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