Thread (64 messages) flat view 64 messages, 9 authors, 2016-06-23

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

From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date: 2016-06-12 10:43:42
Also in: alsa-devel, linux-media

On Jun 12 2016 17:31, Henrik Austad wrote:
On Sun, Jun 12, 2016 at 01:30:24PM +0900, Takashi Sakamoto wrote:
quoted
On Jun 12 2016 12:38, Takashi Sakamoto wrote:
quoted
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).
quoted
(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/*.)

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.)


Regards

Takashi Sakamoto

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help