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?
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
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
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
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
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
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
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
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,
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
--
To unsubscribe from this list: send the line
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
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
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
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
14 matches
Mail list logo
