[pulseaudio-discuss] Accessing audio as root

[David Henningsson]

(Answer to both Colin and Bill)

Colin Guthrie wrote:
> 'Twas brillig, and Bill Cox at 02/01/10 15:03 did gyre and gimble:
>> Hi, David.
>>
>> On Sat, Jan 2, 2010 at 1:08 AM, David Henningsson
>> <launchpad.web at epost.diwic.se> wrote:
>>> I was just thinking, and this idea is perhaps not 100% thought through,
>>> but it could be worth considering.
>>>
>>> We have this hand-over mechanism:
>>>
>>> http://git.0pointer.de/?p=reserve.git;a=blob_plain;f=reserve.txt
>> You obviously know more about the plumbing than I do!  I don't know
>> anything about d-bus, so my opinion counts little, but it looks like a
>> good direction to me.  I would want to bury all the complexity of
>> dealing with d-bus under the pulse-simple API, so that only a one-line
>> change has to be made to clients like speakup/espeakup and
>> speakup/speechd-up.

You're talking about the pulse-simple API here, I thought the speech
daemon, timidity etc were using ALSA directly? Are you planning to
change that? (And if you do, what consequences will that bring to
speakup being able to talk when PulseAudio is down?)

>> I'm not quite sure how this works.  When a speakup client wants access
>> to the sound card, it could request access at high priority, and then
>> plays it's sound.  How would it hand back the sound card to the other
>> user and uncork it?  

Good question. I'm assuming it is handled in a good way already between
PulseAudio and Jack and that way could work here as well. I think one
can listen to org.freedesktop.DBus.NameOwnerChanged, or just poll once a
second. However the reserve API does not currently handle (in the best
way) if there is more than one client waiting for the soundcard.

>> If this were automatic once the queue was empty
>> for say one second, that would be great.  Is this the sort of thing we
>> can do with PA/CK?

> While this would theoretically work, I think it's probably not needed.
> The reservation system is really meant for interacting with jack and
> while it's not exclusive, I think it's not really an appropriate
> technique to solve this problem.
> 
> I think the general concept of the speech dispatchers running as a
> system service is the bit that needs re-thought and that adding hooks to
> consolekit (if they don't exist) and the concept of an "idle user" are
> probably more practical long term solutions.
> 
> Of course I could be wrong on that front :p

Taking it a step back, and looking at it from a higher, conceptual
level, I think it depends on how you view upon the soundcard. If you
view it as a part of the seat (as in ConsoleKit's definition), then the
ConsoleKit approach makes most sense. If you view the soundcard as a
system-wide resource, it makes more sense to make the reserve API
system-wide as well.

PulseAudio has taken the "seat" approach, whereas the speak server has
taken the "system-wide resource" approach. And I personally think both
views are equally valid - after all, we don't know anything about the
actual physical location of the speakers/mic! So for PulseAudio to be a
little friendly in a heterogeneous world, would it hurt to move/copy the
reserve API to the system d-bus? Then it would be up to the speech
daemon, timidity, and the others, to make their own choice whether they
want to integrate with ConsoleKit and get the mixing features of
PulseAudio, or - a little more quick and dirty, perhaps - just request
the device on the d-bus.

// David