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@xxxxxxx> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
