Presentation time is either set by
a) Local sound card performing capture (in which case it will be 'capture
time')
b) Local media application sending a stream accross the network
(time when the sample should be played out remotely)
c) Remote media application streaming data *to* host, in which case it will
be local presentation time on local soundcard
This value is dominant to the number of events included in an IEC 61883-1
packet. If this TSN subsystem decides it, most of these items don't need
to be in ALSA.
Not sure if I understand this correctly.
TSN should have a reference to the timing-domain of each *local*
sound-device (for local capture or playback) as well as the shared
time-reference provided by gPTP.
Unless an End-station acts as GrandMaster for the gPTP-domain, time set
forth by gPTP is inmutable and cannot be adjusted. It follows that the
sample-frequency of the local audio-devices must be adjusted, or the
audio-streams to/from said devices must be resampled.
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.
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
