alsa/mpd/gmpc support for 24 bit audio

[gavs]

I have an external 24 bit usb dac connected to a computer that is running TC3.1 with alsa/mpd/gmpc. I understand that recently mpd introduced support for S24_3LE format, the input format for usb dacs. This support eliminates the need for unnecessary format conversions and is supposed to improve sound quality. I have only the usb dac audio device (I blacklist the mainboard sound), therefore I refer to hw:0,0 .

Apparently users of mpd version 0.15.9 have reported that this feature works by simply specifying
   device "hw:0,0"
in the mpd.conf file (previously one had to use plughw which invoked format conversions). The mpd version for tc is 0.15.12 so I thought this would work, but gmpc shows a message that mpd reports a problem opening audio device. Although the format should be optional, I also tried specifying
   format "44100:24_3:2"
but mpd aborts when trying to start the daemon giving the message Channel count missing. I also tried
   format "*:24_3:2"
as * is supposed to be valid, but got the message Sample rate missing.

I do not fully understand the interactions between mpd and alsa, but I stepped back to alsa to check format support using speaker-test. I tried
   speaker-test -c2 --rate 48000 --format S24_LE
and got the message Format S24_LE is not supported. Also the same result with S24_3LE. I noticed that speaker-test is version 1.0.23, as noted on the alsa.tcz info file, but when I check
   cat /proc/asound/version
it reports version 1.0.21 .
Just in case it had anything to do with tc3.1, I created a bootable CD with 3.2, downloaded+installed alsa and did the speaker-test again. Same result.

Any suggestions on how I can get mpd to send S24_3LE format to the dac without unnecessary format conversion?

Thank you.

P.S. I do not see the files /etc/asound.conf or ~/.asoundrc  that alsa uses for configuration. Should I just create if needed? Is one preferred?

[Juanito]

P.S. I do not see the files /etc/asound.conf or ~/.asoundrc  that alsa uses for configuration. Should I just create if needed? Is one preferred?

Usually ~/.asoundrc is not required, but you could create one to see if that helps

[gavs]

Thank you for the prompt response. As you note, the system works without ~/.asoundrc when I specify plughw rather than hw in mpd.conf. However, one of the alternatives for improving sound quality that was suggested for the dac included some settings in .asoundrc. Further, one of the settings was
   format S24_3LE
so I wanted to see if this approach would work. Unfortunately after creating .asoundrc as instructed by the dac manufacturer and re-initiating with alsasound start, errors were returned indicating that .asoundrc may be old or corrupt. Executing speaker-test continues to report that the format is not supported.

Is it possible that something is missing from alsa.tcz preventing it from recognizing the S24_3LE format?

[Juanito]

Would it be worth trying pulseaudio?

[gavs]

I do not know anything about Pulseaudio except what I have read. It sounds like it would receive input from a source (MPD in this case?) and direct it to a sink (the dac via ALSA I believe?). This adds a layer between MPD and ALSA for the benefit of increasing functionality, e.g. multiple sources to a device. However, the objective here is to pass S24_3LE format from MPD through ALSA to the dac. Even if I set it up so that MPD passes S24_3LE format through Pulseaudio first en route to ALSA and the dac, would't I hit the same problem when it got to ALSA?

I am under the impression that all sound will pass through ALSA to get to the hardware, therefore, without invoking any other layers, I first have to get the ALSA layer recognizing S24_3LE, i.e. by checking with speaker-test. Is this incorrect?

[Juanito]

The short answer is that I'm not totally sure about the relationship with alsa, but pulseaudio automatically detects hardware (source and sink) and I've not seen alsa mentioned when selecting source or sink with pulseaudio.

Note that pavucontrol would probably make it easier to select source and sink if you give it a go.

[hiro]

Huh, I don't understand what pulseaudio has to do with this.

Alsa definitely knows how to output s24_3LE. I know this, because it is also the only format one of my usb dacs allows.
It works, but since I have an old version of mpd without support for S24_3LE I had to use plughw:0 in mpd, which (if I remember correctly) can convert S24_LE to S24_3LE.

Speakertest says: Recognized sample formats are: S8 S16_LE S16_BE FLOAT_LE S32_LE S32_BE

[gavs]

I loaded pulseaudio and changed the mpd output to pulse. As with alsa output, this worked when a format was not specified. However, when I attempted to specify 24_3 format I got the same error message again.

