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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <575D2809.9020903@sakamocchi.jp>
Date:	Sun, 12 Jun 2016 18:14:49 +0900
From:	Takashi Sakamoto <o-takashi@...amocchi.jp>
To:	Henrik Austad <henrik@...tad.us>
Cc:	alsa-devel@...a-project.org, netdev@...r.kernel.org,
	henrk@...tad.us, alsa-devel@...r.kernel.org,
	linux-media@...r.kernel.org
Subject: 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:
>> 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.

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

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)