[alsa-devel] dsnoop issues

[Takashi Iwai]

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.


Takashi