[pulseaudio-discuss] Accessing audio as root

[Bill Cox]

Hi, Luke.  I didn't know you were VI, but I see your name on all sorts
of code I've looked at.  Thanks for all of it!

You may have better insight than the rest of us here in this
discussion.  Personally, I'm beginning to lean towards building or
debugging a bypass mux, like dmix, to minimize the code involved
between speakup and the sound card.  I'm comparing this to how the
monitor works.  If we want sound to be as reliable as the X server (or
worse), then we could implement the connection through CK and
user-land PA, and configure some modules to make the connection.
However, when X crashes (every other day or so), I hit Ctrl+Alt+F1,
and bang!  I'm back in a reliable console, and back in business.
Given the importance of speech on systems for the blind, shouldn't we
work towards a system like that?  These are decisions that will effect
VI users for many years, and I'd like to say we did our best for them.

I was leaning towards Colin's solution as you are, but when I tried
emulating manually what we would automate through CK, I found that two
PA instances on my machine result in locking the sound card by the
first one, period.  This is true of both my Karmic and Lucid installs.
 Switch user also fails to transfer sound rights on both systems,
which is a reported bug with no progress in some time.  Can we really
rely on a currently broken system for speech?

Those are my current thoughts.  I would be very interested in yours.

Thanks,
Bill

On Sun, Jan 3, 2010 at 6:36 PM, Luke Yelavich <themuso at ubuntu.com> wrote:
> On Sun, Jan 03, 2010 at 01:08:07AM EST, Colin Guthrie wrote:
>> 'Twas brillig, and Tanu Kaskinen at 02/01/10 05:59 did gyre and gimble:
>> > So that's how I see it should work. I'm not very confident when speaking
>> > about consolekit and boot/login processes, so I have to hope that the
>> > system I described isn't too different from how things work in reality.
>>
>> I think I agree more or less, but with perhaps a few caveats/clarifications.
>>
>> 1. I think the "anybody" user is a valid concept. I'd personally call it
>> the "idle" or "inactive" user as homage to the active denomination in
>> consolekit already.
>>
>> To run some practical tests, if you run:
>>
>> [colin at jimmy ~]$ ck-list-sessions
>> Session1:
>>       unix-user = '603'
>>       realname = 'Colin Guthrie'
>>       seat = 'Seat1'
>>       session-type = ''
>>       active = TRUE
>>       x11-display = ':0'
>>       x11-display-device = '/dev/tty7'
>>       display-device = ''
>>       remote-host-name = ''
>>       is-local = TRUE
>>       on-since = '2009-12-30T09:40:14.334448Z'
>>       login-session-id = '4294967295'
>>
>> you can see that I am the "active" user currently.
>>
>> If however I run the following and then switch to the login window on tty1:
>>
>> [colin at jimmy ~]$ sleep 3; ck-list-sessions
>> Session1:
>>       unix-user = '603'
>>       realname = 'Colin Guthrie'
>>       seat = 'Seat1'
>>       session-type = ''
>>       active = FALSE
>>       x11-display = ':0'
>>       x11-display-device = '/dev/tty7'
>>       display-device = ''
>>       remote-host-name = ''
>>       is-local = TRUE
>>       on-since = '2009-12-30T09:40:14.334448Z'
>>       login-session-id = '4294967295'
>>
>> Here we see that no user is currently "active". In this mode no user is
>> active on my system - i.e. it's "idle".
>>
>>
>> Now lets think about permissions. Some folks have recently mentioned the
>> "audio" group. This is a relic and should not be used or considered for
>> controlling access to audio hardware. The real way forward is the
>> interaction between udev and console kit applying ACLs for the
>> appropriate users.
>>
>> Now in this case we really need to define a user on the system who is
>> "idle". Both udev and console-kit probably need to be aware of this
>> concept and write the appropriate ACLs to the sound hardware for the
>> "idle" user, removing them when a real user logs in (and in this case
>> "gdm" should be considered a "real" user.
>
> This sounds good, however one big problem is that speakup is actually kernel code, i.e its run as a kernel module, so it can get low level access to the tty devices to read the text. For the record, I am a vision impaired user, who uses a screen reader, and again for the record, this is an approach I am personally very much against. Instead, we need a daemon that will run as the idle user, and then through the hand-over stuff discussed in the rest of Colin's email, act appropriately. There are already user-space device nodes for reading the contents of the tty, and the BrlTTY Braille display daemon already uses these. BrlTTY already supports speech output, so it needs screen reader control via keyboard added, as well as working accross multiple user sessions etc.
>
> In short, what has happened here, is that the Linux desktop has evolved, and the accessibility software for people with blindness/vision impairement, has not. If such software wants to stay relevant, it has to evolve, or it will die. So yes we need consolekit to have idle user support, and then we need all the lower level accessibility software, eg for using Braille displays/speech output for the console, to also be improved to work system wide, and per user.
>
> I would be happy to do this work, if I had the time. :)
>
> Luke
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>