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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
