FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 07-07-2008, 10:45 AM
"William L. Maltby"
 
Default Flaky desktop audio behavior.

Might have some kind of bug here. I want to know if anybody else is
seeing this. It's happened twice now, so I should be able to repeat it.

$ rpm -q centos-release
centos-release-5-2.el5.centos

On my desktop, I "su -" to another user. Then "nohup thunderbird", it
gets the mail and plays the announcement. ISTM this is an error right
off the bat as this user is not the desktop owner. But that's not the
main point. I really am OK with that behavior in my instance.

The problem is that the sound system goes muted, as indicated by the
volume control on my desktop panel and I can't recover from it except by
a reboot.

When I try to open the sound control panel, I get an error panel saying
"No volume control GStreamer plugins and/or devices found". If I just
try to un-mute, there's no error message but the status does not change.

I've attached a snapshot of the error panel.

Further, in chasing another problem that Jim (hce) had, we have done
this:

# find . -type f -exec echo {} ; -exec cat {} ; >/tmp/asound.play.bug

Normally it acts as expected but now I get this.

cat: ./acpi/event: Device or resource busy
cat: ./sys/net/ipv6/route/flush: Operation not permitted
cat: ./sys/net/ipv4/route/flush: Operation not permitted
cat: ./sys/fs/binfmt_misc/register: Invalid argument
cat: ./sysrq-trigger: Invalid argument

and it hangs right there. <Ctl>-<C> breaks OK.

I feel it might be related to Jim's problem. I feel it might be a bug.

Can anybody reproduce? I think the T'bird step is coincidental. I think
any sound played as another user should reproduce it. Hmmm ... I might
be assuming to much if I assume another user is significant.

TIA
--
Bill
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-07-2008, 04:13 PM
"nate"
 
Default Flaky desktop audio behavior.

William L. Maltby wrote:

> I feel it might be related to Jim's problem. I feel it might be a bug.
>
> Can anybody reproduce? I think the T'bird step is coincidental. I think
> any sound played as another user should reproduce it. Hmmm ... I might
> be assuming to much if I assume another user is significant.
>

I don't see why the desktop owner would be the only one that can play
a sound. But in any case have you checked to see if the sound device
is locked by another process? When I have sound issues I usually run
lsof | grep /dev/dsp to see what, if anything is using the sound card
and kill it. To me it sounds like thunderbird from the other user is
accessing the sound card directly, perhaps preventing other apps from
accessing it. Some desktop setups include a sound daemon like esd or
karts(?), to facilitate multiple things accessing the sound card
simultaneously, but I'm not sure what their capabilities/limitations
are as I rarely if ever use them.

nate

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-07-2008, 04:32 PM
"William L. Maltby"
 
Default Flaky desktop audio behavior.

On Mon, 2008-07-07 at 09:13 -0700, nate wrote:
> William L. Maltby wrote:
>
> > I feel it might be related to Jim's problem. I feel it might be a bug.
> >
> > Can anybody reproduce? I think the T'bird step is coincidental. I think
> > any sound played as another user should reproduce it. Hmmm ... I might
> > be assuming to much if I assume another user is significant.
> >
>
> I don't see why the desktop owner would be the only one that can play
> a sound. But in any case have you checked to see if the sound device

I based my presumption based on past behavior (4.2-4.6, 5.0-5.1) and
seeing the logic of why a desktop user might have exclusive use - if
that user is first to use it. Before this, never tried to have another
user use it first.

> is locked by another process? When I have sound issues I usually run
> lsof | grep /dev/dsp to see what, if anything is using the sound card
> and kill it. To me it sounds like thunderbird from the other user is

I'll do that. But in the two cases so far, I had exited the T'bird after
reading the mail and expected that that should remove any locks and
close any open files.

> accessing the sound card directly, perhaps preventing other apps from
> accessing it. Some desktop setups include a sound daemon like esd or
> karts(?), to facilitate multiple things accessing the sound card
> simultaneously, but I'm not sure what their capabilities/limitations
> are as I rarely if ever use them.

I'll check this out too. The sound daemon is available, esound-0.2.36-3,
and I see a config file. I'll start checking the docs, configs, etc. to
see what I can discover.

>
> nate
> <snip sig stuff>

Thanks for the time and thoughts Nate.

--
Bill

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-09-2008, 04:07 PM
"William L. Maltby"
 
Default Flaky desktop audio behavior.

On Mon, 2008-07-07 at 09:13 -0700, nate wrote:
> William L. Maltby wrote:
>
> > I feel it might be related to Jim's problem. I feel it might be a bug.
> >
> > Can anybody reproduce? I think the T'bird step is coincidental. I think
> > any sound played as another user should reproduce it. Hmmm ... I might
> > be assuming to much if I assume another user is significant.
> >
>
> I don't see why the desktop owner would be the only one that can play
> a sound. But in any case have you checked to see if the sound device
> is locked by another process? When I have sound issues I usually run
> lsof | grep /dev/dsp to see what, if anything is using the sound card

That returned nothing. So I ran it w/o the dsp and manually extracted
anything interesting. Got just these, which look normal.