As hiro notes, I do not think that pulseaudio will help. The usb dac is detected without pulseaudio and I can play music files using plughw in the mpd.conf file. But plughw introduces processing of the sound stream and may degrade audio quality. The word is that sound quality can be improved by using hw and specifying 24_3 format in the mpd.conf file. The handling of S24_3LE directly by mpd is a very recent feature (I believe only since version 0.15.9). However using 24_3 in the format field results in an error when starting mpd. Similarly, an error is returned if * is used in any of the format fields. Both 24_3 and * are discussed in the mpd manual (http://www.musicpd.org/doc/user/ch03s04.html). This seems to be an mpd issue?

If alsa recognizes S24_LE and S24_3LE, is there a reason that speaker-test does not? I tried speaker-test using --format S24_LE after reading that this is a good test of the hardware capability (unfortunately I cannot find that link now). I do not fully understand the structure of alsa, but I gather that some parts are in alsa-modules-2.6.33.3-tinycore.tcz and others are in alsa-config.tcz and all are brought in by alsa.tcz. I suspect the alsa drivers are in alsa-modules. Could this issue be related to the older driver version 1.0.21 compared to the current version of 1.0.23 for other modules? Recall that I was unable to specify S24_3LE format in the .asoundrc file (an alternative way to improve quality that is suggested by the dac manufacturer).

Would it be useful to post these issues to mpd (recognition of 24_3 and * format specification in mpd.conf) and alsa (speaker-test not recognizing formats S24_LE and S24_3LE) forums respectively, or are these issues tc implementation concerns?

[Juanito]

..but I gather that some parts are in alsa-modules-2.6.33.3-tinycore.tcz and others are in alsa-config.tcz and all are brought in by alsa.tcz. I suspect the alsa drivers are in alsa-modules. Could this issue be related to the older driver version 1.0.21 compared to the current version of 1.0.23 for other modules?

iirc, the version of alsa modules that comes with the 2.6.33.3 kernel source is 1.0.21, whereas the rest of the alsa extensions use the latest version available at that time, 1.0.23

You could perhaps try compiling the latest version of alsa modules against the kernel source?

[maro]

I would not want to claim for a second that I understand much about 'alsa', but I had a quick look into what I assume to be the source code of 'speaker-test' (file: 'speaker-test/speaker-test.c' in 'alsa-utils-1.0.23.tar.bz2') and one can find there the follwoing few lines:

Code: [Select]

static const int supported_formats[] = {
  SND_PCM_FORMAT_S8,
  SND_PCM_FORMAT_S16_LE,
  SND_PCM_FORMAT_S16_BE,
  SND_PCM_FORMAT_FLOAT_LE,
  SND_PCM_FORMAT_S32_LE,
  SND_PCM_FORMAT_S32_BE,
  -1
};
I therefore take it that 'speaker-test' will only ever support those 6 formats (also listed in reply #6) as it checks the '--format ' parameter against that list.

But all might not be lost as 'aplay --help' shows the following list:

Code: [Select]

Recognized sample formats are: S8 U8 S16_LE S16_BE U16_LE U16_BE S24_LE S24_BE U24_LE U24_BE
S32_LE S32_BE U32_LE U32_BE FLOAT_LE FLOAT_BE FLOAT64_LE FLOAT64_BE IEC958_SUBFRAME_LE
IEC958_SUBFRAME_BE MU_LAW A_LAW IMA_ADPCM MPEG GSM SPECIAL S24_3LE S24_3BE U24_3LE
U24_3BE S20_3LE S20_3BE U20_3LE U20_3BE S18_3LE S18_3BE U18_3LE


[tinypoodle]

But all might not be lost as 'aplay --help' shows the following list:

Code: [Select]

Recognized sample formats are: S8 U8 S16_LE S16_BE U16_LE U16_BE S24_LE S24_BE U24_LE U24_BE
S32_LE S32_BE U32_LE U32_BE FLOAT_LE FLOAT_BE FLOAT64_LE FLOAT64_BE IEC958_SUBFRAME_LE
IEC958_SUBFRAME_BE MU_LAW A_LAW IMA_ADPCM MPEG GSM SPECIAL S24_3LE S24_3BE U24_3LE
U24_3BE S20_3LE S20_3BE U20_3LE U20_3BE S18_3LE S18_3BE U18_3LE


Note: same applies for arecord

[hiro]

As I already said there's definitely nothing wrong with alsa.
So I think you're right and it's a mpd problem.
"Channel count missing" is what an old version of mpd outputs if you try to use "44100:24_3:2". Perhaps the patch is still not included in 0.15.12...

[gavs]

Thank you for these suggestions. It does appear that alsa handles S24_3LE and it is just speaker-test that does not. Is it surprising that there is this inconsistency? Should this problem be reported? Should I post a message on the alsa forum?

When I tried
   aplay -Dhw:0,0 song.wav
the sound did not play because song.wav is S16_3LE and alsa reported Available formats: S24_3LE . This confirms that alsa is properly detecting that the dac requires S24_3LE.

When I tried
   aplay -Dplughw:0,0 song.wav
the sound plays, confirming that the alsa plughw is formating the S16_3LE to S24_3LE.

This also works
   aplay -Dplug:dmix song.wav
but with different behavior. The dac accepts rates of 44100, 48000, 88200 and 96000, displaying which it is receiving with LED. The file song.wav was 44100. plughw appears to pass the sound stream at its native rate while dmix passes the sound stream at 48000, its built in default (this can be over-ridden using RATE=).

Hiro's assertion that alsa is handling S24_3LE appropriately (except for speaker-test) is confirmed by these trials.

So, the outstanding issue is how mpd handles the format. The use of 24_3 was reported for version 0.15.9 but could it have had a patch applied? Or is there something more generic about the parsing of the format statement? The mpd manual discusses use of * in the format statement. I presume this is not a recent modification. Mpd also aborted when I tried "*:16:2".  Has anybody else tried * in the format specification of the mpd.conf file? The reason for doing this is that some song files are 96000 while most are 44100. Since the dac can handle multiple rates, the * should allow the sound stream to be passed to the dac in its native rate (I hope).

[hiro]

So, the outstanding issue is how mpd handles the format. The use of 24_3 was reported for version 0.15.9

Source? A quick search here brought nothing...

The reason for doing this is that some song files are 96000 while most are 44100. Since the dac can handle multiple rates, the * should allow the sound stream to be passed to the dac in its native rate (I hope).

I think something like that should be possible. Mpd doesn't resample here. But I can't help you with the config file, since the default already worked fine.

And don't worry about speaker-test. It's not worth it.

[tinypoodle]

I had meant to hint that with arecord a sample file with a suitable format could be created.