Skip to contentSkip to conversation

firewire-lib: Use IEC 61883-6 compliant labels for Raw Audio/

RFC PATCH In review Takashi Sakamoto 3 participants 5 messages May 31, 2014 – Jun 1, 2014

Subsystems (2)
Sound Firewire audio drivers and IEC 61883-1/6 packet streaming engine
lore
Share & tools
lore

Takashi Sakamoto

author maintainer
#0 lore raw

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

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
[email protected]

Quoted 1 line

From 7aa1bd8e3ba3a1217cba14ba3a1be322874b29a2 Mon Sep 17 00:00:00 2001

From: Takashi Sakamoto <[email protected]>
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 <[email protected]>
---
 sound/firewire/amdtp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
sound/firewire/amdtp.c +1 -1
index 31dd1cf..f96bf4c 100644
@@ -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;
Signature · 1 line
1.8.3.2
maintainer Acked-by on v1 1/1
#1 lore raw
Quoted 10 lines · Takashi Sakamoto

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.

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)

Quoted 4 lines

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

Same for DICE.

Acked-by Clemens Ladisch <[email protected]>
author maintainer
#2 lore raw
Quoted 11 lines · Clemens Ladisch
Quoted 10 lines · Takashi Sakamoto

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.

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)

Quoted 6 lines
Quoted 4 lines

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

Same for DICE.

It's nice information for Dice developers.

Quoted 1 line
Acked-by Clemens Ladisch <[email protected]>

Thanks.

Iwai-san, could you please apply this patch to for-next?

Regards

Takashi Sakamoto
[email protected]

#3 lore raw

At Sat, 31 May 2014 16:51:52 +0900,

Quoted 20 lines · Takashi Sakamoto
Quoted 11 lines · Clemens Ladisch
Quoted 10 lines · Takashi Sakamoto

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.

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)

Quoted 6 lines
Quoted 4 lines

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

Same for DICE.

Quoted 7 lines

It's nice information for Dice developers.

Quoted 1 line
Acked-by Clemens Ladisch <[email protected]>

Thanks.

Iwai-san, could you please apply this patch to for-next?

If you'd like it to be merged, just resend without RFC tag (and with ack tags).

Takashi

author maintainer
#4 lore raw
Quoted 2 lines · Takashi Iwai

If you'd like it to be merged, just resend without RFC tag (and with ack tags).

I'm OK. Thanks

Takashi Sakamoto
[email protected]