mixer_app 10922 hardtolove 2u CHR 1,3
1604 /dev/null
escd 10926 hardtolove 0r CHR 1,3
1604 /dev/null

A ps yielded (501 = hardtolove) the below. The user that ran the T'bird,
which trumpeted mail arrival, was 502.

501 10906 1 0 07:35 ? 00:00:00 gnome-volume-manager
--sm-client -id default5
501 10922 1 0 07:35 ? 00:00:00 /usr/libexec/mixer_applet2
--oaf -activate-iid=OAFIID:GNOME_MixerApplet_Factory --oaf-ior-fd=20
501 10926 1 0 07:35 ? 00:00:00 ./escd
--key_Inserted="/usr/bin/ esc" --on_Signal="/usr/bin/esc"

Again, looking normal to me. That is *if* they should still be active,
which I assume is the case.

Looking to reduce the scope of investigation (or conversely expand it
beyond 5.2 a tad) I had booted this session with the previous (5.1)
kernel. And experienced the same problem. So it seems to not be 5.2
kernel related. This would seem to indicate that it is X/Gnome related
across 5.1 and 5.2 versions of libraries/applications.

A diff of the /proc/asound/ file contents from a previous normal
situation with the contents after this problem was replicated shows only
the kernel for significant differences.

432c432
< Kernel: Linux centos501.homegroannetworking 2.6.18-92.1.6.el5 #1 SMP
Wed Jun 25 13:49:24 EDT 2008 i686
---
> Kernel: Linux centos501.homegroannetworking 2.6.18-92.1.1.el5 #1 SMP
Sat Jun 21 19:04:27 EDT 2008 i686

Slowly continuing investigation as opportunities arise...



> and kill it. To me it sounds like thunderbird from the other user is
> accessing the sound card directly, perhaps preventing other apps from
> accessing it. Some desktop setups include a sound daemon like esd or

Clarification: the "other user" is me on the desktop, su'd to another
user in gnome-terminal and "nohup thunderbird&".

Since *real* id, as opposed to *effective* id, may have effect here, I
though I should mention it. Having done programming in many languages
over an extended time, and having seen the general level of competence
and attention to detail (the old 80/20 rule seem to apply), I don't
trust them to do it right all that consistently.

> karts(?), to facilitate multiple things accessing the sound card
> simultaneously, but I'm not sure what their capabilities/limitations
> are as I rarely if ever use them.
>
> nate
> <snip sig stuff>

--
Bill

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-09-2008, 05:17 PM
"nate"
 
Default Flaky desktop audio behavior.

William L. Maltby wrote:

> That returned nothing. So I ran it w/o the dsp and manually extracted
> anything interesting. Got just these, which look normal.

How about lsof | grep /dev/snd

I'm used to using OSS, which usually means /dev/dsp, it seems that ALSA
uses /dev/snd(or maybe another device..). I had a similar issue last
night where the flash plugin in firefox prevented Cedega from being
able to spit out sound and found it was using a device in /dev/snd, once
I stopped the flash plugin I got sound back(and even with the sound
device in use, XMMS was able to play sound no problem and it is configured
to use ALSA, as is Cedega).

Worst case just run lsof | grep /dev that's how I found the issue
last night, I wasn't sure what /dev device was in use.

> mixer_app 10922 hardtolove 2u CHR 1,3
> 1604 /dev/null
> escd 10926 hardtolove 0r CHR 1,3
> 1604 /dev/null

These reference /dev/null which isn't related.

nate

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-09-2008, 06:14 PM
"William L. Maltby"
 
Default Flaky desktop audio behavior.

On Wed, 2008-07-09 at 10:17 -0700, nate wrote:
> William L. Maltby wrote:
>
> > That returned nothing. So I ran it w/o the dsp and manually extracted
> > anything interesting. Got just these, which look normal.
>
> How about lsof | grep /dev/snd

In my visual, I was on the lookout for that (or any variation). BJIC,

It returned nothing also.

>
> I'm used to using OSS, which usually means /dev/dsp, it seems that ALSA
> uses /dev/snd(or maybe another device..). I had a similar issue last
> night where the flash plugin in firefox prevented Cedega from being
> able to spit out sound and found it was using a device in /dev/snd, once
> I stopped the flash plugin I got sound back(and even with the sound
> device in use, XMMS was able to play sound no problem and it is configured
> to use ALSA, as is Cedega).

I'll see if I can ID a plugin in the next pass.

>
> Worst case just run lsof | grep /dev that's how I found the issue
> last night, I wasn't sure what /dev device was in use.

That's how I found the below.

>
> > mixer_app 10922 hardtolove 2u CHR 1,3
> > 1604 /dev/null
> > escd 10926 hardtolove 0r CHR 1,3
> > 1604 /dev/null
>
> These reference /dev/null which isn't related.

I ignored the dev/null bit because I just wanted to see anything that
might be sound related that was running.

> <snip sig stuff>

--
Bill

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-09-2008, 06:25 PM
"nate"
 
Default Flaky desktop audio behavior.

William L. Maltby wrote:
>

> I'll see if I can ID a plugin in the next pass.

