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

[Henrik Austad <henrik@austad.us>]

[-- Attachment #1: Type: text/plain, Size: 3578 bytes --]

On Sun, Jun 12, 2016 at 07:43:34PM +0900, Takashi Sakamoto wrote:
> On Jun 12 2016 17:31, Henrik Austad wrote:
> > On Sun, Jun 12, 2016 at 01:30:24PM +0900, Takashi Sakamoto wrote:
> >> On Jun 12 2016 12:38, Takashi Sakamoto wrote:
> >>> In your patcset, there's no actual codes about how to handle any
> >>> interrupt contexts (software / hardware), how to handle packet payload,
> >>> and so on. Especially, for recent sound subsystem, the timing of
> >>> generating interrupts and which context does what works are important to
> >>> reduce playback/capture latency and power consumption.
> >>>
> >>> Of source, your intention of this patchset is to show your early concept
> >>> of TSN feature. Nevertheless, both of explaination and codes are
> >>> important to the other developers who have little knowledges about TSN,
> >>> AVB and AES-64 such as me.
> >>
> >> Oops. Your 5th patch was skipped by alsa-project.org. I guess that size
> >> of the patch is too large to the list service. I can see it:
> >> http://marc.info/?l=linux-netdev&m=146568672728661&w=2
> >>
> >> As long as seeing the patch, packets are queueing in hrtimer callbacks
> >> every 1 seconds.
> > 
> > Actually, the hrtimer fires every 1ms, and that part is something I have to 
> > do something about, also because it sends of the same number of frames 
> > every time, regardless of how accurate the internal timer is to the rest of 
> > the network (there's no backpressure from the networking layer).
> > 
> >> (This is a high level discussion and it's OK to ignore it for the
> >> moment. When writing packet-oriented drivers for sound subsystem, you
> >> need to pay special attention to accuracy of the number of PCM frames
> >> transferred currently, and granularity of the number of PCM frames
> >> transferred by one operation. In this case, snd_avb_hw,
> >> snd_avb_pcm_pointer(), tsn_buffer_write_net() and tsn_buffer_read_net()
> >> are involved in this discussion. You can see ALSA developers' struggle
> >> in USB audio device class drivers and (of cource) IEC 61883-1/6 drivers.)
> > 
> > Ah, good point. Any particular parts of the USB-subsystem I should start 
> > looking at?
> 
> I don't think it's a beter way for you to study USB Audio Device Class
> driver unless you're interested in ALSA or USB subsystem.
> 
> (But for your information, snd-usb-audio is in sound/usb/* of Linux
> kernel. IEC 61883-1/6 driver is in sound/firewire/*.)

Ok, thanks, I'll definately be looking at the firewire bit

> We need different strategy to achieve it on different transmission backend.
> 
> > Knowing where to start looking is a tremendous help
> 
> It's not well-documented, and not well-generalized for packet-oriented
> drivers. Most of developers who have enough knowledge about it work for
> DMA-oriented drivers in mobile platforms and have little interests in
> packet-oriented drivers. You need to find your own way.
> 
> Currently I have few advices to you, because I'm also on the way for
> drivers to process IEC 61883-1/6 packets on IEEE 1394 bus with enough
> accuracy and granularity. The paper I introduced is for the way (but not
> mature).
> 
> I wish you get more helps from the other developers. Your work is more
> significant to Linux system, than mine.
> 
> (And I hope your future work get no ignorance and no unreasonable
> hostility from coarse users.)

Ah well, I have asbestos-underwear so that should be fine :)

Thanks for the pointers, I really appreciate them!



-- 
Henrik Austad

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]