Subject: Re: [linux-audio-dev] [ANN] AlsaPlayer 0.99.52-cvs20011126-jack
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue Nov 27 2001 - 22:47:58 EET
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
This archive was generated by hypermail 2b28 : Tue Nov 27 2001 - 22:45:17 EET