On Mon, Jun 20, 2016 at 01:08:27PM +0200, Pierre-Louis Bossart wrote:
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.
Ok, this sounds promising, and very much in line with what AVB would need.
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.
Ok, I understand that the 'play_at' is difficult to obtain, but it sounds like it is doable to achieve something useful.
Looks like I will be looking into what to put in the .trigger-handler in the ALSA shim and experimenting with this to see how it make sense to connect it from the TSN-stream.
Thanks!