Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On Thu, Jun 23, 2016 at 12:38:48PM +0200, Henrik Austad wrote: > Richard: is it fair to assume that if ptp4l is running and is part of a PTP > domain, ktime_get() will return PTP-adjusted time for the system? No. > Or do I also need to run phc2sys in order to sync the system-time > to PTP-time? Yes, unless you are using SW time stamping, in which case ptp4l will steer the system clock directly. HTH, Richard
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On Thu, Jun 23, 2016 at 12:38:48PM +0200, Henrik Austad wrote: > Richard: is it fair to assume that if ptp4l is running and is part of a PTP > domain, ktime_get() will return PTP-adjusted time for the system? No. > Or do I also need to run phc2sys in order to sync the system-time > to PTP-time? Yes, unless you are using SW time stamping, in which case ptp4l will steer the system clock directly. HTH, Richard
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On Tue, Jun 21, 2016 at 10:45:18AM -0700, Pierre-Louis Bossart wrote: > 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' Interesting, would you mind CCing me in on those patches? > >>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) Ok, I think I see a way to hook this into timestamps from the skbuf on incoming frames and a somewhat messy way on outgoing. Having time coupled with 'avail' and 'delay' is useful, and from the looks of it, 'link'-time is the appropriate level to add this. I'm working on storing the time in the tsn_link struct I use, and then read that from the avb_alsa-shim. Details are still a bit fuzzy though, but I plan to do that and then see what audio-time gives me once it is up and running. Richard: is it fair to assume that if ptp4l is running and is part of a PTP domain, ktime_get() will return PTP-adjusted time for the system? -Or do I also need to run phc2sys in order to sync the system-time to PTP-time? Note that this is for outgoing traffic, Rx should perhaps use the timestamp in skb. Hooking into ktime_get() instead of directly to the PTP-subsystem (if that is even possible) makes it a lot easier to debug when running this in a VM as it doesn't *have* to use PTP-time when I'm crashing a new kernel :) Thanks! -- Henrik Austad signature.asc Description: Digital signature
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On Tue, Jun 21, 2016 at 10:45:18AM -0700, Pierre-Louis Bossart wrote: > 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' Interesting, would you mind CCing me in on those patches? > >>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) Ok, I think I see a way to hook this into timestamps from the skbuf on incoming frames and a somewhat messy way on outgoing. Having time coupled with 'avail' and 'delay' is useful, and from the looks of it, 'link'-time is the appropriate level to add this. I'm working on storing the time in the tsn_link struct I use, and then read that from the avb_alsa-shim. Details are still a bit fuzzy though, but I plan to do that and then see what audio-time gives me once it is up and running. Richard: is it fair to assume that if ptp4l is running and is part of a PTP domain, ktime_get() will return PTP-adjusted time for the system? -Or do I also need to run phc2sys in order to sync the system-time to PTP-time? Note that this is for outgoing traffic, Rx should perhaps use the timestamp in skb. Hooking into ktime_get() instead of directly to the PTP-subsystem (if that is even possible) makes it a lot easier to debug when running this in a VM as it doesn't *have* to use PTP-time when I'm crashing a new kernel :) Thanks! -- Henrik Austad signature.asc Description: Digital signature
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On 6/21/16 12:40 PM, Richard Cochran wrote: On Tue, Jun 21, 2016 at 10:45:18AM -0700, Pierre-Louis Bossart wrote: 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) Can you point me to any open source apps using the dma/link timestamps? Those timestamps are only used in custom applications at the moment, not 'mainstream' open source. It takes time for new kernel capabilities to trickle into userspace, applications usually align on the lowest hardware common denominator. In addition, most applications don't access the kernel directly but go through an audio server or HAL which needs to be updated as well so it's a two-level dependency. These timestamps can be directly mappped to the Android AudioTrack.getTimeStamp API though.
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On 6/21/16 12:40 PM, Richard Cochran wrote: On Tue, Jun 21, 2016 at 10:45:18AM -0700, Pierre-Louis Bossart wrote: 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) Can you point me to any open source apps using the dma/link timestamps? Those timestamps are only used in custom applications at the moment, not 'mainstream' open source. It takes time for new kernel capabilities to trickle into userspace, applications usually align on the lowest hardware common denominator. In addition, most applications don't access the kernel directly but go through an audio server or HAL which needs to be updated as well so it's a two-level dependency. These timestamps can be directly mappped to the Android AudioTrack.getTimeStamp API though.
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On Tue, Jun 21, 2016 at 10:45:18AM -0700, Pierre-Louis Bossart wrote: > 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) Can you point me to any open source apps using the dma/link timestamps? Thanks, Richard
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On Tue, Jun 21, 2016 at 10:45:18AM -0700, Pierre-Louis Bossart wrote: > 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) Can you point me to any open source apps using the dma/link timestamps? Thanks, Richard
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
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)
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
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)
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On 6/20/16 5:31 AM, Richard Cochran wrote: On Mon, Jun 20, 2016 at 02:18:38PM +0200, Richard Cochran wrote: Documentation/sound/alsa/timestamping.txt says: Examples of typestamping with HDaudio: 1. DMA timestamp, no compensation for DMA+analog delay $ ./audio_time -p --ts_type=1 Where is this "audio_time" program of which you speak? alsa-lib/test
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On 6/20/16 5:31 AM, Richard Cochran wrote: On Mon, Jun 20, 2016 at 02:18:38PM +0200, Richard Cochran wrote: Documentation/sound/alsa/timestamping.txt says: Examples of typestamping with HDaudio: 1. DMA timestamp, no compensation for DMA+analog delay $ ./audio_time -p --ts_type=1 Where is this "audio_time" program of which you speak? alsa-lib/test
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On Tue, 21 Jun 2016 08:38:57 +0200, Richard Cochran wrote: > > On Tue, Jun 21, 2016 at 07:54:32AM +0200, Takashi Iwai wrote: > > > I still would appreciate an answer to my other questions, though... > > > > Currently HD-audio (both ASoC and legacy ones) are the only drivers > > providing the link timestamp. In the recent code, it's PCM > > get_time_info ops, so you can easily grep it. > > Yes, I found that myself, thanks. > > > HTH, > > No it doesn't help me, because I asked three questions, and none were > about the link timestamp. ?? The extended audio timpestamp is essentially to return the link timestamp. Just the term has changed along time... Takashi
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On Tue, 21 Jun 2016 08:38:57 +0200, Richard Cochran wrote: > > On Tue, Jun 21, 2016 at 07:54:32AM +0200, Takashi Iwai wrote: > > > I still would appreciate an answer to my other questions, though... > > > > Currently HD-audio (both ASoC and legacy ones) are the only drivers > > providing the link timestamp. In the recent code, it's PCM > > get_time_info ops, so you can easily grep it. > > Yes, I found that myself, thanks. > > > HTH, > > No it doesn't help me, because I asked three questions, and none were > about the link timestamp. ?? The extended audio timpestamp is essentially to return the link timestamp. Just the term has changed along time... Takashi
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On Tue, Jun 21, 2016 at 07:54:32AM +0200, Takashi Iwai wrote: > > I still would appreciate an answer to my other questions, though... > > Currently HD-audio (both ASoC and legacy ones) are the only drivers > providing the link timestamp. In the recent code, it's PCM > get_time_info ops, so you can easily grep it. Yes, I found that myself, thanks. > HTH, No it doesn't help me, because I asked three questions, and none were about the link timestamp. Thanks, Richard
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On Tue, Jun 21, 2016 at 07:54:32AM +0200, Takashi Iwai wrote: > > I still would appreciate an answer to my other questions, though... > > Currently HD-audio (both ASoC and legacy ones) are the only drivers > providing the link timestamp. In the recent code, it's PCM > get_time_info ops, so you can easily grep it. Yes, I found that myself, thanks. > HTH, No it doesn't help me, because I asked three questions, and none were about the link timestamp. Thanks, Richard
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On Mon, 20 Jun 2016 17:21:26 +0200, Richard Cochran wrote: > > On Mon, Jun 20, 2016 at 02:31:48PM +0200, Richard Cochran wrote: > > Where is this "audio_time" program of which you speak? > > Never mind, found it in alsa-lib. > > I still would appreciate an answer to my other questions, though... Currently HD-audio (both ASoC and legacy ones) are the only drivers providing the link timestamp. In the recent code, it's PCM get_time_info ops, so you can easily grep it. HTH, Takashi
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On Mon, 20 Jun 2016 17:21:26 +0200, Richard Cochran wrote: > > On Mon, Jun 20, 2016 at 02:31:48PM +0200, Richard Cochran wrote: > > Where is this "audio_time" program of which you speak? > > Never mind, found it in alsa-lib. > > I still would appreciate an answer to my other questions, though... Currently HD-audio (both ASoC and legacy ones) are the only drivers providing the link timestamp. In the recent code, it's PCM get_time_info ops, so you can easily grep it. HTH, Takashi
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On Mon, Jun 20, 2016 at 02:31:48PM +0200, Richard Cochran wrote: > Where is this "audio_time" program of which you speak? Never mind, found it in alsa-lib. I still would appreciate an answer to my other questions, though... Thanks, Richard
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On Mon, Jun 20, 2016 at 02:31:48PM +0200, Richard Cochran wrote: > Where is this "audio_time" program of which you speak? Never mind, found it in alsa-lib. I still would appreciate an answer to my other questions, though... Thanks, Richard
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On Mon, Jun 20, 2016 at 02:18:38PM +0200, Richard Cochran wrote: > Documentation/sound/alsa/timestamping.txt says: Examples of typestamping with HDaudio: 1. DMA timestamp, no compensation for DMA+analog delay $ ./audio_time -p --ts_type=1 Where is this "audio_time" program of which you speak? Thanks, Richard
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On Mon, Jun 20, 2016 at 02:18:38PM +0200, Richard Cochran wrote: > Documentation/sound/alsa/timestamping.txt says: Examples of typestamping with HDaudio: 1. DMA timestamp, no compensation for DMA+analog delay $ ./audio_time -p --ts_type=1 Where is this "audio_time" program of which you speak? Thanks, Richard
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
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 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? Thanks, Richard
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
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 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? Thanks, Richard
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
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! -- Henrik Austad signature.asc Description: Digital signature
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
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! -- Henrik Austad signature.asc Description: Digital signature
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
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.
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
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.
