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

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

[Takashi Sakamoto]

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

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

[Clemens Ladisch]

Takashi Sakamoto wrote:
> 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)
>
> 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 <clemens@ladisch.de>

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

[Takashi Sakamoto]

(May 31 2014 16:35), Clemens Ladisch wrote:
> Takashi Sakamoto wrote:
>> 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)
>>
>> 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.

> Acked-by: Clemens Ladisch <clemens@ladisch.de>

Thanks.

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


Regards

Takashi Sakamoto
o-takashi@sakamocchi.jp

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

[Takashi Iwai]

At Sat, 31 May 2014 16:51:52 +0900,
Takashi Sakamoto wrote:
> 
> (May 31 2014 16:35), Clemens Ladisch wrote:
> > Takashi Sakamoto wrote:
> >> 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)
> >>
> >> 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.
> 
> > Acked-by: Clemens Ladisch <clemens@ladisch.de>
> 
> 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

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

[Takashi Sakamoto]

(Jun 1 2014 15:23), Takashi Iwai wrote:
> If you'd like it to be merged, just resend without RFC tag (and with
> ack tags).

I'm OK. Thanks


Takashi Sakamoto
o-takashi@sakamocchi.jp