[CentOS] Flaky desktop audio behavior.

[William L. Maltby]

On Wed, 2008-07-09 at 13:32 -0700, nate wrote:
> William L. Maltby wrote:
> 
> > CD is playing alright. Volume Control Panel mute, volume, balance all
> > work. In *my* original thread (not the one from ech - Jim?), I couldn't
> > even open the Volume Cont... crap that's too long - VCP  ;-) (you know
> > who you are!)
> 
> I'm not sure it's a bug though, it may be a feature(tm) (the changing
> of permissions on devices). I don't think it should work that way.

I'll forgo my tendency to start a philosophical discussion about that.
I'll just say that whatever method is chosen, I don't think correct
behavior locks out the desktop user when the other current user
(especially when that user was instantiated from the same desktop,
implying that the *ending* ownership should be at least such that it
allows the original gnome user access to the facilities) is finished
with the device(s).

ISTM it is either a design flaw or an implementation flaw.

For an example of correct behavior, just think of ttys where multiple
users can use the same device at different times. When a user logs on,
ownership is given to that user. When the user logs out, ownership is
returned to root.

System resources are *ultimately* managed by the system.

> 
> I checked my Debian Etch desktop at home for any devices that were
> owned by my userid and the only ones that came up were terminal
> devices(/dev/pts/ stuff), which is normal if your logged in. It appears
> Debian hasn't adopted the stuff that changes the ownership of /dev
> devices and instead relies upon group access rights(what I think is
> the right way to do it). So any user in the audio group for example
> has a right to play audio. I don't have any RHEL or CentOS desktops,
> I have a Fedora 8 desktop in VMWare ESX but it doesn't appear to
> provide a virtual sound device so I can't check anything there either.
> My servers get a minimal version of gnome, not enough to login to a
> desktop with but enough to run some gnome or gtk related apps over
> a SSH tunnel.

Sharing via group access rights is OK too. But it is not appropriate for
all devices or even some uses. Think of 3 users printing to a
non-spooled printer simultaneously. Or writing a CD/DVD.

Regardless, when one user of the group accessible device is finished,
subsequent users are not locked out.

So even this scenario supports "buginess" of the RHEL/CentOS situation.

> 
> >  2) When the using application(s) are terminated, the devices ownership
> > should be returned to root, as with tty devices, or back to the desktop
> > user (if that user ever owned them *before* the devices were used -
> > which they weren't in this case) allowing later allocation to another
> > user again and making them also available for the desktop user.
> 
> While this may be possible I can imagine the logic getting confusing
> if there are multiple people that are logged in.

Not too bad. My background includes some extensive programming and early
UNIX kernel internals. Shared devices start out owned by root, are
allocated (implying ownership changes) when opened by the user and
ownership returns to root when usage ends. There are use counts and
associated structures that are checked to see if the device is in use.

With Linux it may be different, but some facility that implements some
sort of similar control has to exist as a general purpose resource for
management of the system.

> 
> >     The Q now is will changing ownership of these affect the volume
> > slider? Shouldn't? First one is an LSB shared object, second one is
> > data.
> 
> No neither of these should impact volume. What impacts volumes with
> regards to flash is if the plugin is actually loaded(which requires
> going to a page that has a flash object), and actually plays some
> audio. Before that happens nothing with the audio subsystem is
> touched as far as I know..

Yep. In my case, it was the T'bird mail notification that played the
sound.

> 
> > Before I write a bug report (after seeing that one doesn't exist),
> > anything else you think I could look for or try?
> 
> Not off the top of my head.. I guess last words would be don't be
> surprised if it doesn't get fixed(short of getting off the scheme
> of changing ownership of dev devices entirely for things like audio),
> which I don't think(hope) would happen until a major OS rev is
> issued.

I agree. Since this would (apparently, based on what is seen)
necessitate the changing of some important library routines and/or
application logic.

It wouldn't surprise me if the response was something like "Why are you
running as multiple users? That's stupid!".

> 
> nate
> <snip sig stuff>

Regardless, your assistance has been most generous and helpful. I
appreciate your selflessness.

Thanks,
-- 
Bill