Re: [PATCH RFC 0/9] audio timestamping evolutions

[Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>]

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:
>  >
>  > 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 ?

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

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.


_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel