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

On Jun 12 2016 17:28, Henrik Austad wrote:

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

quoted

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.

For your information, I describe more about it.

You can see pre-standardized specification for IEC 61883-6 in website of
1394 Trade Association. Let's look for 'Audio and Music Data
Transmission Protocol 2.3 (October 13, 2010, 1394TA)'
http://1394ta.org/specifications/

In 'clause 12. AM824 SEQUENCE ADAPTATION LAYERS', you can see that one
data block includes several types of data.


But I can imagine that joint group for AVB loosely refers to IEC
61883-6. In this case, AVB specification might describe one data block
transfers one type of data, to drop unreasonable complexities.

quoted

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.

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

In my taste, the driver is not necessarily compliant to any standards.
It's enough just to work its task, without bad side-effects to Linux
system. Based on this concept, current ALSA firewire stack just support
PCM frames and MIDI messages.

Here, I tell you that actual devices tend not to be compliant to any
standards and lost inter-operability.

(Especially, most of audio and music units on IEEE 1394 bus ignores some
of items in standards. In short, they already lost inter-operability.)

So here, we just consider about what actual devices do, instead of
following any standards.


Regards

Takashi Sakamoto