Re: [PATCH v6 0/7] audio timestamping evolutions

[Takashi Iwai <tiwai@suse.de>]

At Fri, 13 Feb 2015 15:14:02 -0600,
Pierre-Louis Bossart 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.
> 
> 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 definition provides by these patches
> 
> 3. For new hardware, there is a neeed to let low-level drivers
> handle timestamping instead of having the ALSA core do
> it. Similarly there is a need to let the low-level driver update
> the initial estimate for the trigger timestamp if there are
> delays to start a stream (eg. with USB)
> 
> These patches try to provide an answer to these multiple needs by
> building on the work done two years ago to expose wall clock
> information to applications. The evolution is to let application
> select which audio timestamp they are interested in, track the delay
> and drifts between recurring measurements and get, when possible, an
> idea of the accuracy of the underlying hardware. A backwards compatible mode
> is provided in case userspace doesn't provide any timestamp selection (results
> based on HDAudio wallclock for playback, hw_ptr in all other cases). 
> 
> The first 4 patches are corrections for misses in the way the system
> and trigger timestamps are handled, and the last 6 provide the
> additional audio timestamping selection. A second batch is planned to
> enable hardware capabilities in a low-level drivers.

Thanks for the revised patches.  I now took them locally to
topic/timestamp branch of sound git tree, but it's not merged yet to
master or for-next.  Unless any objection comes up, I'm going to merge
after 3.20-rc1 is released (as it's targeted for 3.21).

> A corresponding set of patches is available for alsa-lib.

Could you repost the alsa-lib patches?  I'm going to queue and push
out when the patches are really merged in the kernel side.


Takashi