jaroslav - this happens on several different "consumer" audio interfaces. an application waiting in poll(2) will return, but snd_pcm_avail_update() and snd_pcm_mmap_begin() will report only a single (or very small number of) frames available. do you consider this an error, or should an application be prepared to deal with it?
its not clear how it can efficiently deal with it, btw. processing a single frame of audio doesn't scale, and returning back to poll(2) won't help, since the device will still be readable/writable (we'll basically be busy-waiting on the available count rising to a satisfactory number. any ideas? is there some sw-param that will stop this from happening? it feels like a miscalculation to me. i note that something similar occurs with the hammerfall, except that in that case, we get a series of return from poll(2) at the "half-period" points, which is also problematic. with my trident, this kind of behaviour is very common when the device is first opened, and it then stabilizes after a few seconds. with some other cards, it never seems to stabilize: [ from andy lo-a-foe ] >calles where nframes is 1. I did some statistics over 5000 calls for 64 >frames per interrupt. Roughly 45% of the calls are with nframes around >64, another 45% around 1, the remaining % is evenly distributed inbetween thes >e 2 values. Doesn't this make it very inefficient? --p _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
