Question about Conversion to S24_LE from S24_3LE

Question about Conversion to S24_LE from S24_3LE

[Fujikawa, Kazutoshi]

Hello.

I'd like to play a wav file converted from S24_3LE format to S24_LE by alsa-lib.
(I use aplay command.)

I recognize the following:

<PCM format in wav file>
ex. Valid PCM data is 0x123456.

S24_LE  :  0x12345600(in 4bytes, LSB 0 padding)
S24_3LE :  0x123456  (in 3bytes, No padding)


When the S24_LE format file is played, the ALSA driver receives data format is as follows:

0x12345600 (LSB 0 padding)


However, when the S24_3LE format file which is converted to S24_LE by alsa-lib is played, the ALSA driver receives data formats is as follows:

0x00123456 (MSB 0(or 0xFF) padding)

Why is the how to pad 0 different(LSB/MSB)?


cf.

When "snd_pcm_linear_getput" is called
  'get_idx' is set 16.
  'put_idx' is set 8.

[alsa-lib:pcm_linear.c]

211     void snd_pcm_linear_getput(const snd_pcm_channel_area_t *dst_areas, snd_ pcm_uframes_t dst_offset,
212                                const snd_pcm_channel_area_t *src_areas, snd_ pcm_uframes_t src_offset,
213                                unsigned int channels, snd_pcm_uframes_t fram es,
214                                unsigned int get_idx, unsigned int put_idx)
215     {
216     #define CONV24_LABELS
217     #include "plugin_ops.h"
218     #undef CONV24_LABELS
219             void *get = get32_labels[get_idx];
220             void *put = put32_labels[put_idx];
221             unsigned int channel;
222             u_int32_t sample = 0;
223             for (channel = 0; channel < channels; ++channel) {
224                     const char *src;


When 'get_idx' is 16 and 'put_idx' is 8, it is converted as follows:

0x123456(S24_3LE) -> 0x00123456(MSB 0 padding)


I expect the following:

0x123456(S24_3LE) -> 0x12345600(LSB 0 padding)

(If 'get_idx' is 16 and 'put_idx' is 12, it is converted like this.)


I'm doing something wrong?

--------------------
alsa-lib-1.0.24.1
alsa-utils-1.0.24.2
--------------------

Regards.

Kaz

Re: Question about Conversion to S24_LE from S24_3LE

[Takashi Iwai]

At Fri, 10 Aug 2012 00:28:50 +0000,
Fujikawa, Kazutoshi wrote:
> 
> Hello.
> 
> I'd like to play a wav file converted from S24_3LE format to S24_LE by alsa-lib.
> (I use aplay command.)
> 
> I recognize the following:
> 
> <PCM format in wav file>
> ex. Valid PCM data is 0x123456.
> 
> S24_LE  :  0x12345600(in 4bytes, LSB 0 padding)

No, it's S32_LE.  The actual bit length the hardware supports is
informed via sbits (msbits) if it doesn't fill the whole 32bit.
But it's optional.

> S24_3LE :  0x123456  (in 3bytes, No padding)
> 
> 
> When the S24_LE format file is played, the ALSA driver receives data format is as follows:
> 
> 0x12345600 (LSB 0 padding)
> 
> 
> However, when the S24_3LE format file which is converted to S24_LE by alsa-lib is played, the ALSA driver receives data formats is as follows:
> 
> 0x00123456 (MSB 0(or 0xFF) padding)

This is the correct S24_LE representation.


Takashi

Re: Question about Conversion to S24_LE from S24_3LE

[Fujikawa, Kazutoshi]

Hello, Takashi.
Thank you for your replay.

> > 0x00123456 (MSB 0(or 0xFF) padding)
> 
> This is the correct S24_LE representation.

I record a sound file by arecord command on Ubuntu.
(% arecord -f S24_LE -r 48000 -c 2 ubuntu_rec_S24_LE_48000.wav )

Then this file was created, and it was LSB 0 padding.
So I think that S24_LE format is LSB 0 padding.

% od -t x4 ubuntu_rec_S24_LE_48000.wav 
0000000 46464952 003a9824 45564157 20746d66
0000010 00000010 00020001 0000bb80 0005dc00
0000020 00180008 61746164 003a9800 ffffbf00
0000030 ffffc300 ffffc600 ffffca00 ffffd300
0000040 ffffd600 ffffdc00 ffffe000 ffffe000
0000050 ffffe400 ffffea00 ffffeb00 fffff800
0000060 fffffa00 00000400 00000500 00001000
0000070 00000f00 00001600 00001700 00001500

Do you know why this file is LSB 0 padding?

Regards

Re: Question about Conversion to S24_LE from S24_3LE

[Takashi Iwai]

At Fri, 10 Aug 2012 08:44:12 +0000,
Fujikawa, Kazutoshi wrote:
> 
> Hello, Takashi.
> Thank you for your replay.
> 
> > > 0x00123456 (MSB 0(or 0xFF) padding)
> > 
> > This is the correct S24_LE representation.
> 
> I record a sound file by arecord command on Ubuntu.
> (% arecord -f S24_LE -r 48000 -c 2 ubuntu_rec_S24_LE_48000.wav )
> 
> Then this file was created, and it was LSB 0 padding.
> So I think that S24_LE format is LSB 0 padding.
> 
> % od -t x4 ubuntu_rec_S24_LE_48000.wav 
> 0000000 46464952 003a9824 45564157 20746d66
> 0000010 00000010 00020001 0000bb80 0005dc00
> 0000020 00180008 61746164 003a9800 ffffbf00
> 0000030 ffffc300 ffffc600 ffffca00 ffffd300
> 0000040 ffffd600 ffffdc00 ffffe000 ffffe000
> 0000050 ffffe400 ffffea00 ffffeb00 fffff800
> 0000060 fffffa00 00000400 00000500 00001000
> 0000070 00000f00 00001600 00001700 00001500
> 
> Do you know why this file is LSB 0 padding?

It depends on what format is used in the original PCM stream.
It'd make sense to have 00 in LSB if it was converted from 16 to
24bit.


Takashi

Re: Question about Conversion to S24_LE from S24_3LE

[Clemens Ladisch]

Fujikawa, Kazutoshi wrote:
>>> 0x00123456 (MSB 0(or 0xFF) padding)
>>
>> This is the correct S24_LE representation.
>
> I record a sound file by arecord command on Ubuntu.
> (% arecord -f S24_LE -r 48000 -c 2 ubuntu_rec_S24_LE_48000.wav )
>
> Then this file was created, and it was LSB 0 padding.
> So I think that S24_LE format is LSB 0 padding.
>
> % od -t x4 ubuntu_rec_S24_LE_48000.wav
> 0000000 46464952 003a9824 45564157 20746d66
> 0000010 00000010 00020001 0000bb80 0005dc00
> 0000020 00180008 61746164 003a9800 ffffbf00
> 0000030 ffffc300 ffffc600 ffffca00 ffffd300
> 0000040 ffffd600 ffffdc00 ffffe000 ffffe000
> 0000050 ffffe400 ffffea00 ffffeb00 fffff800
> 0000060 fffffa00 00000400 00000500 00001000
> 0000070 00000f00 00001600 00001700 00001500
>
> Do you know why this file is LSB 0 padding?

What hardware (driver) was this recorded from?
Does the hardware actually support S24_LE, or was this converted?


Regards,
Clemens

Re: Question about Conversion to S24_LE from S24_3LE

[Takashi Iwai]

At Thu, 16 Aug 2012 09:37:18 +0900 (JST),
etsuko suzuki wrote:
> 
> Hi.
> 
> I am Etsuko.
> Kaz is my coworker.
> 
> This was my question, so I had to  post this mail myself.
> However my mail was not posted from my E-mail address.

Did you subscribe to the ML?  Otherwise a post would need a manual
approval and it misses sometimes timeframe that the ML server keeps
a pending post.

> Therefore he had posted this instead of me.
> 
> I am challenging once again using the different mail address. 
> 
> *************************************************************
> 
> >It depends on what format is used in the original PCM stream.
> 
> I recorded this file from 16bits wav file.

OK, it's clear now.

> >It'd make sense to have 00 in LSB if it was converted from 16 to 24bit.
> 
> Does this mean the following? 
> 
> ex.)
> 
> > 0000030 ffffc300 ffffc600 ffffca00 ffffd300
>           ++====**
> 
>           ++ : padding
>           == : PCM data
>           ** : This is added when it was converted from 16 to 24bit.
> 

Yes.  When the original source is 16bit, ALSA-lib format conversion
just shifts the bits.  It's suboptimal, but fast.  That's the reason
of the left 00.

> I'd like to ask one more. 
> I read the following, in order to know about wav file. 
> 
> http://msdn.microsoft.com/en-us/windows/hardware/gg463006.aspx
> 
> In this, I found the statement 'left-alinged'. 
> (In 'Details about wValidBitsPerSample')
> 
> I understood 'left-alinged' was 'LSB padding'.
> So I thought S24_LE was LSB padding.

No.  S24_LE has the MSB padding of 8 bits in 32 bit container.

> Does the format in the ALSA driver differ from the format in wav file? 

You need to use S32_LE instead.


HTH,

Takashi

Re: Question about Conversion to S24_LE from S24_3LE

[Takashi Iwai]

At Thu, 16 Aug 2012 16:55:55 +0900 (JST),
etsuko suzuki wrote:
> 
> Thank you for your kindness reply.
> 
> > Did you subscribe to the ML? 
> 
> Yes I did.
> I subscribed ML and I accepted the mail 'Welcome to the "Alsa-devel" mailing l
> ist'.
> And I can receive mails of this ML.
> But I can't post it to ML.
> (The mails were NOT rejected.)
> 
> I  had sent e-mail to 'alsa-devel-owner@alsa-project.org' several times.
> But there was no answer.
> (The mails were NOT rejected.)
> 
> Is something done else? 
> I am sorry about like this question... 

Hm, I guess your message didn't reach properly, or was filtered by
some spam filter.  Better to contact with Jaroslav (Cc'ed), who
maintains alsa-devel ML.


Takashi
> 
> Regards.
> 
> Etsuko
> 

Re: Question about Conversion to S24_LE from S24_3LE

[Jaroslav Kysela]

Date 16.8.2012 11:16, Takashi Iwai wrote:
> At Thu, 16 Aug 2012 16:55:55 +0900 (JST),
> etsuko suzuki wrote:
>>
>> Thank you for your kindness reply.
>>
>>> Did you subscribe to the ML? 
>>
>> Yes I did.
>> I subscribed ML and I accepted the mail 'Welcome to the "Alsa-devel" mailing l
>> ist'.
>> And I can receive mails of this ML.
>> But I can't post it to ML.
>> (The mails were NOT rejected.)
>>
>> I  had sent e-mail to 'alsa-devel-owner@alsa-project.org' several times.
>> But there was no answer.
>> (The mails were NOT rejected.)
>>
>> Is something done else? 
>> I am sorry about like this question... 
> 
> Hm, I guess your message didn't reach properly, or was filtered by
> some spam filter.  Better to contact with Jaroslav (Cc'ed), who
> maintains alsa-devel ML.

The ALSA server identifies e-mails from Etsuko as spams and they're just
ignored. The culprit can be, that the e-mails are in HTML, non-standard
code pages or the sender may be in a blacklist IP list.

I turned on the capturing of the SPAM messages temporary, if you like to
know, where is the problem. Just ping me after you send your e-mail.
This is for Etsuko.

				Thanks,
					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.

Re: Question about Conversion to S24_LE from S24_3LE

[Takashi Iwai]

At Mon, 20 Aug 2012 14:57:51 +0900 (JST),
etsuko suzuki wrote:
> 
> Hello, Takashi.
> 
> > Hm, I guess your message didn't reach properly, or was filtered by some spam
>  filter.
> > Better to contact with Jaroslav (Cc'ed), who maintains alsa-devel ML.
> 
> I contacted him in August 17. 
> However, there is no reply yet.

Didn't you read his mail in Aug. 16?
You were in Cc.

> 
> [No.1]
> 
> > > http://msdn.microsoft.com/en-us/windows/hardware/gg463006.aspx
> > > 
> > > In this, I found the statement 'left-alinged'. 
> > > (In 'Details about wValidBitsPerSample')
> > > 
> > > I understood 'left-alinged' was 'LSB padding'.
> > > So I thought S24_LE was LSB padding.
> > 
> > No.  S24_LE has the MSB padding of 8 bits in 32 bit container.
> 
> That is, does it mean that this document is not correct?
> (I don't understand why this document differs from what you say.)

Well, Microsoft doesn't conquer the whole world yet.
Their definition isn't what we define for our purpose.

> http://www-mmsp.ece.mcgill.ca/documents/audioformats/wave/Docs/multichaudP.pdf
> (This PDF is the same as what was written before. 
>  The page is written on this.)
> 
> On the 6 page of this PDF, it is written to like this.
> 
>   'If wValidBitsPerSample is less than wBitsPerSample, 
>    then the actual 
>    PCM data is "left-aligned" within the container. 
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
>    The sample itself is justified most significant;
>    all extra bits are at the least-significant 
>    portion of the container.
>    All non-valid data bits must be set to 0.'
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> In S24_LE, I think 'wBitsPerSample' indicates 
> 'the container size'(=32) and 
> 'wValidBitsPerSample' indicates 'the bit of actual valid data'(=24).

You _think_ but you utterly misunderstand the terms.

ALSA S24 is not what you think.  S24 is a special format, 3 bytes LSB
in 4 bytes container.  This _is_ the definition.  There is no such a
format in MS's WAV definition.

wValidBitsPerSample is rather corresponding to hw_params ms_bits
parameter.

> 
> [No.2]
> 
> It was written that Microsoft has defined
> the new structure 'WAVE_FORMAT_EXTENSIBLE'(FORMAT_CODE:0xFFFE).
> (On the 4 page of this PDF.)
> 
> I think that the new structure should be used
> in this(the container size > the bit of actual valid data) case.
> 
> But the structure recording 
> by arecord was 'WAVE_FORMAT_PCM'(FORMAT_CODE:0x0001).
> 
> > % od -t x4 ubuntu_rec_S24_LE_48000.wav 
> > 0000000 46464952 003a9824 45564157 20746d66
> > 0000010 00000010 00020001 0000bb80 0005dc00
>                        ^^^^ 0x0001:WAVE_FORMAT_PCM
> 
> (The 'FORMAT_CODE' is written in this page.
>  http://www-mmsp.ece.mcgill.ca/documents/audioformats/wave/wave.html)
> 
> 
> Why does ALSA NOT use the new structure?

Because it's new, and no one cared such a thing.

> Has ALSA corresponded to the new structure?

Please send a fix patch if you'd like to improve :)


thanks,

Takashi

Question about Conversion to S24_LE from S24_3LE

[Tan, Seng Kai]

Hi Takashi,

I am facing similar problem like this issue, hope to get your advice.
http://mailman.alsa-project.org/pipermail/alsa-devel/2012-August/054241.html

I try to turn on S24_LE support for HDMI Audio using below patch. When I aplay S24_LE file it works fine.
The problem happen when I aplay S24_3LE file, I get and extremely low volume.

When I aplay S24_LE file, I get an left justified value in I2S, this is an expected result:
Front end S24_LE  :  0x12345600(in 4bytes, LSB 0 padding)
Back end  S24_3LE :  0x12345600(in 4bytes, LSB 0 padding)

When I aplay S24_3LE file, I get an extremely low output volume. 
Front end S24_3LE  :  0x123456(in 3bytes, No padding)
Back end  S24_LE :  0x00123456(in 4bytes, MSB 0 padding)

Can you advice how to tell the alsa plugin to pad in LSB instead of MSB?

Below are the patch I used to turn on S24_LE for HDA .

Regards,
Seng Kai




>From 33f182fe1f6d1e49d0618559d1212b619ec902ce Mon Sep 17 00:00:00 2001
From: "SengKai,Tan" <seng.kai.tan@intel.com>
Date: Fri, 8 Apr 2016 17:34:51 +0800
Subject: [PATCH] ALSA: hda: S24_LE format support for HDA Audio

This patch is to add S24_LE support for  HDMI audio
and HDA codec.

Before this patch, HDMI and HDA codec audio only
supported S16_LE and S32_LE. Let's say if user would
like to play S24_LE file, it has to use plugin to
convert to either S16_LE or S32_LE which will
increase in processing and less efficient in utilize
the resources.

On the other side, let's say connected HDMI monitor
support S16_LE and S24_LE. Before this patch is applied
audio has to be converted to S16_LE. That will reduce
the audio quality.

Signed-off-by: Tan, Seng Kai <seng.kai.tan@intel.com>
---
 sound/pci/hda/hda_codec.c  | 6 ++++--
 sound/pci/hda/hda_eld.c    | 6 ++++--
 sound/pci/hda/patch_hdmi.c | 3 ++-
 3 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 57197be..9e737bb 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -3501,14 +3501,16 @@ int snd_hda_query_supported_pcm(struct hda_codec *codec, hda_nid_t nid,
 				if (val & AC_SUPPCM_BITS_32)
 					formats |= SNDRV_PCM_FMTBIT_IEC958_SUBFRAME_LE;
 				if (val & (AC_SUPPCM_BITS_20|AC_SUPPCM_BITS_24))
-					formats |= SNDRV_PCM_FMTBIT_S32_LE;
+					formats |= SNDRV_PCM_FMTBIT_S24_LE |
+						SNDRV_PCM_FMTBIT_S32_LE;
 				if (val & AC_SUPPCM_BITS_24)
 					bps = 24;
 				else if (val & AC_SUPPCM_BITS_20)
 					bps = 20;
 			} else if (val & (AC_SUPPCM_BITS_20|AC_SUPPCM_BITS_24|
 					  AC_SUPPCM_BITS_32)) {
-				formats |= SNDRV_PCM_FMTBIT_S32_LE;
+				formats |= SNDRV_PCM_FMTBIT_S24_LE |
+					SNDRV_PCM_FMTBIT_S32_LE;
 				if (val & AC_SUPPCM_BITS_32)
 					bps = 32;
 				else if (val & AC_SUPPCM_BITS_24)
diff --git a/sound/pci/hda/hda_eld.c b/sound/pci/hda/hda_eld.c
index 0e6d753..65bfe10 100644
--- a/sound/pci/hda/hda_eld.c
+++ b/sound/pci/hda/hda_eld.c
@@ -613,12 +613,14 @@ void snd_hdmi_eld_update_pcm_info(struct parsed_hdmi_eld *e,
 			channels_max = a->channels;
 		if (a->format == AUDIO_CODING_TYPE_LPCM) {
 			if (a->sample_bits & AC_SUPPCM_BITS_20) {
-				formats |= SNDRV_PCM_FMTBIT_S32_LE;
+				formats |= SNDRV_PCM_FMTBIT_S24_LE |
+					SNDRV_PCM_FMTBIT_S32_LE;
 				if (maxbps < 20)
 					maxbps = 20;
 			}
 			if (a->sample_bits & AC_SUPPCM_BITS_24) {
-				formats |= SNDRV_PCM_FMTBIT_S32_LE;
+				formats |= SNDRV_PCM_FMTBIT_S24_LE |
+					SNDRV_PCM_FMTBIT_S32_LE;
 				if (maxbps < 24)
 					maxbps = 24;
 			}
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index d02eccd..8cbde13 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -2489,7 +2489,8 @@ static const struct hda_verb nvhdmi_basic_init_7x_8ch[] = {
 	 SNDRV_PCM_RATE_192000)
 #define SUPPORTED_MAXBPS	24
 #define SUPPORTED_FORMATS \
-	(SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE)
+	(SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE |\
+	SNDRV_PCM_FMTBIT_S32_LE)
 #endif
 
 static int nvhdmi_7x_init_2ch(struct hda_codec *codec)
-- 
1.9.1

Re: Question about Conversion to S24_LE from S24_3LE

[Clemens Ladisch]

Tan, Seng Kai wrote:
> I am facing similar problem like this issue, hope to get your advice.
> http://mailman.alsa-project.org/pipermail/alsa-devel/2012-August/054241.html

And the answer is the same.

> I try to turn on S24_LE support for HDMI Audio using below patch.

Your hardware does not support S24_LE.

24-bit samples use the S32_LE format (unless you have very exotic
hardware, but HDA isn't).

> Back end  S24_LE :  0x00123456(in 4bytes, MSB 0 padding)

This is how S24_LE works.

> Can you advice how to tell the alsa plugin to pad in LSB instead of MSB?

Use S32_LE.


Regards,
Clemens

Re: Question about Conversion to S24_LE from S24_3LE

[Tan, Seng Kai]

Thanks Clemens

Tan, Seng Kai wrote:
>> I am facing similar problem like this issue, hope to get your advice.
>> http://mailman.alsa-project.org/pipermail/alsa-devel/2012-August/05424
>> 1.html

>And the answer is the same.

>> I try to turn on S24_LE support for HDMI Audio using below patch.
>Your hardware does not support S24_LE.
>24-bit samples use the S32_LE format (unless you have very exotic hardware, but HDA isn't).
We have another I2S hardware which is able to support S24L_LE and S32_LE format, 
when I use -Dplughw to play S24_3LE format the same things happen. It pad the 0 in MSB
the whole data is shift to right and the audio volume is lower. Is this the problem for alsa plugins?

>> Back end  S24_LE :  0x00123456(in 4bytes, MSB 0 padding)
>This is how S24_LE works.
S24_LE in wav file supposed to be in format  0x00123456 ( 0 pad MSB) or
0x12345600 ( 0 pad LSB) which one is correct? I am a bit confuse here, because 
When I open file with 0x12345600 ( 0 pad LSB) using audacity, it is able to view the file
But not for 0x00123456 ( 0 pad MSB).

>> Can you advice how to tell the alsa plugin to pad in LSB instead of MSB?
>Use S32_LE.
Question: is all HDMI support 24 bit must have 32bit support? My concern is it don't
And we want to maximize the quality to 24bit. 

Regards,
Seng Kai

Re: Question about Conversion to S24_LE from S24_3LE

[Clemens Ladisch]

Tan, Seng Kai wrote:
>> Your hardware does not support S24_LE.
>> 24-bit samples use the S32_LE format (unless you have very exotic hardware, but HDA isn't).
>
> We have another I2S hardware which is able to support S24L_LE and S32_LE format,

The format on the codec's bus has almost nothing to do with the ALSA
sample format.

The Sxx_xE format describes how the samples are formatted in memory,
i.e., how the DMA controller expects to read them.

> S24_LE in wav file

.wav files do no use ALSA sample formats.

Please describe the values of the header fields in this .wav file.

> Question: is all HDMI support 24 bit must have 32bit support?

That depends on the DMA controller.  Most use 32-bit alignment for
24-bit samples.


Regards,
Clemens

Re: Question about Conversion to S24_LE from S24_3LE

[Tan, Seng Kai]

Tan, Seng Kai wrote:
>>> Your hardware does not support S24_LE.
>>> 24-bit samples use the S32_LE format (unless you have very exotic hardware, but HDA isn't).
>>
>> We have another I2S hardware which is able to support S24L_LE and 
>> S32_LE format,

>The format on the codec's bus has almost nothing to do with the ALSA sample format.

>The Sxx_xE format describes how the samples are formatted in memory, i.e., how the DMA controller expects to read them.

I think I get what you mean. 
The input to the driver should be 0x123456 (3 byte, no padding)
And the driver supposed to arrange it to 0x12345600 (4 byte, LSB padding for left justified)
That is because the driver do not support and the value get truncate

>> S24_LE in wav file

>.wav files do no use ALSA sample formats.

>Please describe the values of the header fields in this .wav file.

qwavheaderdump -F ~/Public/workspace/aud_file/Tones/2ch_48sine_S24_LE.wav
/home/ilab/Public/workspace/aud_file/Tones/2ch_48sine_S24_LE.wav (11520044 bytes):
        riff: 'RIFF'
        riff length: 11520036
        wave: 'WAVE'
        fmt: 'fmt '
        fmt length: 16
        format: 1
        channels: 2
        sample rate: 48000
        bytes/second: 384000
        bytes/sample: 8
                 bytes/sample field should be 1, 2 or 4
                don't know which value must be set...

        bits/sample: 24
        data: 'data'
        data length: 11520000

Regards,
Clemens

Re: Question about Conversion to S24_LE from S24_3LE

[Clemens Ladisch]

Tan, Seng Kai wrote:
> The input to the driver should be 0x123456 (3 byte, no padding)
> And the driver supposed to arrange it to 0x12345600 (4 byte, LSB padding for left justified)

No, the kernel driver should never change sample data.

If the hardware supports only 32-bit-aligned samples, then the driver
must declare that.  Any needed conversions are then done in user space.

>>> S24_LE in wav file
>
> qwavheaderdump -F ~/Public/workspace/aud_file/Tones/2ch_48sine_S24_LE.wav
>         channels: 2
>         sample rate: 48000
>         bytes/second: 384000
>         bytes/sample: 8
>         bits/sample: 24

This is not correct according to the .wav specification; the
wBitsPerSamples field must be the container size, which is 32 here (as
shown by nChannels and nBlockAlign).

If the number of valid bits is less than the container size, the file
must use the wValidBitsPerSample field in the WAVEFORMATEXTENSIBLE
structure.

Anyway, .wav files cannot describe or use S24_LE samples, they use
either S32_LE (as in this file) or S24_3LE.


Regards,
Clemens