[pulseaudio-discuss] Accessing audio as root

[Colin Guthrie]

'Twas brillig, and Bill Cox at 03/01/10 16:23 did gyre and gimble:
> Speechd-up isn't the only "root" level sound source that's out there.
> Espeakup is another alternative to speechd-up which is currently much
> more popular, but limited in that it can only use the espeak voice.
> From the point of view of developers for such packages, they just want
> to write to a sound output interface.  Espeakup uses portaudio, and
> frankly, I don't want to rewrite that interface (one is enough for
> me).  These processes, even speechd-up, set custom buffering
> parameters in PA (speechd-up requires the tlength paramter to be much
> shorter than default). 

Well in the situation I'm proposing, the speechd-up would actually just
write it's audio to a pipe (totally bypassing pulse client API), and it
would be up to module-pipe-source and module-loopback to act as the
pulse client, reading from the pipe and actually doing the output. The
buffering metrics can be somewhat adjusted when loading module-loopback.

> Instead of writing modules for PA to talk
> directly to speechd-up,

Well it wouldn't be specific modules, just using module-pipe-source
which already exists. It's just a matter of writing to the chosen pipe
in a known format.

> why not write modules to allow user-land PA
> instances to read from a special global PA instance?  That would
> simplify life for the root level sound packages greatly, and keep
> control of the interaction entirely within PA code.

In principle this is not too bad an idea, but I'm really not sure of the
implications of this. I guess some sort of system level PA that is
triggered from system dbus or similar could work and still allow the use
of some of the PA client libraries. The client would have to
specifically ask for access to this and I'm still not sure of the
overall security model here.

All of the suggestions in this thread are pretty "out there" anyway and
I'd really like to get some feedback from others (especially Lennart) on
the most desirable approach. I think he's heading home soon, so should
catch up on the backlog in due course!

> Also, thanks a ton, Colin, for all the advice!

I tries me best :p

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/]