Android - Audio decoding stutters/drops when UI is active on low-end devices (Samsung Tab A8)

[djnutmac]

I am experiencing performance issues when running the application on lower-end devices, specifically on my Samsung Galaxy Tab A8. When the application UI is open and visible, the signal decoding is unstable and stutters significantly (the signal drops approximately every second).

Observed Behavior

UI Active (Foreground): The audio/decoding drops intermittently (hiccups) every second.

UI Backgrounded: When I minimize the app (leaving the app running in the background), the decoding becomes perfect, and any DAB station plays smoothly without interruption.

Impact on Functionality This performance lag significantly affects the Bandscan feature. Due to the continuous signal interruptions caused by the UI load, the scanner fails to lock onto weaker ensembles/signals that would otherwise be receivable.

Feature Request / Proposed Solution Could you consider implementing a "LIGHT MODE" toggle? This button could disable heavy UI animations or resource-intensive visual elements. This would allow users with less powerful hardware to view the interface and control the app without compromising the audio decoding stability.

Environment

Device: Samsung Galaxy Tab A8

Issue: High UI CPU/GPU usage causing decoding dropouts

[KejPi]

The intention is to share application code with desktop version as much as possible. In general application is well optimized for performnce and I think that when you compare on desktop, the CPU usage is significantly lower than other DAB apps. Adding another option does not necessarily decrease system load as new option means new conditions to be evaluated all the time. There should be no animation running if you do not interact with the application, especially on some screens like About there is nothing to animate. Did you check application log?

I have purchased Samsung Galaxy Tab A11 for development and testing and application runs fine on this device. Of course it is more powerful than A8 but I do not think that the difference is huge. And I also have very old Pixel 3a and do not have performance issues either. Is any other DAB SDR running smoothly on your device?

[djnutmac]

Update on debugging:

I’ve conducted further testing and managed to isolate the trigger for the stuttering/dropouts. It appears to be strictly related to the Gain Control implementation on this specific hardware.

Findings:

The Workaround: The stuttering stops completely ONLY if I set the Gain Control to DEVICE.

The Failure Mode: If I switch to SOFTWARE, DRIVER, or MANUAL gain, the decoding collapses immediately. The device seems unable to handle the processing overhead required for these gain modes.

The Trade-off: While DEVICE mode fixes the stutter, it kills the sensitivity. On a strong local DAB signal that typically yields 30dB SNR, setting it to DEVICE caps it at just 5dB SNR. It seems that any attempt to increase the gain (or the processing associated with higher gain) causes the decoding thread to hang or drop frames.

Cross-Reference: I verified this by installing the same build on an older Huawei Mate 10 Pro, and it works flawlessly across all gain modes.
I also installed welle.io on the Tab and works perfectly

Next Steps: This is a blocker for me as I planned to use this setup for Tropo DX this summer. As a last resort, I am going to perform a full factory reset on the Samsung Tab A8 to rule out any OS-level conflicts, but it strongly looks like a resource bottleneck specific to how the app handles gain on this chipset.

[KejPi]

Software gain requires additional processing in data acquisition thread but I do not think is that big. Maybe that it is the last "drop" causing resources overload. Also that welle.io runs on the device is confusing. As far as I know it generally uses more resources than AbracaDABra at least on desktop. I could try to increase acquisition thread priority if that helps but in general something goes wrong and this may just hide the realy issue.

To recap: Tab A8 it works only when app in in background (== no rendering) or when RTL-SDR gain mode is Device (== lower lod in acquisition thread).

What about the application log in SW mode? What do you see there? Can you share complete log?

[djnutmac]

