On 03/19/2012 06:15 PM, Stefano Panella wrote:
Hi,
I am Stefano Panella, I am new to the list and I would like to take the opportunity to ask some questions since I am trying to write a paravirtualized alsa driver for XEN.
If all goes well I would also like to upstream it on linux.
I have been reading the documentation on "Writing an ALSA Driver" and I am still not completely clear on the meaning of the "pointer" callback in the pcm operations.
The description say:
"This callback is called when the PCM middle layer inquires the current hardware position on the buffer."
My question are:
- In case of a playback stream, is the pointer referring to wich sample
is currently playing on the DAC or to which is it the last frame read by the HW from the alsa memory buffer?
- What does the pointer mean in case of a capture stream? Is it the
position of the current frame on the ADC or is the latest frame written into the alsa buffer?
I'd say that for both, it is being used by applications to know what memory they can read from or write to. But other people here might know better.
- in case it is the frame on the DAC/ADC, what happens if the callback
does not return the real DAC/ADC frame position but an approximate value, let say rounded to 64 frames only?
For the JACK sound server, I think it only needs to be as accurate as the period (i e if you have 4 periods with 64 samples each, you need to be able to return 0, 64, 128 and 192).
For PulseAudio it's worse. The worse granularity, the more difficult for PulseAudio to have low-latency operation. PulseAudio also rewinds/rewrites the buffer occasionally and uses the pointer to know from when it should start rewriting.
- is there any test I could run to check I have implemented correctly
the "pointer" callback? Or any application which would need very high "pointer" precision like frame precision?
PulseAudio has an alsa-time-test application that relies heavily on the pointer callback being accurate. It's only for playback and I've never used it myself so I'm not completely sure about how to interpret the numbers.
In general, I believe PulseAudio (especially with timer-scheduling mode enabled) stress tests the driver quite hard and as such it is sometimes being used as a measure to see if the audio driver is successful. :-)
Hopefully this provides some initial insights.