[alsa-devel] [Pkg-alsa-devel] Bug#438118: alsa-utils: aplay non-blocking mode isn't working

Takashi Iwai tiwai at suse.de
Fri Dec 14 13:41:07 CET 2007


At Fri, 14 Dec 2007 11:53:11 +0100 (CET),
Jaroslav Kysela wrote:
> 
> On Fri, 14 Dec 2007, Anders Boström wrote:
> 
> > >>>>> "TI" == Takashi Iwai <tiwai at suse.de> writes:
> > 
> >  TI> OK, thanks, I see the problem now.
> >  >> 
> >  TI> I don't remember whether it's a feature or a bug.  The drain ioctl
> >  TI> rejects the non-block mode.
> >  >> 
> >  >> I can understand the idea here, that in non-blocking mode, no call
> >  >> should block, ever. But on the other hand, if you call the drain
> >  >> ioctl, you probably expect it to work, even in non-blocking mode. Why
> >  >> would you otherwise call it?
> > 
> >  TI> Yes, that's my opinion, too.  This particular ioctl is to block the
> >  TI> operation, so it should be allowed as long as it's called.
> > 
> >  TI> But I vaguely remember that we discussed about it, and the current
> >  TI> form is the result of that.  Namely, we can call
> >  TI> snd_pcm_nonblock(FALSE) explicitly before calling snd_pcm_drain().
> > 
> >  TI> Though, I prefer fixing the behavior in the core side to allow the
> >  TI> blocking with this call...  Any reasonable objections in mind?
> > 
> > Any progress in including a solotion to this bug in mainstream
> > alsa & linux kernel? Has anything been done? The patch works fine for
> > me...
> 
> I think that this proposal breaks basic posix rules.

AFAIK, O_NONBLOCK doesn't define the behavior of each ioctl on POSIX
at all.  Some standard POSIX-defined ioctls block even with O_NONBLOCK
indeed.

> Application should 
> change blocking state itself. And non-blocking snd_pcm_drain() still makes 
> sense - it will return state of stream (-EAGAIN - unfinished) or reset PCM 
> state to SETUP in case when all data are played.

Well, this can be kept as is, but it's a bit weird (and silly)
behavior.  Anyway, we'll need fix this bug in our own codes in
alsa-utils first :)


Takashi


More information about the Alsa-devel mailing list