10:45:41.138 [I] RadioControl: Playing: [E0505C @ 204640 kHz | 9B] DISCORADIO E05348 : 0
10:45:41.144 [I] RadioControl: Starting user application 'SlideShow' from XPAD.
10:45:41.738 [I] AudioDecoder: HE-AAC v2 48 kHz stereo
10:45:41.739 [I] AudioDecoder: Output sample rate 48000 Hz, channels: 2
10:45:42.139 [I] RadioControl: Starting user application 'SlideShow' from XPAD.
10:45:42.142 [I] Application: Uploading ensemble information to FMLIST (3933 bytes)
10:45:42.298 [I] Application: Ensemble information uploaded, thank you!
10:45:42.606 [I] AudioOutput: Unmuting audio
10:45:42.756 [I] AudioDecoder: Muting audio (decoding errors)
10:45:42.757 [I] AudioDecoder: Unmuting audio
10:45:42.762 [I] AudioDecoder: Muting audio (decoding errors)
10:45:42.939 [I] AudioDecoder: Unmuting audio
10:45:43.348 [I] AudioDecoder: Muting audio (decoding errors)
10:45:43.532 [I] AudioDecoder: Unmuting audio
10:45:43.738 [I] AudioDecoder: Muting audio (decoding errors)
10:45:43.943 [I] AudioDecoder: Unmuting audio
10:45:44.347 [I] AudioDecoder: Muting audio (decoding errors)
10:45:44.353 [I] AudioDecoder: Unmuting audio
10:45:45.349 [I] AudioDecoder: Muting audio (decoding errors)
10:45:45.540 [I] AudioDecoder: Unmuting audio
10:45:46.145 [I] AudioDecoder: Muting audio (decoding errors)
10:45:46.156 [I] AudioDecoder: Unmuting audio
10:45:46.549 [I] AudioDecoder: Muting audio (decoding errors)
10:45:46.742 [I] AudioDecoder: Unmuting audio
10:45:47.347 [I] AudioDecoder: Muting audio (decoding errors)
10:45:47.353 [I] AudioDecoder: Unmuting audio
10:45:48.755 [I] AudioDecoder: Muting audio (decoding errors)
10:45:48.930 [I] AudioDecoder: Unmuting audio
10:45:49.551 [I] AudioDecoder: Muting audio (decoding errors)
10:45:49.732 [I] AudioDecoder: Unmuting audio
10:45:51.951 [I] AudioDecoder: Muting audio (decoding errors)
10:45:51.972 [I] AudioDecoder: Unmuting audio
10:45:54.755 [I] AudioDecoder: Muting audio (decoding errors)
10:45:54.940 [I] AudioDecoder: Unmuting audio
10:45:56.363 [I] AudioDecoder: Muting audio (decoding errors)
10:45:57.995 [I] AudioOutput: Muting... [available 1920 samples]
10:46:04.981 [I] AudioDecoder: Unmuting audio
10:46:05.374 [I] AudioDecoder: Muting audio (decoding errors)
10:46:06.016 [I] AudioOutput: Unmuting audio
10:46:06.192 [I] AudioDecoder: Unmuting audio
10:46:06.198 [I] AudioDecoder: Muting audio (decoding errors)
10:46:07.395 [I] AudioDecoder: Unmuting audio
10:46:07.595 [I] AudioDecoder: Muting audio (decoding errors)

[KejPi]

Thank you! This is actually very interesting. What about SNR indication? Is it stable or is it jumping from zero to some value?

[djnutmac]

I performed a full factory reset on the Samsung Tab A8 to rule out any potential software conflicts or background processes.

Environment: Fresh OS install, only this application installed.

Result: Unfortunately, the issue persists exactly as before. The decoding still stutters/drops unless I restrict the Gain Control to DEVICE.

SNR in other gain modes goes from peak to 0 to peak continuously

[djnutmac]

After discussing the behavior with a colleague (an electronic engineer), we suspect the bottleneck might lie within the graphics drivers/GPU of the Samsung Tab A8. It appears the device struggles to handle the UI rendering overhead, which likely ends up starving the audio decoding thread of necessary resources.

[KejPi]

It could be that GPU is the bottleneck nevertheless, AudioDecoder does not have problems with resources. The problem actually is input stream that is probably dropping data that is why you see SNR jumps. Audio decoding errors are because decoder input stream is currupted and it is corrupted because DAB decoder receives corrupted input IQ data. So the problem is in data acquisition. The question is why your device cannot capture input data fast enough. It could be that overall system resources are not sufficient for the application but I do not understand why it happens. I will think about that, I have some ideas but I am affraid that solving this issue without having the problematic HW for testing is more or less impossible. I might evetually create some test build but I will rely on you to test it.

Just one thing maybe worth to try is to change the cable between tablet and RTL-SDR. If you have other cable, please check with that, the USB cable shall be a good quality cable and it should be also as short as possible.

EDIT: I was thinking about the issue again and actually, th edifference between SW and Device AGC is not less processing it data acquisition thread, data acquisition thread is independent. The key difference in my opinion is the communication with the HW.

[djnutmac]

It definitely points to a hardware limitation on the tablet.
It is quite ironic that an 8-year-old phone (Huawei Mate 10 Pro, EMUI, Android 12) significantly outperforms a 2-year-old Samsung Tab A8 (One UI 6.1, Android 14) for this specific task.

[djnutmac]

I noticed a seemingly random behavior when switching from one of the unstable gain modes back to DEVICE.
Sometimes, the SNR correctly returns to the expected level (~30dB). However, at other times, it gets stuck/capped at 5dB after the switch

[KejPi]

Device AGC was never good on RTL-SDR devices that is why I have implemented it in SW.

[djnutmac]

but is the only way.... I have also SDRplay RSP1 clone, but works only on desktop version beacuse is not listed on the phone/TAB

[KejPi]

SDRplay devices are not supported because as far as I know there is no API available for Android. Is there any SDR application on Android that works with that?