Re: sound: -EPERM on first mplayer invocation

[Takashi Iwai <tiwai@suse.de>]

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