[alsa-devel] paravirtualized alsa kernel driver for XEN
david.henningsson at canonical.com
Tue Mar 20 10:52:10 CET 2012
On 03/19/2012 06:15 PM, Stefano Panella wrote:
> 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:
> 1) 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?
> 2) 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
> 3) 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.
> 4) 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
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.
David Henningsson, Canonical Ltd.
More information about the Alsa-devel