snd_pcm_poll_descriptors() error return

snd_pcm_poll_descriptors() error return

[Alan Horstmann]

Hi,

A user of the Portaudio library is reporting that from Alsa version 1.1.4 the 
function snd_pcm_poll_descriptors() can return -32 (Broken Pipe), and this 
fails an assert within Portaudio.  Earlier 1.1.3 does not seem to  show this 
issue.  For more details, see 
https://app.assembla.com/spaces/portaudio/support/tickets/268.

The Alsa docs don't mention any possible negative error code from this 
function - has the behaviour changed, or is it likely something else is 
triggering the difference?

Regards

Alan

Re: snd_pcm_poll_descriptors() error return

[Takashi Sakamoto]

Hi,

On Oct 02 2018 06:23, Alan Horstmann wrote:
> A user of the Portaudio library is reporting that from Alsa version 1.1.4 the
> function snd_pcm_poll_descriptors() can return -32 (Broken Pipe), and this
> fails an assert within Portaudio.  Earlier 1.1.3 does not seem to  show this
> issue.  For more details, see
> https://app.assembla.com/spaces/portaudio/support/tickets/268.
> 
> The Alsa docs don't mention any possible negative error code from this
> function - has the behaviour changed, or is it likely something else is
> triggering the difference?

Return values from a call of 'snd_pcm_poll_descriptors()' varies
depending on implementation of PCM plugins for used PCM node. Therefore
it's impossible to cover all of the values in documentation.

In a design of alsa-lib, 'snd_pcm_poll_descriptors()' is a thin wrapper
of '.poll_descriptors' callback of internal/external structure of PCM
plugins, therefore its behaviour is dynamically different depending on
each implementation.

For example, when using 'hw' PCM node directly, a call of this function
can returns '-ENOMEM' or '2':
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/pcm/pcm_hw.c;h=59a242009e9f5f1098759305499eaa27bef6c1ab;hb=HEAD#l227

When using 'dmix' PCM node, '-EIO', '0', '-EPIPE' and '1':
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/pcm/pcm_direct.c;h=2b07eff90ff6e12200e27a0d40378f29a7bf0d24;hb=HEAD#l668

When using PCM node with external PCM plugins such as 'pulse',
'snd_pcm_ioplug_create()' is called to instantiate plugin structure,
and a call of 'snd_pcm_poll_descriptors()' can return '-EIO', '0', '1',
and value depending on plugin implementation.
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/pcm/pcm_ioplug.c;h=881a1a85adaf09b4732375e2161b0a1ebb53900f;hb=HEAD#l772

When having good discussion to investigate cause, discover solution for
this kind of issues, you need to identify which PCM node triggers the
issue, at least.


Regards

Takashi Sakamoto

Re: snd_pcm_poll_descriptors() error return

[Takashi Iwai]

On Tue, 02 Oct 2018 01:32:10 +0200,
Takashi Sakamoto wrote:
> 
> Hi,
> 
> On Oct 02 2018 06:23, Alan Horstmann wrote:
> > A user of the Portaudio library is reporting that from Alsa version 1.1.4 the
> > function snd_pcm_poll_descriptors() can return -32 (Broken Pipe), and this
> > fails an assert within Portaudio.  Earlier 1.1.3 does not seem to  show this
> > issue.  For more details, see
> > https://app.assembla.com/spaces/portaudio/support/tickets/268.
> >
> > The Alsa docs don't mention any possible negative error code from this
> > function - has the behaviour changed, or is it likely something else is
> > triggering the difference?
> 
> Return values from a call of 'snd_pcm_poll_descriptors()' varies
> depending on implementation of PCM plugins for used PCM node. Therefore
> it's impossible to cover all of the values in documentation.
> 
> In a design of alsa-lib, 'snd_pcm_poll_descriptors()' is a thin wrapper
> of '.poll_descriptors' callback of internal/external structure of PCM
> plugins, therefore its behaviour is dynamically different depending on
> each implementation.
> 
> For example, when using 'hw' PCM node directly, a call of this function
> can returns '-ENOMEM' or '2':
> http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/pcm/pcm_hw.c;h=59a242009e9f5f1098759305499eaa27bef6c1ab;hb=HEAD#l227
> 
> When using 'dmix' PCM node, '-EIO', '0', '-EPIPE' and '1':
> http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/pcm/pcm_direct.c;h=2b07eff90ff6e12200e27a0d40378f29a7bf0d24;hb=HEAD#l668
> 
> When using PCM node with external PCM plugins such as 'pulse',
> 'snd_pcm_ioplug_create()' is called to instantiate plugin structure,
> and a call of 'snd_pcm_poll_descriptors()' can return '-EIO', '0', '1',
> and value depending on plugin implementation.
> http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/pcm/pcm_ioplug.c;h=881a1a85adaf09b4732375e2161b0a1ebb53900f;hb=HEAD#l772
> 
> When having good discussion to investigate cause, discover solution for
> this kind of issues, you need to identify which PCM node triggers the
> issue, at least.

Yes, this function may return an error code, and it's the defined
behavior from the beginning.  So, please fix the error handling in the
application side.


thanks,

Takashi

Re: snd_pcm_poll_descriptors() error return

[Alan Horstmann]

On Tuesday 02 October 2018 16:38, Takashi Iwai wrote:
> On Tue, 02 Oct 2018 01:32:10 +0200,
>
> Takashi Sakamoto wrote:
> > Hi,
> >
> > On Oct 02 2018 06:23, Alan Horstmann wrote:
> > > A user of the Portaudio library is reporting that from Alsa version
> > > 1.1.4 the function snd_pcm_poll_descriptors() can return -32 (Broken
> > > Pipe), and this fails an assert within Portaudio.  Earlier 1.1.3 does
> > > not seem to  show this issue.  For more details, see
> > > https://app.assembla.com/spaces/portaudio/support/tickets/268.
> > >
> > > The Alsa docs don't mention any possible negative error code from this
> > > function - has the behaviour changed, or is it likely something else is
> > > triggering the difference?
> >
> > Return values from a call of 'snd_pcm_poll_descriptors()' varies
> > depending on implementation of PCM plugins for used PCM node. Therefore
> > it's impossible to cover all of the values in documentation.
> >
> > In a design of alsa-lib, 'snd_pcm_poll_descriptors()' is a thin wrapper
> > of '.poll_descriptors' callback of internal/external structure of PCM
> > plugins, therefore its behaviour is dynamically different depending on
> > each implementation.
> >
> > For example, when using 'hw' PCM node directly, a call of this function
> > can returns '-ENOMEM' or '2':
> > http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/pcm/pcm_hw.c;h=5
> >9a242009e9f5f1098759305499eaa27bef6c1ab;hb=HEAD#l227
> >
> > When using 'dmix' PCM node, '-EIO', '0', '-EPIPE' and '1':
> > http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/pcm/pcm_direct.c
> >;h=2b07eff90ff6e12200e27a0d40378f29a7bf0d24;hb=HEAD#l668
> >
> > When using PCM node with external PCM plugins such as 'pulse',
> > 'snd_pcm_ioplug_create()' is called to instantiate plugin structure,
> > and a call of 'snd_pcm_poll_descriptors()' can return '-EIO', '0', '1',
> > and value depending on plugin implementation.
> > http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/pcm/pcm_ioplug.c
> >;h=881a1a85adaf09b4732375e2161b0a1ebb53900f;hb=HEAD#l772
> >
> > When having good discussion to investigate cause, discover solution for
> > this kind of issues, you need to identify which PCM node triggers the
> > issue, at least.
>
> Yes, this function may return an error code, and it's the defined
> behavior from the beginning.  So, please fix the error handling in the
> application side.

OK, thanks for that info - so we will have to check the function return more 
carefully than at present!  I appreciate the input from both of you on this.

Regards

Alan