[pulseaudio-discuss] Accessing audio as root

[Gene Heskett]

On Sunday 03 January 2010, Colin Guthrie 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
>
And it seem like a doable, sane approach to the problem.  A voice of sanity 
midst the riot this could become.

But that still leaves PA's biggest problem for this user:  It picks the most 
obviously wrong choice in available audio outputs, whether they exist or not 
in the hardware (in my case they don't physically exist), and I have not 
found a way around that yet.  A default install of mdv2010 on another drive 
here is silent, the only thing heard when booting it is the thump in the 
speakers as udev starts & loads emu10k1.

There needs to be a 'blacklist' that is capable of making it ignore the audio 
it finds during boot initialization that is known not to work. And this needs 
to be a system wide setting that we set once and can then forget.

The only choice, it seems, for those of us with such hardware, is to disable 
PA by whatever means it takes so alsa can then make use of the hardware it 
knows works.  So we do.  And this choice is forced on us by the distros who 
make it the default, and PA's refusal to ack that a problem exists or make 
any visible efforts to fix it.  That is a strong accusation, but from this 
users vantage point, we have no choice but to come to that conclusion.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

I couldn't remember when I had been so disappointed.  Except perhaps the
time I found out that M&Ms really DO melt in your hand.
		-- Peter Oakley