Testing Request for KDE+PulseAudio users

[Colin Guthrie]

'Twas brillig, and Michael Pujos at 07/10/09 19:19 did gyre and gimble:
> IMHO, PulseAudio or Phonon should stay away from both UPnP Media 
> Renderers and Airport Express, as sending audio
> to those devices has nothing to do with setting up  a local sound card, 
> and more to do with  http streaming and SOAP requests.

That is an interesting point. I personally disagree as for me the 
situation with current APEX on OSX and Windows in that you can 
(officially) only use iTunes to output to these devices is too 
restrictive. If you put support for a specific sound output system into 
the applications you get a two fold disadvantage:
  1) Different sound producing apps may or may not support your device 
and the application developers have to go out of their way to support 
it, leading to more work and more potential bug paths.
  2) The UI for sound device control will be different in every application.

For me the UI problem is a big one. On OSX users go to one control panel 
to control their sound output regardless of the app in question (some 
exceptions do exist but the general rule is there. This is currently 
true of Phonon on KDE too and I like that central point of 
configuration. From a usability perspective it sure beats digging 
through random config menus in different apps and finding the "stream to 
APEX" option.

I guess opinions vary.

> One of the biggest problems of audio on Linux is the overload of layers 
> upon layers upon layers and abstractions abstracting other abstractions 
> with all the potential bugs that implies.

Yes I agree, but PA is designed specifically to fit in with this without 
adding much overhead. It's core is both lock free and zero-copy. This 
keeps things pretty slim from an extra layer perspective.


> Some guy mapped the dependency graph of all those layers and the result 
> was just insane.

Yeah but so much of it was redundant. Take a look at some of the Nokia 
slides from LPC the other week... that's the kind of diagrams that are 
done properly.

> IMHO the best way to do it is to code to the standard platform audio 
> API: alsa on Linux, DirectSound on Windows, etc.

Like I said before in my previous email, the userspace management of 
sound is needed and for that some process/daemon needs to be running. 
Whether you call it alsad or pulseaudio makes no difference, I made some 
pretty good arguments as to why it's necessary. You cannot solve all the 
problems with a library alone. CoreAudio on OSX shares a fair bit of its 
design principles with PA... ALSA is needed (PA is probably the most 
advanced ALSA client application out there!) but, for all the reasons I 
details in my last mail, it's certainly not the be all and end all of 
"sound on linux".

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]