[pulseaudio-discuss] Accessing audio as root
Bill Cox
waywardgeek at gmail.com
Sun Jan 3 08:23:29 PST 2010
Hi, Colin. I like your proposal, but I think I'd like to implement it
in two phases. I'd like to skip step 1 for now, and not deal wit CK,
but as you say, make speechd-up "headless", and write the PA modules
you suggest to pipe sound from speechd-up. CK isn't working properly
with PA in Ubuntu anyway, and I'd like that to get fixed first, so I
can do a Vinux/Ubuntu release based on it. I want to release
VInux/Ubuntu Lucid in May, and there's a ton of non-PA related work to
do, so for now, I'll stick to what I can get working quickly. Please
don't be mad at me if I do one release with PA running as a system
daemon. However, for the following release, I'd like to get it
"right".
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). Instead of writing modules for PA to talk
directly to speechd-up, 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.
What do you think? Also, thanks a ton, Colin, for all the advice!
Bill
On Sun, Jan 3, 2010 at 9:21 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> 'Twas brillig, and Ng Oon-Ee at 03/01/10 13:26 did gyre and gimble:
>> So, in my simplistic and user-centric point-of-view, I wonder if
>> speechd-up accepts audio INPUTS? Perhaps it could act as a pulseaudio
>> sink, with the appropriate modules, of course. It starts before the user
>> logs in and only exits after the user has logged out, of course.
>>
>> The reasoning behind my proposal is simply that root is system-wide by
>> definition (in my understanding), hence why all Colin's proposals have
>> involved speechd-up running as a particular user while all your replies
>> have mentioned root access to pulse....
>
>
> I guess a possibility is the following:
>
> 1. Make console-kit aware of the "idle" state as before.
> 2. Make the speechd-up or speech-dispatcher "headless". i.e. all they do
> is open a pipe (fifo) and pump their synthesised speech to it - they do
> not actually output audio itself.
> 3. Write a PA module that acts as a pulse client that opens that pipe
> and outputs the sound (in actual fact, we could use a combination of
> module-pipe-source and module-loopback for this without writing a single
> line of code in PA).
> 4. Place a script in:
> /usr/lib/ConsoleKit/run-session.d
> or
> /etc/ConsoleKit/run-session.d
> (I'm not sure which is best)
> which basically does the following (see /usr/bin/start-pulseaudio-x11):
>
> /usr/bin/pulseaudio --start --log-target=syslog "$@"
> /usr/bin/pactl load-module module-pipe-source source_name="a11y"
> file="/tmp/a11y.socket" > /dev/null
> /usr/bin/pactl load-module module-loopback source="a11y" > /dev/null
>
>
> (or something like the above - I could have gotten arguments wrong and
> you may want some channels/rate etc. stuff going on). There may also
> need to be something setup to stop PA from exiting after an idle timeout.
>
>
> With all that in place things may just work. Obviously speechd-up would
> have to support multiple clients opening the /tmp/a11y.socket file (and
> it probably shouldn't actually be in /tmp!).
>
> Does that fit better with your model of things?
>
>
> As a side note, would it be wise to provide some kind of positional
> information along with the raw PCM? I'd have thought that using stereo
> to good effect may help with a11y? Event sounds are already positional -
> those triggered at the left of the screen are much louder on the left
> channel etc. This is just a random thought tho'.
>
> 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/]
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>
More information about the pulseaudio-discuss
mailing list