Anders Torger wrote: > > 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.
Yes, I buy that. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ------------------------------------------------------- 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
