[alsa-devel] dsnoop issues

[Takashi Iwai]

At Fri, 27 Apr 2007 15:46:54 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> On Fri, 27 Apr 2007, Takashi Iwai wrote:
> 
> > At Fri, 27 Apr 2007 15:18:53 +0200 (CEST),
> > Jaroslav Kysela wrote:
> > > 
> > > On Fri, 27 Apr 2007, Takashi Iwai wrote:
> > > 
> > > > At Fri, 27 Apr 2007 15:00:22 +0200 (CEST),
> > > > Jaroslav Kysela wrote:
> > > > > 
> > > > > On Fri, 27 Apr 2007, Takashi Iwai wrote:
> > > > > 
> > > > > > Actually, the documentation is wrong, IMO.  The typical behavior of
> > > > > > read syscall is that it returns a value actually read by that call.
> > > > > > It doesn't guarantee whether the requested size is filled, and can be
> > > > > > shorter than requested.  As snd_pcm_readi() emulates the read syscall,
> > > > > > it should behave in that way.
> > > > > 
> > > > > I don't think so completely. For blocking mode (!O_NONBLOCK), all possible 
> > > > > data should be read. Only signal or an error should break this.
> > > > > 
> > > > > The read logic for dsnoop is in snd_pcm_read_areas() in pcm/pcm.c 
> > > > > (alsa-lib).
> > > > 
> > > > In the current implementation, it may work in that way.  But, in
> > > > general, I'm against such a condition.  It's not what read syscalls
> > > > does, so there is no real reason that snd_pcm_readi() should do so.
> > > 
> > > Well 'man 2 read' exactly explains when a less count than requested might 
> > > be returned for blocking behaviour. I'm missing something? Of course, 
> > > applications should not expect to read all possible frames, but under 
> > > normal conditions, less count should be returned in rare cases (for 
> > > the blocking mode, of course).
> > 
> > The below from man page:
> > 
> > ================
> > RETURN VALUE
> >        On success, the number of bytes read is returned (zero indicates end of
> >        file), and the file position is advanced by this number.  It is not  an
> >        error  if  this  number  is smaller than the number of bytes requested;
> >        this may happen for example because fewer bytes are actually  available
> >        right  now  (maybe  because we were close to end-of-file, or because we
> >        are reading from a pipe, or from a terminal),  or  because  read()  was
> >        interrupted  by  a  signal.
> > ================
> > 
> > So, when fewer bytes are actually available at the moment read gets
> > called, it may return a shorter value.
> 
> The problem is that in this way, there won't be any difference between 
> blocking I/O and non-blocking I/O. I understand situation for pipes, but
> we can wait to get other samples and if application wants to block, why 
> not block?

I think it's a difference between zero and fewer bytes.  When nothing
is available, it should block.  After all, the blocking behavior isn't
strictly defined.  I guess it's rather loose in many real
implementations.

What I'm suggesting here is not to change the current semantics in
alsa-lib, but just to remove the sentense in the document.  It's not a
standard guarantee for read although we suppose to do that.


Takashi