Messages in this thread | | | Date | Wed, 05 Aug 2009 07:41:52 +0200 | From | Takashi Iwai <> | Subject | Re: sound: -EPERM on first mplayer invocation |
| |
At Wed, 05 Aug 2009 07:37:30 +0200, I wrote: > > At Wed, 5 Aug 2009 04:32:34 +0200, > Denys Vlasenko wrote: > > > > On Tuesday 04 August 2009 11:16, Takashi Iwai wrote: > > > > > > For a long time I observe the following nuisance: > > > > > > when I run mplayer for the very first time after boot, > > > > > > I can't adjust the volume. mplayer spews this to stderr: > > > > > > > > > > > > alsa-control: error setting left channel, Operation not permitted > > > > > > > > > > > > This happens even if I login as root and run mplayer as root. > > > > > > > > > > > > I tracked it down to snd_ctl_elem_write in sound/core/control.c > > > > > > > > > > ... > > > > > > > > > > > > Thus, vd->owner != file. > > > > > > > > > > > > As I said, it only happens on very first run of mplayer, > > > > > > and it isn't a recent change, I think I saw it at least > > > > > > for one year with different kernels. > > > > > > > > > > > > Takashi, any idea what might be happening here? > > > > > > How can I help you more with tracking it down? > > > > > > > > > > This implies that another process (e.g. a sound daemon like PA) > > > > > already opened the device and locked this specific control element. > > > > > If so, this is no bug but the right behavior. > > > > > Check "fuser /dev/snd/controlC*". > > > > > > > > Nothing uses them: > > > > > > > > shadow:~# lsof -nP | grep '/dev/.*control' > > > > shadow:~# fuser /dev/snd/controlC* > > > > shadow:~# > > > > > > > > I tried running bare X with only xterm and mplayer, > > > > > > Hm, but according to your debug session, the vd->owner is set > > > to a different value, right? Check vd->owner_pid in the error path. > > > It'll show the pid blocking that control element. > > > > I modified 2.6.31-rc2 source as follows: > > > > static int snd_ctl_elem_write(struct snd_card *card, struct snd_ctl_file *file, > > struct snd_ctl_elem_value *control) > > { > > struct snd_kcontrol *kctl; > > struct snd_kcontrol_volatile *vd; > > unsigned int index_offset; > > int result; > > > > down_read(&card->controls_rwsem); > > kctl = snd_ctl_find_id(card, &control->id); > > if (kctl == NULL) { > > result = -ENOENT; > > } else { > > index_offset = snd_ctl_get_ioff(kctl, &control->id); > > vd = &kctl->vd[index_offset]; > > if (file && vd->owner) > > printk("file:%p vd->owner:%p\n", file, vd->owner); > > if (!(vd->access & SNDRV_CTL_ELEM_ACCESS_WRITE) || > > kctl->put == NULL || > > (file && vd->owner && vd->owner != file)) { > > if (file && vd->owner) > > printk("vd->owner_pid:%d vd->owner->pid:%d file->pid:%d\n", vd->owner_pid, vd->owner->pid, file->pid); > > result = -EPERM; > > } else { > > ... > > > > and when I start mplayer, I see this: > > > > dmesg: > > file:ffff8800798af940 vd->owner:ffff8800798af940 > > file:ffff8800798af940 vd->owner:ffff8800798af940 > > > > I assume it's some sort of initialization, no EPERM here. > > Then I press "lower the volume" key (keypad "/") > > in mplayer window, twice: > > > > dmesg: > > file:ffff8800798af8c0 vd->owner:ffff8800798af940 > > vd->owner_pid:0 vd->owner->pid:2067 file->pid:2067 > > file:ffff8800798af740 vd->owner:ffff8800798af940 > > vd->owner_pid:0 vd->owner->pid:2067 file->pid:2067 > > The file instances are different. It implies that mplayer opens the > device at each time but doesn't close. > It sounds like a bug in mplayer to me.
... or the first control handle keeps opened and blocks it. A question is how is your PCM configuration and which control element is locked? The latter can be seen by adding a printk of kctl->id.name.
Takashi
| |