[alsa-devel] dsnoop issues
perex at suse.cz
Fri Apr 27 15:46:54 CEST 2007
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
Jaroslav Kysela <perex at suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
More information about the Alsa-devel