[alsa-devel] [PATCH RFC 0/9] audio timestamping evolutions

[Raymond Yau]

>
> This series of patches was inspired by recent threads on the alsa
> mailing list, as well issues detected with existing and upcoming
> hardware:
>
> 1. 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.

>
> 2. 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 ?