Confusion over audio device enumeration

[Colin Guthrie]

'Twas brillig, and Martin Sandsmark at 23/09/09 15:57 did gyre and gimble:
> I'm no PulseAudio fan, but I can certainly see its use cases (networked sound
> for thin clients, for example), so I'm very glad someone is poking into this.

Yeah thin client use case is a big one for sure and I also think the 
non-hardware devices support is key. More and more people are using 
bluetooth headsets/headphones, uPnP devices and Apple Airtunes devices 
and pulse is pretty good at dealing with all those and alsa is not 
really (IMO) the ideal place to do that (BT via alsa does work but BT 
via pulseaudio is where all the upstream (meaning bluez) support is going).

>> So the platform plugin (second link) provides both it's own devices and 
>> ask the backend. But the backend (first link) also appears to ask the 
>> platform plugin for it's devices as well as giving it's own too.
> 
> I think this is because it is supposed to configure ALSA too. But I haven't
> looked much into that part of the backend plugin, so I'm not entirely sure.
> :-)

 From what I gather the platform plugin does indeed enumerate devices 
from alsa. The current pulseaudio support in the platform plugin doesn't 
work with any recent pulseaudio as it relies on the name given to the 
devices by pulse's autodetection plugin which has been completely 
replaced in recently cycles. It basically seems to just augment the alsa 
devices pulse knows about to the built in list of alsa devices anyway 
which isn't really what I'd call pulseaudio support at all!

So I'll probably strip that pulse code out completely from the platform 
plugin and keep going with my general approach of making the backends 
themselves aware of pulse and able to pass on the info they get from 
pulse about the devices.

I think my changes so far are quite neat (e.g. keeping the pulse stuff 
contained within a couple of classes and only relatively minimal changes 
to the actual backends themselves. And of course it's all optional, 
degrading nicely if pulseaudio is not installed.


But I digress. I'm still confused as to the double GlobalConfig system 
in use.... I'd have expected that the one in kcm should be removed in 
some capacity. The do seem to be more or less duplicated but both still 
used depending on context which is where my confusion comes in :s

If no one knows I'll just have to crack on and hope for the best :)


>> etc.) but am a little disappointed that there are several linux backends 
>> - personally I'd prefer to see efforts concentrated on one backend 
> 
> I couldn't have put it better myself :-)

:)

>> [...] But if we use pulseaudio in the way I am working towards, then *all*
>> applications will honour this configuration (pulse can determine most
>> applications' role automatically from the category in their .desktop file)
> 
> This sounds pretty nice, though I would obviously prefer if it was done by
> mucking with the asoundrc, instead of needing a whole sound server, but
> that's not what we're discussing here, so meh. :-P

Potentially, but I doubt that asoundrc would actually be able to deal 
with this for all applications, including fallback etc. when devices are 
removed and other such stuff.

It's also interesting that sound servers still seem to have a bad 
reputation!

For current pulseaudio releases, we're seeing significant interest from 
the embedded community with intel utilising pulse's timer based 
scheduling core (aka glitch-free) with very large latencies (up to 10s) 
and interrupts disabled to get increased power savings (most people 
think that latency == bad but most of the time latency is good for power 
consumption). Alsa on it's own cannot (or at least doesn't) implement 
this approach so pulseaudio is becoming more popular in embedded devices 
where power consumption is key (it's used on the Palm Pre incidentally 
as well as on Moblin and Nokia have a reasonable interest too which is 
where things might become interesting for KDE/Qt) and is continuing to 
increase it's popularity on the desktop/laptop fields too. So I think 
it's just a matter of time before the main problems are resolved and 
everyone is assimilated! :p

Anyway, I've already started down the "pulseaudio is awesome" 
evangelistic trail and while I enjoy the "pulseaudio is awesome" vs. 
"pulseaudio sucks" debates, they tend to go on for *ages* without any 
real outcomes so I'll stop myself :p

Many thanks for your reply (and for the albeit brief chat on IRC yesterday!)

Take care.

Col



-- 

+------------------------+
|     Colin Guthrie      |
+------------------------+
|     colin at guthr.ie     |
| http://colin.guthr.ie/ |
+------------------------+