[alsa-devel] dsnoop issues

[Jaroslav Kysela]

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?

						Jaroslav

-----
Jaroslav Kysela <perex at suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs