On 6/20/16 5:18 AM, Richard Cochran wrote:
On Mon, Jun 20, 2016 at 01:08:27PM +0200, Pierre-Louis Bossart wrote:
The ALSA API provides support for 'audio' timestamps (playback/capture rate
defined by audio subsystem) and 'system' timestamps (typically linked to
TSC/ART) with one option to take synchronized timestamps should the hardware
support them.
Thanks for the info. I just skimmed Documentation/sound/alsa/timestamping.txt.
That is fairly new, only since v4.1. Are then any apps in the wild
that I can look at? AFAICT, OpenAVB, gstreamer, etc, don't use the
new API.
The ALSA API supports a generic .get_time_info callback, its
implementation is for now limited to a regular 'DMA' or 'link' timestamp
for HDaudio - the difference being which counters are used and how close
they are to the link serializer. The synchronized part is still WIP but
should come 'soon'
The intent was that the 'audio' timestamps are translated to a shared time
reference managed in userspace by gPTP, which in turn would define if
(adaptive) audio sample rate conversion is needed. There is no support at
the moment for a 'play_at' function in ALSA, only means to control a
feedback loop.
Documentation/sound/alsa/timestamping.txt says:
If supported in hardware, the absolute link time could also be used
to define a precise start time (patches WIP)
Two questions:
1. Where are the patches? (If some are coming, I would appreciate
being on CC!)
2. Can you mention specific HW that would support this?
You can experiment with the 'dma' and 'link' timestamps today on any
HDaudio-based device. Like I said the synchronized part has not been
upstreamed yet (delays + dependency on ART-to-TSC conversions that made
it in the kernel recently)
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
