[alsa-devel] Question about Conversion to S24_LE from S24_3LE
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
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
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
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
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
participants (3)
-
Clemens Ladisch
-
Fujikawa, Kazutoshi
-
Takashi Iwai