| Message ID | 61B6C8BF61481342973655BC8AB0FF355AE2F4@PGSMSX101.gar.corp.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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
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
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
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
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)