Tiny Core Linux
Tiny Core Extensions => TCE Q&A Forum => Topic started by: gavs on November 22, 2010, 06:17:16 PM
-
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?
-
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
-
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?
-
Would it be worth trying pulseaudio?
-
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?
-
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.
-
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
-
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?
-
..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?
-
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:
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:
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
-
But all might not be lost as 'aplay --help' shows the following list:
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
-
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...
-
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).
-
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.
-
I had meant to hint that with arecord a sample file with a suitable format could be created.
-
Thanks for the suggestion tinypoodle. I created a song.wav file in S24_3LE format. Now, when I issue the command
aplay -Dhw:0,0 song.wav
the sound plays. This is further confirmation that the dac only accepts S24_3LE format and that alsa can handle this format.
As to source for the statement that mpd version 0.15.9 handles 24_3 format, scroll down about one quarter of the way to a message submitted by mbognar on this link
http://www.computeraudiophile.com/content/Bit-perfect-audio-Linux-882-and-1764-now-possible
Further down on this link there is also discussion about using * in the format specification.
It appears that a recent release of Voyage MPD uses mpd version 0.16~alpha2
http://www.audiocircle.com/index.php?topic=87560.0
but they are looking to push the sampling rate to 192Khz which requires the latest USB Audio Class 2 drivers (my dac does not support rates higher than 96Khz which can be accommodated by USB Audio Class 1).
I have not tried Voyage. Tiny Core, with selection of only essential modules and loading of the entire system in ram, seems well suited for building dedicated music appliances.
-
I guess the posting related to MPD version 0.15.9 was misleading. The 2 features in the format specification that I was trying are new to version 0.16 (see http://www.musicpd.org/forum/index.php?PHPSESSID=b50a48fae4acbb60ecfcf808744b2e0c&topic=2377.0 ).
Thanks to all for the suggestions to sort this out.
-
will someone pacckage this up? it is released, right?
-
MPD 0.15.15 is the latest released stable version. MPD 0.16~alpha4 is the latest released development version.
-
Oh, sorry. In the rush I missed the alpha. I guess I can wait then.
-
MPD version 0.16 was released as the latest stable version on Dec 11.
-
Ok, so who's gonna take the burden? :D
-
I'm going to compile version 0.16, but there are many new libraries and dependencies ... please hold the line ...
-
Thank you for your continued interest and support. I appreciate your efforts. I am new to this and have never packaged an application. However, I will aim to learn how to do this and perhaps be able to help in the future.
-
I have just submitted mpd 0.16 and some stuff for usage.
-
I updated to TC3.4 and tried mpd 0.16. I was able to use hw instead of plughw as device. Also, I was able to specify the format using
format "*:24_3:2"
Reportedly, mpd 0.16 and these settings permit passing of the sound stream by mpd directly to the hardware with minimal processing (also using mixer_type "hardware" to avoid software manipulation of volume). My initial impression is that the sound is cleaner and crisper. If there is interest, I can post my opinion after further critical listening.
Many thanks for your efforts.
As an aside, I am using gmpc as the client. The gmpc icons all appear as Xs. Has anyone else experienced this? Is there a dependency I'm missing? The only apps I have downloaded and installed are ntfs-3g (for external usb ntfs drive with music), mpd (this gets the alsa dependencies) and gmpc.
-
That's cool. Although I doubt that there *should* be any difference. Did you have your volume at 100% before that?
Plughw doesn't resample, and I can't think of any other sources for noise/distortions in that comparison.
-
@gavs
If the icons it uses are generic (not distributed with the app), you'll need an icon theme that has them. The Gnome one is fairly complete.
-
Well, then it *should* work as gmpc has these icons as a dependency:
$ grep icon *dep
gmpc.tcz.dep:hicolor-icon-theme.tcz
-
The hicolor theme is a placeholder - its size is 8kb.
-
Oh well. But then what extension are they in?
-
The hicolor theme is a placeholder - its size is 8kb.
Total: 25 K (1 file, 341 directories)
:o
Hahaha, something had always made me feel weird about that package on many opportunities, but I just never could pinpoint down what... :P
-
Oh well. But then what extension are they in?
Any that has them ;)
As mentioned, gnome-icon-theme is fairly complete. There are several other icon themes available, in different styles etc, which may or may not have the icons used by a particular app.
-
Ok, then the icons are not generic I guess.
I found something in /usr/local/share/gmpc/icons
-
The extension 'shared-mime-info.tcz' is required for the GMPC icons to appear. Should this be a dependency somewhere?
-
IMHO thats sounds more like a candidate for a recommendation in .info file than a mandatory dependency.
-
I'm confused. I have tested this with "base norestore" and agree to gavs - with shared-mime-info.tcz, all icons will displayed.
What should I do? Adding shared-mime-info as a dependency is no problem for me. But then we get problems somewhere else?
-
Can someone please explain why the icons are displayed when the extension "shared-mime-info" was loaded? This extension still contains no icons, right?
.info says :
Description: Database for common mime types.
I bring mime types with very different things in context.
???
-
I believe the icons are in /usr/local/share/gmpc/icons. I viewed some of the png files and these are the icons that appear in gmpc when shared-mime-info is loaded.
I do not have experience with mime, but it seems that the database of common mime types may be used by an application, like gmpc, or by a desktop, like gtk, to associate the file containing the data with it's respective application command. The specification page fore shared-mime
http://www.freedesktop.org/wiki/Specifications/shared-mime-info-spec
has links to 'GTK+ file selector' as well as 'Icon theme specification'. I am not competent to understand how these are implemented. Maybe somebody else who knows can give a simple explanation.
-
I agree, probably there is used some mapping functionality of shared-mime-info by gmpc.
I also found some information in the net (e.g. freeBSD) that shared-mime-info is a dependency for running gmpc.
I will update the .dep file and submit.
Thank you for your efforts.