[pulseaudio-discuss] Using pulseaudio with speakup

[Bill Cox]

Hi, Colin.  Here's what I'm thinking of doing.  I think PulseAudio
should support the concept of a "global" sound source attached to a
card, and whichever pulseaudio system has rights to use the card
should be responsPible for processing the global source.  Any
pulseaudio client could declare themsevles a "global" source, but to
be considered authorised, they must be of a special global source
group, or perhaps run as a special global source user.

It is clear to me, and I hope becoming clear to you, that there are a
few special cases where a process needs continuous access to the sound
card, and needs to share it with the user.  Speakup is one.  But even
looking at this, it's actually multiple cases.  Speakup just creates
the /dev/speakup_soft device, which speakup clients read to produce
speach.  Two popular drivers exist, both with PA backends:
speechd-up/speech-dispatcher, and espeakup.  I'm sure there are more
reasons for other sound drivers to be considered "global".

Would this scheme be in keeping with PA security?  It seems to me that
it would be pretty secure: it's only a sound source, and there's no
possibility of accessing the mic, for example, and only special
processes can use it.

If this is acceptable, I volunteer to write it.

Thanks,
Bill

On Sat, Jan 2, 2010 at 8:17 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> 'Twas brillig, and Bill Cox at 01/01/10 21:58 did gyre and gimble:
>> However, even with these changes, there are bugs due to pulseaudio's
>> user-based structure.  Today, in Karmic, if I 'switch user' to another
>> use, my new gnome session has no sound.  That's because there are two
>> pulseaudio processes running, and the first one takes over control of
>> the sound card and does not share.
>
> Other folk have replied now but just to explain in detail for clarity:
>
> It is by design that multiple pulseaudio processes run at the same time
> but the idea is that they gracefully drop access to the actual sound
> hardware when the given user is not supposed to have access. This is why
> the gdm user has direct access at the login window and then when a user
> logs in it gracefully hands control over to the real user. Again
> switching users should all just work.
>
> PA should remain running even when the user does not have current access
> to the hardware as it will "cork" it's streams (a sort of equivalent to
> pause) and as more applications are aware of the concept of corking they
> will be able to adjust their UI accordingly. We can also issue corks for
> other reasons (e.g. a voip call comes in so the music and video apps are
> corked/paused.
>
> So whatever problem you are having switching users would seem to suggest
> a problem with consolekit and/or the consolekit module in PA.
>
> Use the program ck-list-sessions to see which user is currently "active"
> to debug this further.
>
> Daniel's earlier comments about the different users are the wait forward
> to debug further.
>
> 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
>