linux
linux copied to clipboard
raspberrypi
Alsa driver limited to 16-bit / 48kHz audio files
While trying to play 24-bit/96kHz or 24-bit 192kHz files with aplay the files are downsampled to 16-bit
pi@raspberrypi ~ $ aplay -v audio/JimmyAndTheCrows96kHz.wav
Playing WAVE 'audio/JimmyAndTheCrows96kHz.wav' : Signed 24 bit Little Endian in 3bytes, Rate 96000 Hz, Stereo
Plug PCM: Rate conversion PCM (48000, sformat=S16_LE)
Converter: linear-interpolation
Protocol version: 10002
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S24_3LE
subformat : STD
channels : 2
rate : 96000
exact rate : 96000 (96000/1)
msbits : 24
buffer_size : 32768
period_size : 8192
period_time : 85333
tstamp_mode : NONE
period_step : 1
avail_min : 8192
period_event : 0
start_threshold : 32768
stop_threshold : 32768
silence_threshold: 0
silence_size : 0
boundary : 1073741824
Slave: Hardware PCM card 0 'bcm2835 ALSA' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : MMAP_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 16384
period_size : 4096
period_time : 85333
tstamp_mode : NONE
period_step : 1
avail_min : 4096
period_event : 0
start_threshold : 16384
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 1073741824
appl_ptr : 0
hw_ptr : 0
pi@raspberrypi ~ $ mplayer -ao alsa audio/test32bit_44.1kHz.wav
MPlayer svn r34540 (Debian), built with gcc-4.6 (C) 2000-2012 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Playing audio/test32bit_44.1kHz.wav.
libavformat version 53.21.1 (external)
Mismatching header version 53.19.0
Audio only file format detected.
Load subtitles in audio/
==========================================================================
Opening audio decoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 44100 Hz, 2 ch, s32le, 2822.4 kbit/100.00% (ratio: 352800->352800)
Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
==========================================================================
AO: [alsa] 44100Hz 2ch s32le (4 bytes per sample)
Video: no video
Starting playback...
A: 23.5 (23.5) of 66.0 (01:06.0) 1.8%
MPlayer interrupted by signal 2 in module: play_audio
A: 23.6 (23.5) of 66.0 (01:06.0) 1.8%
Exiting... (Quit)
pi@raspberrypi ~ $ mplayer -ao alsa audio/JimmyAndTheCrows96kHz.wav
MPlayer svn r34540 (Debian), built with gcc-4.6 (C) 2000-2012 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Playing audio/JimmyAndTheCrows96kHz.wav.
libavformat version 53.21.1 (external)
Mismatching header version 53.19.0
libavformat file format detected.
[wav @ 0xb63ecc78]max_analyze_duration reached
[lavf] stream 0: audio (pcm_s24le), -aid 0
Clip info:
comment: Jimmy And The Crows
encoded_by: Keith Greeninger, Chris Kee & Br
date: 2013-07-25
creation_time: 14:58:00
time_reference: 0
coding_history: A=PCM,F=96000,W=24,M=stereo,T=KORG AudioGate ver.2.3.2 (Windows 7),
artist: Keith Greeninger, Chris Kee & Brain
title: Jimmy And The Crows
Load subtitles in audio/
==========================================================================
Opening audio decoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 96000 Hz, 2 ch, s24le, 4608.0 kbit/100.00% (ratio: 576000->576000)
Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
==========================================================================
AO: [alsa] 48000Hz 2ch s24le (3 bytes per sample)
Video: no video
Starting playback...
A: 36.9 (36.9) of 475.2 (07:55.2) 9.2%
MPlayer interrupted by signal 2 in module: decode_audio
A: 37.0 (36.9) of 475.2 (07:55.2) 9.2%
Exiting... (Quit)
But playing with omxplayer they "appear" to play back correctly:
pi@raspberrypi ~ $ omxplayer -p audio/JimmyAndTheCrows96kHz.wav
Audio codec pcm_s24le channels 2 samplerate 96000 bitspersample 24
Subtitle count: 0, state: off, index: 1, delay: 0
have a nice day ;)
Alsa limits sampling rate to 48kHz, but can easily be increased. It also only supports 8 and 16-bit samples. This can be increased although may be a little more involved.
omxplayer will honour the sampling rate. I believe the code path may involve the samples being converted to 16-bit.
The OMX API does allow 32-bit samples to be submitted (although hdmi is limited to 24-bit), so hello_audio could be modified to output higher depth samples. Whether you could hear the difference is debatable.
24-bit audio files are becoming more popular now. I just got back from CES and there was a whole room dedicated to companies that provide high resolution audio files for downloads. Sony had a whole section in their booth for high res audio and even Creative Labs had a section for high res audio.
The market may be small but it is growing.
Agreed. If the hardware can support it, and some people want it, then I'd like to make it available. But very subtle improvements are obviously lower priority than major bugs reported. But, it's on my list!
Don't start a war with comments like "subtle improvements", trust me, there are quite a few people out there who are very passionate about this stuff. Do you know of anyone who is knowledgeable about this enough to help?
Sorry, I meant besides popcornmix since I'm sure he's busy and this isn't at the top of his to do list.
Increasing the max samplerate of alsa driver is trivial. Just edit the 48000 and rebuild kernel. Supporting > 16-bit samples is trivial on the kernel side, but I'd guess there will be GPU side issues that need debugging (you can specify 32-bit samples and it does things with that, but it's never been tested, so is unlikely to work).
hello_audio already supports up to 192kHz. Making it support 32-bit samples should just work. Anyone can try that, and produce a "higher quality" player.
Yes, we've already checked the sample rate and as you say, it's trivial. 32-bit doesn't help too much in the real world since almost nothing is available in 32-bit. The trick is getting 24-bit packaged in the 32-bit and processed properly.
Most APIs don't deal with actual packed 24-bit quantities as they are expensive to access. Normally APIs (like openmax) will just deal with 32-bit quanties and the least significant 8 bits will not be used.
I'll need to check if ALSA treats SNDRV_PCM_FMTBIT_S24 as packed or not.
I think it's actually SNDRV_PCM_FMTBIT_S24_3LE that's needed if I'm not mistaken
Hi. Previously (in kernel 3.14.1 and before (3.13.y) I was able to output 192khz (32_LE) via HDMI (after having changed the file and rebuild the module (like this) : .formats = SNDRV_PCM_FMTBIT_U8 | SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE, .rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_8000_192000, .rate_min = 8000, .rate_max = 192000, .channels_min = 1, .channels_max = 2
However, in later kernels it now outputs only 48 khz even though I have applied the same changes and build the modules like I always have been doing. At the moment I'm using 3.14.4.
I use it for making the small piCorePlayer which is used as a Squeezebox replacement player. It is not pure raspian as I need to rebuild the kernel to produce a tinycore linux. However, there has been no problems before, only at the latest kernels.
I noticed that the behaviour of how HDMI is selected has been changed - could that have an influence on the issue I'm seeing?
Steen
@amtssp The firmware does uses the maximum supported sample rate from the EDID as a limit. What does "tvservice -a" report? Try adding hdmi_force_edid_audio=1 which assumes all audio formats/rates are supported.
Thanks for your reply.
I already use the following commands in order to try to force audio via HDMI. Most users are using this player without a screen attached as it is only an audio player.
sudo echo hdmi_force_mode=1 sudo echo hdmi_drive=2 sudo echo hdmi_force_hotplug=1
sudo echo hdmi_force_edid_audio=1
sudo echo hdmi_ignore_edid=0xa5000080
I will try to see if I can figure out exactly when the behaviour was changed.
Sorry the tvservice command was not found - as I stated I'm using microcore linux
tc@piCorePlayer:~$ tvservice -a -sh: tvservice: not found
If you have time please try it: https://sites.google.com/site/picoreplayer/home
Steen
On Tue, Jun 10, 2014 at 1:06 PM, popcornmix [email protected] wrote:
@amtssp https://github.com/amtssp The firmware does uses the maximum supported sample rate from the EDID as a limit. What does "tvservice -a" report? Try adding hdmi_force_edid_audio=1 which assumes all audio formats/rates are supported.
Can you identify when this happened?
— Reply to this email directly or view it on GitHub https://github.com/raspberrypi/linux/issues/494#issuecomment-45600172.
I'd suggest removing hdmi_ignore_edid=0xa5000080. We now allow HDMI modes to be forced even if not listed in the EDID.
There was a firmware commit on "March 8th 2004" labelled: "audioplus: limit sample rates chosen to ones supported by hardware"
so might be worth trying a firmware from just before and just after that point.
Is there a simple way of making PiCorePlayer play an audio file without a squeezebox client? I'm not sure our work's network will support it. (If I can play a file through ssh or http then that would be easier)
Hello Did anyone try to resolve this 24 bits issue and 48000 Hz limit in raspberry ? I have some files from qobuz.com which are in 24 bits / 96 kHz and I cannot succeed playing them with mpd : it is always resampled to 16 bits / 48 or 44.1 khz depending on the existing limit in mpd.conf (format "44100:16:2") is activated or not. But is never played in the original format whereas omxplayer does it well. I am ok to make a test if someone can compile the sources. Or if someone could give me information about the compiling process because I never did it on a raspberry. My first step would be to compile the unmodified sources and see if I can reproduce the reference image. Then I could try some code modifications as suggested above.
we have touched on this on issue #1000 just enabling the relevant capabilities in the ALSA interface hasn’t enabled 24bit. So its probably a job of interfacing the ALSA components to the hardware firmware correctly as all test files played with noise, though test tones through the native vc interface seem to work @popcornmix that about sum it up?
It seems like you need to enable 32 support whereas adding 24 bit is not working. See here: https://www.raspberrypi.org/forums/viewtopic.php?t=25810 by tghewett » Mon Mar 25, 2013 8:24 pm
.formats = SNDRV_PCM_FMTBIT_U8 | SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE,
However, making this change allows to play 24 bit files.
SNDRV_PCM_FORMAT_S24_LE uses the low 3 bytes (of 4), SNDRV_PCM_FORMAT_S24_3LE uses exactly 3 bytes, SNDRV_PCM_FMTBIT_S32_LE uses the full 4 bytes, but is equivalent to using the higher 3 bytes (if you assume the low byte is set to all 0). So I guess RPI prefers the latter variant.
Unfortunately I can't find any format that signals this variant, so I guess SNDRV_PCM_FMTBIT_S32_LE is the only choice.
I have tested SNDRV_PCM_FMTBIT_S32_LE with conversion from S16_LE and S24_3LE and this produces distortion and noise with current implementation with that format enabled in the alsa driver.
do we have an update on this? I am trying to passthrough(bitstream) 24bit stereo flac audio file to my external AV receiver with no success. It always gets down to 16bit even when If I use omxplayer instead of alsa.
You can't passthrough flac audio - no receiver supports that. omxplayer does support 24 bit audio as PCM (e.g. after flac is decoded by arm).
@GeorgeIoak has this issue been resolved? If yes, then please close this issue.
in my opinion this is a very big priority. passing through 24bit audio with mpd using alsa .
Yes, this is desired. We did add it at one point but reverted it when issues with some apps like Sonic Pi were found. But it needs to be re-visited.
Hi. Any progress on this issue? Several popular mpd based distros can't play Hi-Res Audio files without downsampling or adding an external dac. In my opinion Hi-Res audio over HDMI is a must. Thanks.
