(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
