Clemens Ladisch wrote: > > 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.
Please reread with me SusV3: POLLOUT: Normal data may be written without blocking. When buffer is not full we have to return POLLOUT, but when buffer is full the point is *not* that file cannot be written without blocking, the point is that file cannot be written (because we'd return an error) See? Now the point is another: it's correct to return an error when buffer is full or it's better to block? My answer is that proposed behaviour is illogical if the programmer take in account single-threading (i.e. my application have exclusive control of PCM): - in blocking mode we should delay (waiting for what?) - in nonblocking mode we should return -EAGAIN (why try again?) OTOH I agree that if the programmer consider multi-threading all the illogicity goes away. I think this could be faced with an appropriate documentation. I've still some residual doubts: - how many applications out there we will break? - I'm almost sure that alsa-lib need to be changed in several places to follow this: who will do that? I'm thinking expecially to PCM chains and pcm_share. Ok, iff: - Jaroslav agrees too - somebody do the patch for write *and* poll, correct the documentation and add a special paragraph explaining multithreading POV, correct alsa-lib and test *all* the PCM classes you'll have my vote (FWIW of course ;-). Thanks for your patience anyway. -- 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
