'multi' plugin signals POLLOUT but snd_pcm_avail_update() returns 0

'multi' plugin signals POLLOUT but snd_pcm_avail_update() returns 0

[Lennart Poettering]

Heya!

There's a apparently a bug in the 'multi' plugin. When it is used it
will pretty often signal POLLOUT when used with
snd_pcm_poll_descriptors_revents() and the subsequent call to
snd_pcm_update_avail() will still return 0. Doesn't look right to me.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: 'multi' plugin signals POLLOUT but snd_pcm_avail_update() returns 0

[Takashi Iwai]

At Sat, 25 Oct 2008 17:14:29 +0200,
Lennart Poettering wrote:
> 
> Heya!
> 
> There's a apparently a bug in the 'multi' plugin. When it is used it
> will pretty often signal POLLOUT when used with
> snd_pcm_poll_descriptors_revents() and the subsequent call to
> snd_pcm_update_avail() will still return 0. Doesn't look right to me.

Doesn't look right, indeed.
On which system setup does it happen?
Can you reproduce it via a combination of dummy driver so that I can
test it on my system, too?


thanks,

Takashi

Re: 'multi' plugin signals POLLOUT but snd_pcm_avail_update() returns 0

[Lennart Poettering]

On Mon, 27.10.08 09:24, Takashi Iwai (tiwai@suse.de) wrote:

> 
> At Sat, 25 Oct 2008 17:14:29 +0200,
> Lennart Poettering wrote:
> > 
> > Heya!
> > 
> > There's a apparently a bug in the 'multi' plugin. When it is used it
> > will pretty often signal POLLOUT when used with
> > snd_pcm_poll_descriptors_revents() and the subsequent call to
> > snd_pcm_update_avail() will still return 0. Doesn't look right to me.
> 
> Doesn't look right, indeed.
> On which system setup does it happen?

That's surround40:0 on SoundBlaster Live. Here's the debug output of
PA showing this:

https://bugzilla.redhat.com/attachment.cgi?id=321485

(Which belongs to https://bugzilla.redhat.com/show_bug.cgi?id=462200).

Ever line saying "ALSA woke us up to write new data to the device, but
there was actually nothing to write! Most likely this is an ALSA
driver bug. Please report this issue to the PulseAudio developers." is
where we get POLLOUT but update_avail() is 0.

Looking at it it might actually be the hooks module that is broken,
not necessarily "multi".

> Can you reproduce it via a combination of dummy driver so that I can
> test it on my system, too?

Uh. It's not my machine where this happened. But I can try to
reproduce that...

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: 'multi' plugin signals POLLOUT but snd_pcm_avail_update() returns 0

[Takashi Iwai]

At Mon, 27 Oct 2008 15:18:36 +0100,
Lennart Poettering wrote:
> 
> On Mon, 27.10.08 09:24, Takashi Iwai (tiwai@suse.de) wrote:
> 
> > 
> > At Sat, 25 Oct 2008 17:14:29 +0200,
> > Lennart Poettering wrote:
> > > 
> > > Heya!
> > > 
> > > There's a apparently a bug in the 'multi' plugin. When it is used it
> > > will pretty often signal POLLOUT when used with
> > > snd_pcm_poll_descriptors_revents() and the subsequent call to
> > > snd_pcm_update_avail() will still return 0. Doesn't look right to me.
> > 
> > Doesn't look right, indeed.
> > On which system setup does it happen?
> 
> That's surround40:0 on SoundBlaster Live. Here's the debug output of
> PA showing this:
> 
> https://bugzilla.redhat.com/attachment.cgi?id=321485
> 
> (Which belongs to https://bugzilla.redhat.com/show_bug.cgi?id=462200).
> 
> Ever line saying "ALSA woke us up to write new data to the device, but
> there was actually nothing to write! Most likely this is an ALSA
> driver bug. Please report this issue to the PulseAudio developers." is
> where we get POLLOUT but update_avail() is 0.
> 
> Looking at it it might actually be the hooks module that is broken,
> not necessarily "multi".

As far as I see, there is nothing special in the update_avail and
poll_* stuff of multi plugin.  It just calls avail_update of each
slave, and takes the minimum value.

A few considerations:

- 32bit process on 64bit kernel may have something wrong sync;
  but PA should be 64bit, too, right?

- forward/rewind might be buggy;
  relevant with command sequences?


thanks,

Takashi