Project

General

Profile

Actions

Bug #6336

closed

ms-sdr audio calls don't work

Added by Hoernchen 3 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
01/21/2024
Due date:
% Done:

0%

Resolution:
Spec Reference:

Description

https://cgit.osmocom.org/osmocom-bb/commit/?id=fd8962e89144fb0af4b99199589d9f9768804640 completely broke ms-sdr audio calls, the len is 0, but not always - removing the assertion "makes it work again", as far as not crashing and hearing sound is concerned.
Audio has never really sounded great, so, it looks like we are getting broken audio frames that are now missing due to the patch/have len 0?

<0014> gapk_io.c:300 PQ 'pq_audio_sink': chain 'source/tch_fb -> format/gsm -> ecu/fr -> format/gsm -> codec/fr -> sink/alsa' prepared
<0014> gapk_io.c:476 GAPK I/O initialized for MS '1', codec 'fr'
<0001> gsm48_rr.c:4074 request suspension of data link
<0001> gsm48_rr.c:4540 suspension coplete, leaving dedicated mode
<0001> gsm48_rr.c:3001 setting indicated TA 0 (actual TA 0)
<0001> gsm48_rr.c:3012 using last SACCH timeout 32
<0001> gsm48_rr.c:837 stopping pending timer T_meas
<0001> gsm48_rr.c:2901 MEAS REP: pwr=19 TA=0 meas-invalid=1 rxlev-full=-110 rxlev-sub=-110 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0
<0001> gsm48_rr.c:3034 establishing channel in dedicated mode
<0001> gsm48_rr.c:3045  Channel type 8, subch 0, ts 2, mode 1, audio-mode 10, cipher 1
<0001> gsm48_rr.c:4575 request resume of data link
<0001> gsm48_rr.c:3708 ASSIGNMENT COMPLETE (cause #0)
mobile: fmt_gsm.c:48: int gsm_to_canon(uint8_t *, const uint8_t *, unsigned int): Assertion `src_len == GSM_LEN' failed.
Process 2211765 stopped
* thread #1, name = 'mobile', stop reason = signal SIGABRT
    frame #0: 0x0000007ff7a753f8 libc.so.6`__pthread_kill_implementation(threadid=549621288992, signo=6, no_tid=<unavailable>) at pthread_kill.c:44:76
(lldb) bt
* thread #1, name = 'mobile', stop reason = signal SIGABRT
  * frame #0: 0x0000007ff7a753f8 libc.so.6`__pthread_kill_implementation(threadid=549621288992, signo=6, no_tid=<unavailable>) at pthread_kill.c:44:76
    frame #1: 0x0000007ff7a2b6ac libc.so.6`__GI_raise(sig=6) at raise.c:26:13
    frame #2: 0x0000007ff7a16ec0 libc.so.6`__GI_abort at abort.c:79:7
    frame #3: 0x0000007ff7a24bf8 libc.so.6`__assert_fail_base(fmt="%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion="src_len == GSM_LEN", file="fmt_gsm.c", line=48, function="int gsm_to_canon(uint8_t *, const uint8_t *, unsigned int)") at assert.c:92:3
    frame #4: 0x0000007ff7a24c6c libc.so.6`__assert_fail(assertion="src_len == GSM_LEN", file="fmt_gsm.c", line=48, function="int gsm_to_canon(uint8_t *, const uint8_t *, unsigned int)") at assert.c:101:3
    frame #5: 0x0000007ff7ba5980 libosmogapk.so.0`gsm_to_canon(dst=<unavailable>, src=<unavailable>, src_len=<unavailable>) at fmt_gsm.c:48:2
    frame #6: 0x0000007ff7ba2eac libosmogapk.so.0`osmo_gapk_pq_execute(pq=0x00000055557629c0) at procqueue.c:202:8
    frame #7: 0x00000055555afbd0 mobile`gapk_io_serve_ms(ms=0x0000005555732120) at gapk_io.c:572:3
    frame #8: 0x00000055555693bc mobile`mobile_work(ms=0x0000005555732120) at app_mobile.c:86:9
    frame #9: 0x000000555556a0e0 mobile`_mobile_app_work at app_mobile.c:428:12
    frame #10: 0x00000055555691d4 mobile`main(argc=<unavailable>, argv=<unavailable>) at main.c:340:3
    frame #11: 0x0000007ff7a17584 libc.so.6`__libc_start_call_main(main=(mobile`main at main.c:250), argc=3, argv=0x0000007fffffec98) at libc_start_call_main.h:58:16
    frame #12: 0x0000007ff7a17658 libc.so.6`__libc_start_main_impl(main=(mobile`main at main.c:250), argc=3, argv=0x0000007fffffec98, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=<unavailable>) at libc-start.c:360:3
    frame #13: 0x0000005555568970 mobile`_start + 48
(lldb)


Related issues

Related to OsmocomBB - Bug #6337: bad fr audio with gapk/ms-sdrNew01/22/2024

Actions
Actions #1

Updated by fixeria 3 months ago

  • Status changed from New to Feedback
  • Assignee changed from fixeria to Hoernchen

I stumbled upon this issue a few weeks ago while working on #4396, the fix has been merged to master:

https://cgit.osmocom.org/osmocom-bb/commit/?id=ca183f79d8aef31f9cff5670a06ffbc8c50f90ea

This fixes a segfault on receipt of TRAFFIC.ind with len=0. Can you test with this patch applied?

Hoernchen wrote:

Audio has never really sounded great

Interestingly enough, I had good audio quality results when testing on my old DELL laptop, but on my new laptop it's quite choppy.
I think [at least part of] the problem is that we're calling blocking ALSA API in libosmogapk. Did you notice how laggy the VTY interface becomes during a call?
I also have a feeling that we're sending more UL TRAFFIC.req than DL TRAFFIC.ind we get from the PHY. I am seeing "dropping ..." when testing with a Mot C1xx phone.
Anyways, this problem deserves a separate ticket.

it looks like we are getting broken audio frames that are now missing due to the patch/have len 0?

If you remove the assert(src_len == GSM_LEN) in gsm_to_canon(), it would still copy GSM_LEN from the input buffer. It's either garbage or zeroes...

Actions #2

Updated by Hoernchen 3 months ago

  • Status changed from Feedback to Resolved

Oh yes, that patch actually resolves that part of the issue..
The other audio issues don't really appear to be cpu related, but "something" sucks.

Actions #3

Updated by Hoernchen 3 months ago

  • Related to Bug #6337: bad fr audio with gapk/ms-sdr added
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)