On 2016年06月20日 18:06, Henrik Austad wrote:
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.
?
OK. Bye.
Takashi Sakamoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
