PulseAudio & !PulseAudio in KDEMM (was: Re: Phonon Sample Cache)

[Harald Sitter]

On Monday 29 August 2011 10:04:07 Ian Monroe wrote:
> 2011/8/29 Michael Pyne <mpyne at kde.org>:
> > On Saturday, August 27, 2011 13:56:03 Colin Guthrie wrote:
> >> libcanberra does pulse, alsa, gstreamer and OSS. The plan would be to
> >> use pulse by default on most linux systems and write an additional
> >> phonon backend for canberra for those users who do not want to use
> >> pulse
> >> (which is an reducing minority but an annoying vocal one, so needs to
> >> be
> >> supported). If written, this phonon backend would be committed
> >> upstream.
> > 
> > I don't use PulseAudio and I'm on Linux. I do so for the same reason
> > that I used aKode on KDE 3.5 instead of aRts. It's funny that it's not
> > considered completely insane for Linux users to use lightweight
> > programs in other instances where an entire order-of-magnitude more
> > features is not desired (e.g. lighttpd vs. httpd, the various 'light'
> > window managers, etc.). What is it exactly about not using PA when I
> > don't need positional audio or network sound streaming over a home
> > network that I don't have that makes *me* the stick in the mud?
> > 
> > I'd like to think I'd been a completely silent minority... it's looking
> > as if I'll need to change that soon.
> 
> Why use pulseaudio? Check out the subject line of this thread...
> 
> Anyways this is a pretty straightforward case where treating the "no
> pulseaudio" as an error-case rather then a normal use-case makes loads
> of stuff much easier. Like currently we have our own hardware handling
> code in parallel with pulseaudio and its just not really necessary
> anymore.

Speaking with a broader kdemm POV here...

Just to make this perfectly clear: non-PA setups are supported an probably 
always will be, BUT they will not receive the same amount of attention (thus 
integration) because of what Ian highlighted. This mostly applies to platform 
integration features, playback and simple integration (like every phonon app 
using the same audio device) are supported in any setup. A PA-less setup is 
certainly a use case and certainly to be kept in mind, but for the actual 
target audience it makes more sense to ditch PA into their system stack and 
provide them all the fancy features other operating systems provide as well.

One example: device enumeration with PA is persistent across backends, without 
PA it sort of is and soon will not be anymore as the code responsible will be 
removed (or that is the plan anyway - device enum is then outsourced to the 
backend, so that what the enumeration shows is *actually* what the current 
backend supports).

Another example: kmix will not allow individual volume control on different 
apps without PA, even though this could be done with phonon it would only 
replicate functionality of PA on reduced scope.

The advantage with PA is that due to the sound serving nature we get to cover 
most (if not all) relevant apps on a user's system in the integration 
capabilities (like the per-app-volume in kmix, or system wide EQ in the future 
perhaps). Plus of course it reduces the amount of logic we need to maintain to 
achieve platform integration on Linux.

Now I realize that most people who will want to run a non-PA system probably 
do not care about that sort of stuff anyway, so it does not matter much. Also 
we need people to run non-PA setups for QA reasons really.

In conculsion for *nix:
- !PA setups supported
- !PA setups will have less platform integration
- PA setups do provide a high level  of platform integration (without us 
having to maintain epic amounts of code)
- !PA setups necessary for testing as they are valid use case we need to 
support

Other OSs:
- Platform integration is done by the OS's MM stack
- We just throw data at the output device

-- 
Harald