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.