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 subsystem)
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-t
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 k
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 s
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
Wh
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
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 ca
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...
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
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
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 hardwa
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 sho
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
On Sun, Jun 19, 2016 at 11:46:29AM +0200, Richard Cochran wrote:
> On Sun, Jun 19, 2016 at 12:45:50AM +0200, Henrik Austad wrote:
> > edit: this turned out to be a somewhat lengthy answer. I have tried to
> > shorten it down somewhere. it is getting late and I'm getting increasingly
> > incoheren
On Sun, Jun 19, 2016 at 12:45:50AM +0200, Henrik Austad wrote:
> edit: this turned out to be a somewhat lengthy answer. I have tried to
> shorten it down somewhere. it is getting late and I'm getting increasingly
> incoherent (Richard probably knows what I'm talking about ;) so I'll stop
> for n
On Sat, Jun 18, 2016 at 02:22:13PM +0900, Takashi Sakamoto wrote:
> Hi,
Hi Takashi,
You raise a lot of valid points and questions, I'll try to answer them.
edit: this turned out to be a somewhat lengthy answer. I have tried to
shorten it down somewhere. it is getting late and I'm getting increa
Hi,
Sorry to be late. In this weekday, I have little time for this thread
because working for alsa-lib[1]. Besides, I'm not full-time developer
for this kind of work. In short, I use my limited private time for this
discussion.
On Jun 15 2016 17:06, Richard Cochran wrote:
> On Wed, Jun 15, 2016 a
On Wed, Jun 15, 2016 at 09:04:41AM +0200, Richard Cochran wrote:
> On Tue, Jun 14, 2016 at 10:38:10PM +0200, Henrik Austad wrote:
> > Whereas I want to do
> >
> > aplay some_song.wav
>
> Can you please explain how your patches accomplish this?
Never mind. Looking back, I found it in patch #7.
On Wed, Jun 15, 2016 at 12:15:24PM +0900, Takashi Sakamoto wrote:
> > On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote:
> >> I have seen audio PLL/multiplier chips that will take, for example, a
> >> 10 kHz input and produce your 48 kHz media clock. With the right HW
> >> design, yo
On Wed, Jun 15, 2016 at 09:04:41AM +0200, Richard Cochran wrote:
> On Tue, Jun 14, 2016 at 10:38:10PM +0200, Henrik Austad wrote:
> > Whereas I want to do
> >
> > aplay some_song.wav
>
> Can you please explain how your patches accomplish this?
In short:
modprobe tsn
modprobe avb_alsa
mkdir /sy
On Tue, Jun 14, 2016 at 10:38:10PM +0200, Henrik Austad wrote:
> Where is your media-application in this?
Um, that *is* a media application. It plays music on the sound card.
> You only loop the audio from
> network to the dsp, is the media-application attached to the dsp-device?
Sorry, I thou
On Tue, Jun 14, 2016 at 10:38:10PM +0200, Henrik Austad wrote:
> Whereas I want to do
>
> aplay some_song.wav
Can you please explain how your patches accomplish this?
Thanks,
Richard
Hi Richard,
On Tue, 14 Jun 2016 19:04:44 +0200, Richard Cochran write:
>> Well, I guess I should have said, I am not too familiar with the
>> breadth of current audio hardware, high end or low end. Of course I
>> would like to see even consumer devices work with AVB, but it is up to
>> the ALSA
Hi Richard,
> On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote:
>> 3. ALSA support for tunable AD/DA clocks. The rate of the Listener's
>>DA clock must match that of the Talker and the other Listeners.
>>Either you adjust it in HW using a VCO or similar, or you do
>>ad
On Tue, Jun 14, 2016 at 08:26:15PM +0200, Richard Cochran wrote:
> On Tue, Jun 14, 2016 at 11:30:00AM +0200, Henrik Austad wrote:
> > So loop data from kernel -> userspace -> kernelspace and finally back to
> > userspace and the media application?
>
> Huh? I wonder where you got that idea. Let
On Tue, Jun 14, 2016 at 11:30:00AM +0200, Henrik Austad wrote:
> So loop data from kernel -> userspace -> kernelspace and finally back to
> userspace and the media application?
Huh? I wonder where you got that idea. Let me show an example of
what I mean.
void listener()
{
On Tue, Jun 14, 2016 at 12:18:44PM +0100, One Thousand Gnomes wrote:
> On Mon, 13 Jun 2016 21:51:36 +0200
> Richard Cochran wrote:
> >
> > Actually, we already have support for tunable clock-like HW elements,
> > namely the dynamic posix clock API. It is trivial to write a driver
> > for VCO or
On Mon, 13 Jun 2016 21:51:36 +0200
Richard Cochran wrote:
> On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote:
> > 3. ALSA support for tunable AD/DA clocks. The rate of the Listener's
> >DA clock must match that of the Talker and the other Listeners.
> >Either you adjust it
On Mon, Jun 13, 2016 at 09:32:10PM +0200, Richard Cochran wrote:
> On Mon, Jun 13, 2016 at 03:00:59PM +0200, Henrik Austad wrote:
> > On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote:
> > > Which driver is that?
> >
> > drivers/net/ethernet/renesas/
>
> That driver is merely a PTP
On Mon, Jun 13, 2016 at 08:56:44AM -0700, John Fastabend wrote:
> On 16-06-13 04:47 AM, Richard Cochran wrote:
> > [...]
> > Here is what is missing to support audio TSN:
> >
> > * User Space
> >
> > 1. A proper userland stack for AVDECC, MAAP, FQTSS, and so on. The
> >OpenAVB project does n
On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote:
> 3. ALSA support for tunable AD/DA clocks. The rate of the Listener's
>DA clock must match that of the Talker and the other Listeners.
>Either you adjust it in HW using a VCO or similar, or you do
>adaptive sample rate c
On Mon, Jun 13, 2016 at 03:00:59PM +0200, Henrik Austad wrote:
> On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote:
> > People have been asking me about TSN and Linux, and we've made some
> > thoughts about it. The interest is there, and so I am glad to see
> > discussion on this top
On Mon, Jun 13, 2016 at 03:00:59PM +0200, Henrik Austad wrote:
> On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote:
> > Which driver is that?
>
> drivers/net/ethernet/renesas/
That driver is merely a PTP capable MAC driver, nothing more.
Although AVB is in the device name, the drive
On 16-06-13 04:47 AM, Richard Cochran wrote:
> Henrik,
>
> On Sun, Jun 12, 2016 at 01:01:28AM +0200, Henrik Austad wrote:
>> There are at least one AVB-driver (the AV-part of TSN) in the kernel
>> already,
>
> Which driver is that?
>
>> however this driver aims to solve a wider scope as TSN can
On Monday, June 13, 2016 1:47:13 PM CEST Richard Cochran wrote:
> * Kernel Space
>
> 1. Providing frames with a future transmit time. For normal sockets,
>this can be in the CMESG data. For mmap'ed buffers, we will need a
>new format. (I think Arnd is working on a new layout.)
>
After
On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote:
> Henrik,
Hi Richard,
> On Sun, Jun 12, 2016 at 01:01:28AM +0200, Henrik Austad wrote:
> > There are at least one AVB-driver (the AV-part of TSN) in the kernel
> > already,
>
> Which driver is that?
drivers/net/ethernet/renesas/
Henrik,
On Sun, Jun 12, 2016 at 01:01:28AM +0200, Henrik Austad wrote:
> There are at least one AVB-driver (the AV-part of TSN) in the kernel
> already,
Which driver is that?
> however this driver aims to solve a wider scope as TSN can do
> much more than just audio. A very basic ALSA-driver is
Hi all
(series based on v4.7-rc2, now with the correct netdev)
This is a *very* early RFC for a TSN-driver in the kernel. It has been
floating around in my repo for a while and I would appreciate some
feedback on the overall design to avoid doing some major blunders.
TSN: Time Sensitive Networkin
On Sun, Jun 12, 2016 at 12:22:13AM +0200, Henrik Austad wrote:
> Hi all
Sorry.. I somehow managed to mess up the address to netdev, so if you feel
like replying to this, use this as it has the correct netdev-address.
again, sorry
> (series based on v4.7-rc2)
>
> This is a *very* early RFC for
Hi all
(series based on v4.7-rc2)
This is a *very* early RFC for a TSN-driver in the kernel. It has been
floating around in my repo for a while and I would appreciate some
feedback on the overall design to avoid doing some major blunders.
TSN: Time Sensitive Networking, formely known as AVB (Audi
41 matches
Mail list logo
