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. With non-blocking mode it works, you fill the buffer and currently you wait for EPIPE, with the new behaviour you would wait for EAGAIN instead. The (1) alternative is then more flexible in terms of application design. Changing the behaviour would of course break your example application if it specifically checks for EPIPE (and not just a generic error). /Anders Torger ------------------------------------------------------- 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
