kaali1 | 2 years ago | on: Easy Effects: Audio effects for PipeWire applications
kaali1's comments
kaali1 | 3 years ago | on: Linux Touchpad like MacBook Update: 2022 progress and new poll
This issue is the reason I switch to Chromium to read long articles.
The fix seems to unfortunately be gated by Firefox migrating to GTK4 https://bugzilla.mozilla.org/show_bug.cgi?id=1568722
kaali1 | 4 years ago | on: FCC finally starts tackling America's robocall scourge
> Does it mean if I had a rooted phone I could get the call recording working on latest Android?
Some phone hardware architecture can't let the AP (the Processor running Android) access the call audio (because the audio stream is routed directly from the mic/speaker to the modem). On those no amount of root hacking will allow you to record calls. Nevertheless this is rare nowadays where all the audio goes through an ADSP connected to the AP.
Your best bet is to find a phone manufacturer/vendor that advertise call recording support. Alternatively search on call recording website like [1] which phone they support rooted. [1] https://www.boldbeast.com/android/call_recorder.html
kaali1 | 4 years ago | on: FCC finally starts tackling America's robocall scourge
The API was never removed, it's just behind a system permission (only system apps can be granted this permission).
Before Marshmallow (2015), recording phone calls was behind the same permission as recording the mic. This was obviously bad as voice calls are much more privacy sensitive than the mic. In Marshmallow, phone calls recording was updated to be guarded by a new permission, a system one, so only system application can access it.
Nevertheless, there were multiple ways to bypass the new system permission, which call recording apps made use to continue recording calls even without the system permission. Those ways were fixed one after the other as part of securing and refactors of the audio stack. The last such bug was fixed in Android 9.
Any OEM can bundle a call recording apps, it's just that many don't.
kaali1 | 5 years ago | on: The end arrives as Adobe starts blocking Flash content
I am in a similar situation and was able to disabled Flash's EOL "kill switch" just for this old flash site with a mms.cfg:
EOLUninstallDisable=1
EnableAllowList=1
AllowListUrlPattern=https://old-flash-site.com
kaali1 | 5 years ago | on: The Case of the Extra 40ms
You are right, Aaudio is available since Oreo only and the device is 3 version older. Additionally Netflix 's video playback is not a low latency use-case, so it shouldn't use Aaudio even on recent devices.
My comment was about the parent's affirmation that low latency apps should be scheduled by interrupt.
kaali1 | 5 years ago | on: The Case of the Extra 40ms
The way to get the best latency on a device is not for your processing loop to be directly driven by an audio hardware events/interrupts. This is for many reasons:
1) events/interrupts can be delayed (usually by (bad) drivers disabling interrupt for a long time).
2) latency is not adjustable. You may want to give your processing more time if you know more work needs to be done, or the system is under variable load.
3) you will usually finish generating your audio too early. Eg: if the interrupts is every 2ms, but your processing is 1ms long, you are adding an unnecessary 1ms latency by starting as soon as the interrupt is received.
4) the device will consume more power as it can not know when it will next wakeup (theoretically, I do not think it makes a difference in practice)
Modern mobile devices use a DMA to copy the content of the application processor (AP) to the audio DSP. This DMA will copy periodically the content of a AP buffer to a DSP buffer, this is called a DMA burst.
You want to track this burst and wakup just enough time before it to have the time to generate your audio data and write it to the AP buffer + a safety margin. This allows you to track the system performance & application load to adjust your safety margin and optimize latency. It also allows the scheduler to know when your app will need to be woken up far in advance leading.
The Android Aaudio API [1] implement what I just described, as well as memory mapping the AP buffer to the application process to achieve 0 copy. It is the way to achieve the lowest latency on Android.
I believe Apple low latency APIs uses a similar no interrupt design.
Source: worked 3 years on the Android audio framework at Google.
Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer.
[1]: https://developer.android.com/ndk/guides/audio/aaudio/aaudio
page 1
[1]: https://developer.android.com/reference/android/media/audiof...