From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Sakamoto Subject: Re: [very-RFC 0/8] TSN driver for the kernel Date: Tue, 21 Jun 2016 11:22:18 +0900 Message-ID: <5768A4DA.1030809@sakamocchi.jp> References: <1465686096-22156-1-git-send-email-henrik@austad.us> <20160613114713.GA9544@localhost.localdomain> <20160613195136.GC2441@netboy> <20160614121844.54a125a5@lxorguk.ukuu.org.uk> <5760C84C.40408@sakamocchi.jp> <20160615080602.GA13555@localhost.localdomain> <5764DA85.3050801@sakamocchi.jp> <20160618224549.GF32724@icarus.home.austad.us> <5766B01B.9070903@sakamocchi.jp> <20160620090656.GB8011@sisyphus.home.austad.us> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: Received: from smtp-proxy001.phy.lolipop.jp (smtp-proxy001.phy.lolipop.jp [157.7.104.42]) by alsa0.perex.cz (Postfix) with ESMTP id 307FA2656F5 for ; Tue, 21 Jun 2016 04:22:20 +0200 (CEST) In-Reply-To: <20160620090656.GB8011@sisyphus.home.austad.us> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Henrik Austad Cc: netdev@vger.kernel.org, Richard Cochran , linux-media@vger.kernel.org, alsa-devel@alsa-project.org, Arnd Bergmann List-Id: alsa-devel@alsa-project.org T24gMjAxNuW5tDA25pyIMjDml6UgMTg6MDYsIEhlbnJpayBBdXN0YWQgd3JvdGU6Cj4gT24gU3Vu LCBKdW4gMTksIDIwMTYgYXQgMTE6NDU6NDdQTSArMDkwMCwgVGFrYXNoaSBTYWthbW90byB3cm90 ZToKPj4gKHJlbW92ZSBDLkMuIHRvIGxrbWwuIFRoaXMgaXMgbm90IHNvIG1ham9yIGZlYXR1cmUu KQo+Pgo+PiBPbiBKdW4gMTkgMjkxNiAwNzo0NSwgSGVucmlrIEF1c3RhZCB3cm90ZToKPj4+IHNu aXAKPj4+Cj4+PiA4MDIuMVEgZ2l2ZXMgeW91IGxvdyBsYXRlbmN5IHRocm91Z2ggdGhlIG5ldHdv cmssIGJ1dCBtb3JlIGltcG9ydGFudGx5LCBubwo+Pj4gZHJvcHBlZCBmcmFtZXMuIGdQVFAgZ2l2 ZXMgeW91IGEgY2VudHJhbCByZWZlcmVuY2UgdG8gdGltZS4KPj4KPj4gV2hlbiBzdWNoIGEgbG9u ZyBtZXNzYWdlIGlzIHJlcXVpcmVkLCBpdCBtZWFucyB0aGF0IHdlIGRvbid0IGhhdmUKPj4gZW5v dWdoIHByZW1pc2VzIGZvciB0aGlzIGRpc2N1c3Npb24uCj4KPiBJc24ndCBhIGRpc2N1c3Npb24g cGFydCBvZiBob3cgaW5mb3JtYXRpb24gaXMgY29udmV5ZWQgYW5kIGZpbmRpbmcgcGFydHMKPiB0 aGF0IHJlcXVpcmUgbW9yZSBrbm93bGVkZ2U/Cj4KPj4gWW91IGhhdmUganVzdCBpbnRlcmVzdHMg aW4gZ1BUUCBhbmQgdHJhbnNmZXJyaW5nIEFWVFBEVXMsIHdoaWxlIG5vCj4+IGludGVyZXN0cyBp biB0aGUgb3RoZXJzIHN1Y2ggYXMgIndoYXQgdGhlIGJhc2ljIGlkZWFzIG9mIFRTTiBjb21lCj4+ IGZyb20iIGFuZCAidGhlIHJlYXNvbiB0aGF0IElFRUUgMTcyMiByZWZlcnMgdG8gSUVDIDYxODgz IHNlcmllcwo+PiB3aGljaCBpcyBvcmlnaW5hbGx5IGRlc2lnbmVkIGZvciBJRUVFIDEzOTQgYnVz IiBhbmQgInRoZSByZWFzb24gdGhhdAo+PiBJIHdhcyBtb3RpdmF0ZWQgdG8gam9pbiBpbiB0aGlz IGRpc2N1c3Npb24gZXZlbiB0aG91Z2ggbm90IGEgbmV0ZGV2Cj4+IGRldmVsb3BlciIuCj4KPiBJ J20gc29ycnksIEknbSBub3Qgc3VyZSBJIGZvbGxvdyB5b3UgaGVyZS4gV2hhdCBkbyB5b3UgbWVh biBJIGRvbid0IGhhdmUKPiBhbnkgaW50ZXJlc3QgaW4gd2hlcmUgVFNOIGNvbWVzIGZyb20/IG9y IHRoZSByZWFzb24gd2h5IDE3MjIgdXNlIElFQyA2MTg4Mz8KPiBXaGF0IGFib3V0ICJ0aGV5IHBp Y2tlZCA2MTg4MyBiZWNhdXNlIGl0IG1hZGUgc2Vuc2U/Igo+Cj4gZ1BUUCBpdHNlbGYgaXMgKm5v dCogYWJvdXQgdHJhbnNmZmVyaW5nIGF1ZGlvLWRhdGEsIGl0IGlzIGFib3V0IGFncmVlaW5nIG9u Cj4gYSBjb21tb24gdGltZSBzbyB0aGF0IHdoZW4geW91ICpkbyogdHJhbnNmZXIgYXVkaW8tZGF0 YSwgdGhlIHNhbXBsZXJhdGUKPiBhY3R1YWxseSBtZWFucyBzb21ldGhpbmcuCj4KPiBMZXQgbWUg YXNrIHlvdSB0aGlzOyBpZiB5b3UgaGF2ZSAyIHNvdW5kLWNhcmRzIGluIHlvdXIgY29tcHV0ZXIg YW5kIHlvdQo+IHdhbnQgdG8gYXR0YWNoIGEgbWljIHRvIG9uZSBhbmQgc3BlYWtlcnMgdG8gdGhl IG90aGVyLCBob3cgZG8geW91IHNvbHZlCj4gc3RyZWFtaW5nIG9mIGF1ZGlvIGZyb20gdGhlIG1p YyB0byB0aGUgc3BlYWtlciBJZiB5b3UgYW5zd2VyIGRvZXMgbm90Cj4gY29udGFpbiBzb21ldGhp bmcgYWtpbiB0byAiZGlmZmVyZW50IHRpbWluZy1kb21haW4gaXNzdWVzIiwgSSdkIGJlIHZlcnkK PiBzdXJwcmlzZWQuCj4KPiBJZiB5b3UgYXJlIGludGVyZXN0ZWQgaW4gVFNOIGZvciB0cmFuc2Zl cnJpbmcgKmFueXRoaW5nKiwgX2luY2x1ZGluZ18KPiBhdWRpbywgeW91ICpoYXZlKiB0byB0YWtl IGdQVFAgaW50byBjb25zaWRlcmF0aW9uLiBKdXN0IGFzIHlvdSBoYXZlIHRvCj4gdGhpbmsgYWJv dXQgc3RyZWFtIHJlc2VydmF0aW9uLCBjb21wbGlhbnQgaGFyZHdhcmUgYW5kIGFsbCB0aGUgZGlm ZmVyZW50Cj4gc3Vic3lzdGVtcyB5b3UgYXJlIGdvaW5nIHRvIHJ1biBpbnRvLCBlaXRoZXIgdmlh IGtlcm5lbCBvciB2aWEgdXNlcnNwYWNlLgo+Cj4+IEhlcmUsIGNvdWxkIEkgYXNrIHlvdSBhIHF1 ZXN0aW9uPyBEbyB5b3Uga25vdyBhIHJvbGUgb2YgY3ljbGUgc3RhcnQKPj4gcGFja2V0IG9mIElF RUUgU3RkIDEzOTQ/Cj4KPiBObywgSSBkbyBub3QuCj4KPiBJIGhhdmUgb25seSBwYXNzaW5nIGtu b3dsZWRnZSBvZiB0aGUgZmlyZXdpcmUgc3RhbmRhcmQsIEkndmUgbG9va2VkIGF0IHRoZQo+IGVu Y29kaW5nIGRlc2NyaWJlZCBpbiAxNzIyIGFuZCBhZGRlZCB0aGF0IHRvIHRoZSBhbHNhIHNoaW0g YXMgYW4gZXhhbXBsZSBvZgo+IGhvdyB0byB1c2UgVFNOLiBBcyBJIHN0YXRlZCwgdGhpcyB3YXMg YSAqdmVyeSogZWFybHkgdmVyc2lvbiBhbmQgSSB3b3VsZAo+IGxpa2UgdG8gdXNlIFRTTiBmb3Ig YXVkaW8gLSBhbmQgbW9yZSB3b3JrIGlzIG5lZWRlZC4KPgo+PiBJZiB5b3UgdGhpbmsgaXQncyBu b3QgcmVsYXRlZCB0byB0aGlzIGRpc2N1c3Npb24sIHBsZWFzZSB0ZWxsIGl0IHRvCj4+IG1lLiBU aGVuIEknbGwgZHJvcCBvdXQgZnJvbSB0aGlzIHRocmVhZC4KPgo+IFRoZXJlIGFyZSB0b25zIG9m IGRldGFpbHMgbGVmdCBhbmQgcmlnaHQsIGFuZCBhcyBJIHNhaWQsIEknbSBub3QgIGFsbCB0bwo+ IGZhbWlsaWFyIHdpdGggZmlyZXdpcmUuIEkga25vdyB0aGF0IG9uZSBvZiB0aGUgYXV0aG9ycyBi ZWhpbmQgdGhlIGZpcmV3aXJlCj4gc3RhbmRhcmQgaGFwcGVuZWQgdG8gYmUgcGFydCBvZiAxNzIy IHN0YW5kYXJkLgo+Cj4gSSBhbSBjdXJyZW50bHkgd29ya2luZyBteSB3YXkgdGhyb3VnaCB0aGUg ZmlyZXdpcmUtc3RhayBwYXBlciB5b3UndmUKPiB3cml0dGVuLCBhbmQgSSBoYXZlIGdvdHRlbiBh IGxvdCBvZiBwb2ludGVycyB0byBvdGhlciBhcmVhcyBJIG5lZWQgdG8gZGlnCj4gaW50byBzbyBJ IHNob3VsZCBiZSBidXN5IGZvciBhIHdoaWxlLgo+Cj4gVGhhdCBiZWluZyBzYWlkLCBSaWNoYXJk J3MgcG9pbnQgYWJvdXQgYSB3YXkgdG8gZmluZCBzYW1wbGUtcmF0ZSBvZiBhCj4gaGFyZHdhcmUg ZGV2aWNlIGFuZCB3YXlzIHRvIGluZmx1ZW5jZSB0aGF0LCBpcyBpbXBvcnRhbnQgZm9yIEFWQi9U U04uCj4KPj4gSGlzdG9yeSBSZXBlYXRzIGl0c2VsZi4KPgo+ID8KCk9LLiBCeWUuCgoKVGFrYXNo aSBTYWthbW90bwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwpBbHNhLWRldmVsIG1haWxpbmcgbGlzdApBbHNhLWRldmVsQGFsc2EtcHJvamVjdC5vcmcKaHR0 cDovL21haWxtYW4uYWxzYS1wcm9qZWN0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Fsc2EtZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from smtp-proxy001.phy.lolipop.jp ([157.7.104.42]:57756 "EHLO smtp-proxy001.phy.lolipop.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932277AbcFUCbx (ORCPT ); Mon, 20 Jun 2016 22:31:53 -0400 Subject: Re: [very-RFC 0/8] TSN driver for the kernel To: Henrik Austad References: <1465686096-22156-1-git-send-email-henrik@austad.us> <20160613114713.GA9544@localhost.localdomain> <20160613195136.GC2441@netboy> <20160614121844.54a125a5@lxorguk.ukuu.org.uk> <5760C84C.40408@sakamocchi.jp> <20160615080602.GA13555@localhost.localdomain> <5764DA85.3050801@sakamocchi.jp> <20160618224549.GF32724@icarus.home.austad.us> <5766B01B.9070903@sakamocchi.jp> <20160620090656.GB8011@sisyphus.home.austad.us> Cc: Richard Cochran , alsa-devel@alsa-project.org, netdev@vger.kernel.org, Arnd Bergmann , linux-media@vger.kernel.org From: Takashi Sakamoto Message-ID: <5768A4DA.1030809@sakamocchi.jp> Date: Tue, 21 Jun 2016 11:22:18 +0900 MIME-Version: 1.0 In-Reply-To: <20160620090656.GB8011@sisyphus.home.austad.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-media-owner@vger.kernel.org List-ID: 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