On Wednesday 09 October 2002 15.28, you wrote: > Clemens Ladisch wrote: > >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 > > Why would the buffer get full in PREPARED state ? > Surely any sensible, "start_threshold" should cause the state to > change to RUNNING before the buffer is full. > I can't see any reason to not to use "start_threshold" in order to > get from PREPARED to RUNNING.
Because another thread that should start the card is not ready yet. In threaded programming it may be fully natural to first fill the output buffer and then start the card from another thread. Of course, you can always adapt to how it works (for example if there would always be a start threshold which could not be changed), but it is best if poll() works in a way that is expected, and is conforming to standards. If poll() behaviour is changed to the proposed, we will not only get a more clear standard conformance (what is conforming or not is however always a question of interpretation, since there is no relevant standard that directly relates to sound cards), but a more flexible API in terms of how to design your multi-threaded/process applications. /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
