Hi,
When the kernel reports current (playback) delay via a call to
snd_pcm_status() or snd_pcm_delay() for a normal hardware PCM, then the
delay value reported is the sum of space used in the ring buffer plus
any delay reported from the underlying runtime driver.
snd_pcm_dshare_status() and snd_pcm_dshare_delay() discard this
refinement and simply report the use of some ring buffer. Why does it do
this and how could the reporting be improved? In particular I am
struggling to understand the relationship between a dshare instance's
(view of a) ring buffer and the slave (hw) PCM's ring buffer.
I understand that the *slowptr* configuration item can be set to get
more accurate position updates as part of this reporting but I get the
feeling that this will not on its own solve the problem. If it did then
one could simply use the delay value reported by the slave PCM.
The context of these questions is using dshare to expose 4 logical
stereo devices on a platform using an ARM-based SoC with a single
8-channel hardware driver. I need to get the same level of delay report
accuracy as I would do without using dshare.
Alan.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
