This series of patches was inspired by recent threads on the alsa mailing list, as well issues detected with existing and upcoming hardware:
- there was a request from the PulseAudio community to get more
information from drivers to make rewinds safer. While the conclusion was that it's nearly impossible for a driver developer to provide this information, there are however ways to assess the granularity of the hw_ptr updates using timestamping capabilities, and indirectly understand how safe rewinds might be.
How long do the application need to measure the granularity of the hw_ptr updates ?
Are there limitation using wallclock ?
It seem that audio_time.c is hardcoded to use 48000Hz which is the hda link rate, do the measurement still valid when application use 44100Hz ?
As hda controller only know the timimg up to hda link, those codec delay seem not exposed to the user space
7.3.4.5 Audio Function Group Capabilities The Audio Parameter returns a set of bit fields describing the audio capabilities of the Audio Function.
Input Delay is a 4-bit value representing the number of samples between when the sample is received as an analog signal at the pin and when the digital representation is transmitted on the High Definition Audio Link. This may be a “typical” value. If this is 0, the widgets along the critical path should be queried, and each individual widget must report its individual delay.
Output Delay is a four bit value representing the number of samples between when the sample is received from the Link and when it appears as an analog signal at the pin. This may be a “typical” value. If this is 0, the widgets along the critical path should be queried, and each individual widget must report its individual delay.
snd-hda-intel seem only expose widget delay in hda_proc.c
7.3.4.6 Audio Widget Capabilities
Delay indicates the number of sample delays through the widget. This may be 0 if the delay value in the Audio Function Parameters is supplied to represent the entire path.
- There was also a request to add a start_at capability based either
on system hr timers or a wall clock, which requires a means to expose both types of information to applications. Rather than adding new sets of timestamps, it is suggested the new start_at functionality relies on the new audio_timestamp definitions provided here.
Do the application need to set specific start threshold when usng start_at to prevent it start when buffer is full ?