netdev - Re: [very-RFC 0/8] TSN driver for the kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 21 Jun 2016 11:22:18 +0900
From:	Takashi Sakamoto <o-takashi@...amocchi.jp>
To:	Henrik Austad <henrik@...tad.us>
Cc:	Richard Cochran <richardcochran@...il.com>,
	alsa-devel@...a-project.org, netdev@...r.kernel.org,
	Arnd Bergmann <arnd@...aro.org>, linux-media@...r.kernel.org
Subject: Re: [very-RFC 0/8] TSN driver for the kernel

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