Anders Torger wrote: >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 > > > Ok, as far as Iam concerned, my application will not care. It never reaches the "PREPARED, buffer full" state because I use "start_threshold". Although my application is multi-treaded, all the audio out happens in a single thread. Other threads do the grabbing the data of the hard disk etc. and buffering it in memory.
I do think that any poll should block unless data can be written to the file handle irrespective of the BLOCK/NON-BLOCK status of the file handle. BLOCK/NON-BLOCK should only effect open and write calls, not poll calls. 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. I guess the solution to all this would be to provide two different poll/snd_pcm_wait calls so the application writer can choose which behaviour they want. This would then make everyone happy, and also not break any old apps. Another solution is for the application writer to use the pthreads "pthread_cond_wait()" to get one thread to wait until another thread has done some work. Then alsa would not have to change at all. ;-) Cheers James ------------------------------------------------------- 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
