On 06/06/16 02:24, Raymond Yau wrote:
http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=cf40ea169aad366b2...
HDA has hardware specific feature (audio wallclock) for the timestamp and period wakeup can be disabled
only a few pci drivers which read the residue value from hardware register (e.g. hda-intel, oxygen , .) you have to measure the granularity since the unit may be different for usb, pcie and firewire sound card
Thank you Raymond. Yes, (I think) I understand all that. Let me restate my understanding of the situation.
The pointer position will generally be inaccurate by up to a period size. Even when a driver claims to support DMA_RESIDUE_GRANULARITY_BURST, the reported data is still unlikely to be sample accurate (as the size of a burst is undefined). For most drivers the reported position will be inaccurate and the actual accuracy cannot be determined.
The delay is also likely to be inaccurate. It is intended that this could include things such as codec delay but for most drivers this is not included. A few drivers, and in particular USB via an estimate, do try to include the in-flight transfer delay. In some ways this is the worst case: the delay may or may not include the transfer delay AND may or may not include the codec delay; what it actually includes is unknown.
The result of these is that both the position and delay may be inaccurate and the degree to which this is the case is not known.
We can tell that the position has not changed since the last call to snd_pcm_update_hw_ptr0() because new_hw_ptr == old_hw_ptr. We can use this knowledge to adjust the audio_tstamp returned by the time elapsed since the previous call (for SNDRV_PCM_AUDIO_TSTAMP_TYPE_DEFAULT). We can also make such an adjustment even if the position has changed to better deal with the inaccuracy of position reporting.
Because of the 2 different types of unknown accuracy in delay, we cannot do the same trick with this. In many ways being able to update the delay in this way would be ideal. If we could, then we could leave audio_tstamp alone and let audio_tstamp_config.report_delay determine if the adjusted delay is also included in that. Since, in practice, most drivers either contain no codec delay value of a constant one, we can still use such a mechanim for most practical cases.
Have I got anything wrong above?
I'm going to test a revised patch based on these assumptions.
as the application is based on the pointer for read/write, you still need to use small period size and CPU power if you want to determine the value returned by snd_pcm_rewindable is safe or not
My point is that I want to find a way to get reported delay and/or audio timestamps that are more accurate that a period time even in the absence of hardware that has specific support for this.
Alan.