On Wednesday 09 October 2002 09.52, Clemens Ladisch wrote: > Abramo Bagnara wrote: > > Clemens Ladisch wrote: > > > Abramo Bagnara wrote: > > > > The point is that stream is in bad state wrt read/write, this > > > > is the reason why poll should return POLLERR. > > > > > > I think the stream is _not_ in a bad state because one buffer of > > > data can (and has) be written. The reason for not allowing > > > further writes is that the buffer is full, and not that the > > > device wouldn't accept any data at all. This is similar to the > > > behaviour of a pipe with the reading end opened by an application > > > which currently doesn't read from the pipe, in contrast to a pipe > > > with the read end not opened at all. > > > > ??? With this message now I'm very confused about what you wish... > > I changed my mind about how the POSIX standard fits to our problem > case. > > > Can you resume to me the comparison between current and wanted > > behaviour wrt poll for both playback and capture. > > The behaviour of polling during capture is just fine: > > RUNNING: block until avail_min is available, then return POLLIN > DRAINING: return POLLIN until buffer is empty, then return POLLERR > (other states: POLLERR) > > The current behaviour for playback is: > > PREPARED: return POLLOUT until the buffer is full, then return > POLLERR RUNNING: block until avail_min can be written, then return > POLLOUT DRAINING: block (until state changes) > (other states: POLLERR) > > I want the behaviour in the PREPARED state to be similar to the > RUNNING state, i.e. return POLLOUT until the buffer is full, then > block.
Why not have the same behaviour for polling during capture? Reading from a not-yet-started sound card is useful in the same way that writing to a not-yet-started sound card is useful. Perhaps especially in low-latency multi-threaded applications, when you want to start reading (or writing) as soon as possible after the sound card has been started (this can be accomplished in other ways of course). If poll keeps returning POLLERR it is no use. Blocking in both cases is better, and in my humble opinion more logical behaviour. I don't think having a special case for the prepared state in read or write is useful. /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
