GUADEC: porting GNOME to Android [LWN.net]

GUADEC: porting GNOME to Android

Posted Aug 18, 2012 17:35 UTC (Sat) by alankila (subscriber, #47141)
In reply to: GUADEC: porting GNOME to Android by Cyberax
Parent article: GUADEC: porting GNOME to Android

Last time I looked, the plugins couldn't be loaded dynamically or configured remotely. Maybe this has changed, but it's far cry from the productized experience that AF offers with OpenSL.

For security reasons, random DSP plugins can't be done on Android either, but the system must at boot-up time declare static list of files to be used for such purposes. But all ROM modders can change this list, so there's that. Afterwards, applications that wish to have their audio stream managed publish their session id to the wider system to work with, and DSP-related applications hear these broadcasts and can use RPC shims to connect to the main mediaserver process to add and remove these effects on a per-session basis.

It is obvious that it takes quite some effort to get from "can be done in principle" to something that can be distributed to end users. My belief is that PA's DSP story is still in the "can be done in principle" stage...

(Log in to post comments)

GUADEC: porting GNOME to Android

Posted Aug 18, 2012 18:05 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

> For security reasons, random DSP plugins can't be done on Android either,
Nope. DSP is often done in _hardware_ on Android (for instance, on Galaxy S phones) and sometimes sound stream doesn't even touch the CPU. So that's the reason for non-dynamic AF plugins.

GUADEC: porting GNOME to Android

Posted Aug 18, 2012 21:16 UTC (Sat) by alankila (subscriber, #47141) [Link]

Oh, some DSP probably is. The sort of thing I have in mind is not. I am not aware of any mediaplayer-based sound streams that would not touch the CPU, although as far as I know phone conversations occur without the main CPU being able to interface with either of those streams.

In any case, Android vendors can provide vendor-specific implementations of AudioEffects, and I suppose it might be possible to hardware-accelerate more of the AudioFlinger API. There's a lot of maybes to this, because last time I looked there was but one digital stream that everything got mixed to, and whatever "DSP" was involved was concerned entirely with the mechanics of generating analog audio from that single PCM data.

So there's multiple kinds of things called "DSP" here. The fact that custom DSP plugins are not possible is obvious given that they must be loaded to a root-owned process implemented in C which must not crash and must be as realtime as possible. So random code, or offloadng processing by some IPC approach is probably out.