On 12/9/14, 10:40 PM, Raymond Yau wrote:
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 ?
If you look at the examples, it's pretty clear that the granularity can be observed with a limited set of measurements, 10 queries or so. If you take longer measurements you will be tracking drift mainly.
Are there limitation using wallclock ?
The only limitation I can think of is that implementations need to watch out for wrap-around, i think in the HDAUdio case it means you need to have one interrupt or status query every 5mn, which is probably fine for most applications. Also the wall clock keeps ticking independently of the stream state, if the stream can be mixed, paused, resumed then the low-level driver should probably track the start position and compensate for it.
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 ?
If you use a wallclock then you really abstract away the actual sampling frequency and the transmission pattern discontinuity (12-11-11-12-11-11-12-11-11-11 pattern, with an invalid sample every 12 or 11 samples for HDAudio). It wouldn't matter if you transmitted 44.1 or 48kHz since they use the same wall clock ticks.
As hda controller only know the timimg up to hda link, those codec delay seem not exposed to the user space
The delay is reported by the timestamping logic if the codec driver provides it. my patches don't do any magic, they only report what is available. If the codec delay is not reported then that's too bad. feel free to contribute patches to correct this point if needed.
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 ?
These patches aren't mine but I would imagine that the buffer is full (pre-rolled) and ready to be played. The buffer fullness is probably not a criterion for starting a stream in that use case, the timestamp requested probably trumps everything else.