[RFC] [PATCH] firewire-lib: Use IEC 61883-6 compliant labels for Raw Audio/

[Takashi Sakamoto <o-takashi@sakamocchi.jp>]

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

Hi Clemens,

Would I request you to comment this patch?

I don't touch this label issue with my patchset because there is a bit
possibility to cause a regression. But now, I have a confidence that
this modification is reasonable. In detail, please see an attached patch.


Regards

Takashi Sakamoto
o-takashi@sakamocchi.jp

[-- Attachment #2: 0001-firewire-lib-Use-IEC-61883-6-compliant-labels-for-Ra.patch --]
[-- Type: text/x-diff, Size: 1591 bytes --]

>From 7aa1bd8e3ba3a1217cba14ba3a1be322874b29a2 Mon Sep 17 00:00:00 2001
From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date: Sat, 31 May 2014 15:56:32 +0900
Subject: [PATCH] firewire-lib: Use IEC 61883-6 compliant labels for Raw Audio
 data

According to AM824 in IEC 61883-6:2002, 2 bits in LSB of label for Raw Audio
data means Valid Length Code (VBL). Ths value is:
- b00 for 24 bits sample (label is 0x40)
- b01 for 20 bits sample (label is 0x41)
- b10 for 16 bits sample (label is 0x42)

But current firewire-lib apply 24 bits label for both of 16/24 bits samples.

As long as I investigate with BeBoB/Fireworks and OXFW, all of them have a
behaviour to ignore this label, it can generate correct sound even if
firewire-lib gives 0xff for the label. This is also confirmed to IEC 60958
data channel as I described to this comment:

ALSA: bebob: Improve comments about stream format
51fa31d462f32e1ffdf957802dcab1dc20d2f243

So I believe there're no regressions.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
---
 sound/firewire/amdtp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/firewire/amdtp.c b/sound/firewire/amdtp.c
index 31dd1cf..f96bf4c 100644
--- a/sound/firewire/amdtp.c
+++ b/sound/firewire/amdtp.c
@@ -418,7 +418,7 @@ static void amdtp_write_s16(struct amdtp_stream *s,
 	for (i = 0; i < frames; ++i) {
 		for (c = 0; c < channels; ++c) {
 			buffer[s->pcm_positions[c]] =
-					cpu_to_be32((*src << 8) | 0x40000000);
+					cpu_to_be32((*src << 8) | 0x42000000);
 			src++;
 		}
 		buffer += s->data_block_quadlets;
-- 
1.8.3.2


[-- Attachment #3: Type: text/plain, Size: 0 bytes --]