On Thursday 10 October 2002 16.21, Jaroslav Kysela wrote: > On Thu, 10 Oct 2002, Anders Torger wrote: > > On Thursday 10 October 2002 04.15, James Courtier-Dutton wrote: > > > I don't understand which applications prefer: - > > > 1) "PREPARED: return POLLOUT until the buffer is full, then > > > return POLLERR." and which would prefer (as suggested): - > > > 2) "PREPARED: return POLLOUT until the buffer is full, then > > > BLOCK." > > > > > > As I understand it, the poll works correctly in RUNNING state? > > > I think (2) would basically kill all single thread apps so on > > > balance, I think (1) is the best to go with for now. > > > > > > The application I have thought of is that an application might > > > want to fill many file handles/streams buffers but keep them in > > > PREPARED state. Then release all the channels at the same time so > > > that they play in sync. But for that one does not need to do any > > > polling in PREPARED state. One just does snd_pcm_write until one > > > gets an error. > > > > This is possible to do with (1) as well, actually it is only a > > slight difference. You will need to have non-blocking write in the > > above example, or else you are not sure that you fill the buffer at > > all, for example if the output buffer is 2048 frames, and you try > > to write 4096, which currently returns an error in blocking mode, > > but still the output buffer will be empty. > > Not true. The output buffer will be filled up and then EPIPE error > will be returned. So first write 4096 results with 2048 and second > with EPIPE.
Uhmm... but if you use my own write() call wrappers, then my description is correct... eh... I guess I have used them too much :-) Anyway, it still is possible to do the given scenario with (1), but you need to put the file descriptor into non-blocking mode first of course. /Anders ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
