[LAD] Meego pulseaudio "compliance" and "enforcement" (was Re: [Meego-handset] Enabling Speakerphone)

[Kai Vehmanen]

Hi,

On Sat, 18 Dec 2010, Niels Mayer wrote:

> The list comprises a good number of people with expertise in both
> pulseaudio; hopefully the Jack sound server authors, including Paul
> Davis, will be willing to publicly share their perspectives on the
> issues raised regarding the role of pulseaudio on a handset and  Linux
> audio performance/latency/efficiency issues.

btw, just a note that there are lots of LAD/JACK regulars (including me) 
currently working with Maemo/MeeGo, so there's some (or actually quite a 
lot) of history to this discussion.

Here's my reply to Benno's mail (July this year) about this same topic on 
maemo-developers: 
http://lists.maemo.org/pipermail/maemo-developers/2010-July/027087.html

I think many (not all but many) issues you Niels raised in your original 
mail would happen with JACK as well:
   - Most of the CPU load attributed to Pulseaudio is actually
     algorithms specific to the product (in-process clients in JACK
     terms, so would show up with jackd as well).
   - Bugs in kernel drivers that cause scheduling spikes (your WLAN
     scan example) would affect jackd just as badly (bear in mind
     that your average mobile phone has a huge number of hw drivers,
     so there's a lot of kernel code to go through for fine-tuning);
     The Maemo5 N900 firmware should fair much better (it has gone
     through more fine-tuning).. This is very familiar to all of us
     building machines to run jackd. Even one badly behaving driver
     can ruin the whole thing, and hunting these down is not a small
     task.
   - Locking the sample-rate is not specific to Pulseaudio. It's
     more related to the problem of supporting multiple, totally
     independent clients; e.g. you could lock the hw to 8000 for calls,
     but if then video playback is started, while the call is still
     ongoing, do you a) stick to 8000Hz for the whole video as well,
     b) have a glitch as you need to reprogram the hw to different rate,
     or c) do you do the common thing and run at a common backend rate
     (like 48000) and resample some of the client streams.

Agreed, JACK has many strong points that apply to MeeGo context as well, 
especially in providing a good API for out-of-process clients to get 
low-latency access to the audio engine. You can do the same with 
Pulseaudio, but it's more complicated and more prono to errors (e.g. the 
QAudio recording example Benno mentioned in the above thread). But then 
OTOH, Pulseaudio has many strong points as well. Both projects can be 
extended/developed. Of course here one important factor is what the 
projects themselves want to do... and here Pulseaudio has a much more 
explicit focus on wanting to solve the wider audio-on-the-desktop problem, 
and it has had that for a long time.