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

On Sun, Jun 12, 2016 at 12:38:36PM +0900, Takashi Sakamoto wrote:

Hi,

I'm one of maintainers for ALSA firewire stack, which handles IEC
61883-1/6 and vendor-unique packets on IEEE 1394 bus for consumer
recording equipments.
(I'm not in MAINTAINERS because I'm a shy boy.)

IEC 61883-6 describes that one packet can multiplex several types of
data in its data channels; i.e. Multi Bit Linear Audio data (PCM
samples), One Bit Audio Data (DSD), MIDI messages and so on.

Hmm, that I did not know, not sure how that applies to AVB, but definately 
something I have to look into.

If you handles packet payload in 'struct snd_pcm_ops.copy', a process
context of an ALSA PCM applications performs the work. Thus, no chances
to multiplex data with the other types.

Hmm, ok, I didn't know that, that is something I need to look into -and 
incidentally one of the reasons why I posted the series now instead of a 
few more months down the road - thanks!

The driver is not adhering fully to any standards right now, the amount of 
detail is quite high - but I'm slowly improving as I go through the 
standards. Getting on top of all the standards and all the different 
subsystems are definately a work in progress (it's a lot to digest!)

To prevent this situation, current ALSA firewire stack handles packet
payload in software interrupt context of isochronous context of OHCI
1394. As a result of this, the software stack supports PCM substreams
and MIDI substreams.

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.

See reply in other mail :)

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.

Yes, that is one of the things I aimed for, and also getting feedback on 
the overall thinking

And, I might cooperate to prepare for common IEC 61883 layer. For actual
codes of ALSA firewire stack, please see mainline kernel code. For
actual devices of IEC 61883-1/6 and IEEE 1394 bus, please refer to my
report in 2014. At least, you can get to know what to consider about
developing upper drivers near ALSA userspace applications.
https://github.com/takaswie/alsa-firewire-report

Thanks, I'll dig into that, much appreciated

(But I confirm that the report includes my misunderstandings in clause
3.4 and 6.2. need more time...)

ok, good to know

Thank you for your input, very much appreicated!

-- 
Henrik Austad