The plugins themselves won't show up, in my case it just said firefox
was using it. And I recall getting audio from flash earlier in the
day so thought it still might be using it, and I happened to be right,
after disabling the plugin the lock on the device was released.

Since nothing is using the sound device, I'm not sure what else to
check, short of permissions, at one point a few years ago it wasn't
uncommon for the permissions of devices such as sound devices etc
to get automatically changed to the person logged in. Not sure what
caused it or why, or if anything still does it anymore. But if your
user doesn't have access to the device I would think similar behavior
would occur.

So, check permissions on /dev/snd/* and /dev/dsp, another thing I do
to test is run a command line program that generates a sound(I
use mpg123 out of habbit which plays mp3 files), and see if you
notice any permission denied type errors.

nate


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-09-2008, 07:20 PM
"William L. Maltby"
 
Default Flaky desktop audio behavior.

On Wed, 2008-07-09 at 11:25 -0700, nate wrote:
> William L. Maltby wrote:
> >
>
> > I'll see if I can ID a plugin in the next pass.
>
> The plugins themselves won't show up, in my case it just said firefox
> was using it. And I recall getting audio from flash earlier in the
> day so thought it still might be using it, and I happened to be right,
> after disabling the plugin the lock on the device was released.
>
> Since nothing is using the sound device, I'm not sure what else to
> check, short of permissions, at one point a few years ago it wasn't
> uncommon for the permissions of devices such as sound devices etc
> to get automatically changed to the person logged in. Not sure what
> caused it or why, or if anything still does it anymore. But if your
> user doesn't have access to the device I would think similar behavior
> would occur.

Well, that was involved partly. The other user owned all the
devices /dev/{gpmctl,mixer,audio,adsp,snd} *and* floppies, HD,
nvidia, ...

So I ran

find /dev -user bill -exec chown hardtolove {} ;

which I really shouldn't (I know better). But that did provide a small
gain.

I can now open the Volume Control Panel (for a lurking friend, that is
VCP ;-)

I still can't open the volume slider that drops down from the little
speaker icon. So something is better, something still not fixed.

>
> So, check permissions on /dev/snd/* and /dev/dsp, another thing I do
> to test is run a command line program that generates a sound(I
> use mpg123 out of habbit which plays mp3 files), and see if you
> notice any permission denied type errors.

Will do. Signing off to find out where I can get mpg123. I think I'll
pop a CD in again first and see what I can doo-dah, doo-dah with that.

BRB

>
> nate
> <snip sig stuff>

Thanks for following up!
--
Bill

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-09-2008, 07:45 PM
"William L. Maltby"
 
Default Flaky desktop audio behavior.

On Wed, 2008-07-09 at 15:20 -0400, William L. Maltby wrote:
> On Wed, 2008-07-09 at 11:25 -0700, nate wrote:
> ><snip>

> Well, that was involved partly. The other user owned all the
> devices /dev/{gpmctl,mixer,audio,adsp,snd} *and* floppies, HD,
> nvidia, ...
>
> So I ran
>
> find /dev -user bill -exec chown hardtolove {} ;
>
> which I really shouldn't (I know better). But that did provide a small
> gain.
>
> I can now open the Volume Control Panel (for a lurking friend, that is
> VCP ;-)
>
> I still can't open the volume slider that drops down from the little
> speaker icon. So something is better, something still not fixed.
>
> >
> > So, check permissions on /dev/snd/* and /dev/dsp, another thing I do
> > to test is run a command line program that generates a sound(I
> > use mpg123 out of habbit which plays mp3 files), and see if you
> > notice any permission denied type errors.
>
> Will do. Signing off to find out where I can get mpg123. I think I'll
> pop a CD in again first and see what I can doo-dah, doo-dah with that.
>
> BRB

Ahhhhh! Music to my ears!

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!)

So, I suspect we have achieved bug nirvana. ISTM that the problem is
isolated to Gnome or it's interface to the system *or* a failure in some
OS component.

1) Gave (properly?) ownership of the devices to a user other than the
desktop owner (NB: *if* it is legal for a user other than desktop owner
to use the facilities because the user is "in the desktop", being
invoked from a Gnome terminal, then the device ownership should be given
to the user of the device, just as with tty devices).
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.
3) When ownership of the devices were manually changed to root owner,
*part* of the desktop facilities began operating normally.
4) Only part not working now is the volume control application out of
the speaker icon on my panel.
5) As you suspected, lookie here!

# cd ~hardtolove;find . -user bill -ls
16646219 7948 -rwxr-xr-x 1 bill bill 8119784 Nov 20
2007 ./firefox/plugins/libflashplayer.so
16646218 8 -rw-r--r-- 1 bill bill 856 Dec 15
2006 ./firefox/plugins/flashplayer.xpt

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.


Anyway, with your (and all the others too) help, we have a reproducible
situation and some clues.

Before I write a bug report (after seeing that one doesn't exist),
anything else you think I could look for or try?

>
> >
> > nate
> ><snip sig stuff>

Thanks again,
--
Bill

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-09-2008, 08:32 PM
"nate"
 
Default Flaky desktop audio behavior.

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 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.

> 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.

> 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..

> 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.

nate

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 10:20 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org