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

Hi, On Sat, 18 Dec 2010, Niels Mayer wrote: 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.