[alsa-devel] [very-RFC 0/8] TSN driver for the kernel

[Henrik Austad]

On Sun, Jun 19, 2016 at 11:45:47PM +0900, Takashi Sakamoto wrote:
> (remove C.C. to lkml. This is not so major feature.)
> 
> On Jun 19 2916 07:45, Henrik Austad wrote:
> >snip
> >
> >802.1Q gives you low latency through the network, but more importantly, no
> >dropped frames. gPTP gives you a central reference to time.
> 
> When such a long message is required, it means that we don't have
> enough premises for this discussion.

Isn't a discussion part of how information is conveyed and finding parts 
that require more knowledge?

> You have just interests in gPTP and transferring AVTPDUs, while no
> interests in the others such as "what the basic ideas of TSN come
> from" and "the reason that IEEE 1722 refers to IEC 61883 series
> which is originally designed for IEEE 1394 bus" and "the reason that
> I was motivated to join in this discussion even though not a netdev
> developer".

I'm sorry, I'm not sure I follow you here. What do you mean I don't have 
any interest in where TSN comes from? or the reason why 1722 use IEC 61883? 
What about "they picked 61883 because it made sense?"

gPTP itself is *not* about transffering audio-data, it is about agreeing on 
a common time so that when you *do* transfer audio-data, the samplerate 
actually means something.

Let me ask you this; if you have 2 sound-cards in your computer and you 
want to attach a mic to one and speakers to the other, how do you solve 
streaming of audio from the mic to the speaker If you answer does not 
contain something akin to "different timing-domain issues", I'd be very 
surprised.

If you are interested in TSN for transferring *anything*, _including_ 
audio, you *have* to take gPTP into consideration. Just as you have to 
think about stream reservation, compliant hardware and all the different 
subsystems you are going to run into, either via kernel or via userspace.

> Here, could I ask you a question? Do you know a role of cycle start
> packet of IEEE Std 1394?

No, I do not.

I have only passing knowledge of the firewire standard, I've looked at the 
encoding described in 1722 and added that to the alsa shim as an example of 
how to use TSN. As I stated, this was a *very* early version and I would 
like to use TSN for audio - and more work is needed.

> If you think it's not related to this discussion, please tell it to
> me. Then I'll drop out from this thread.

There are tons of details left and right, and as I said, I'm not  all to 
familiar with firewire. I know that one of the authors behind the firewire 
standard happened to be part of 1722 standard.

I am currently working my way through the firewire-stak paper you've 
written, and I have gotten a lot of pointers to other areas I need to dig 
into so I should be busy for a while.

That being said, Richard's point about a way to find sample-rate of a 
hardware device and ways to influence that, is important for AVB/TSN.

> History Repeats itself.

?

> Takashi Sakamoto

-- 
Henrik Austad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20160620/639ddebf/attachment.sig>