The newer versions of ALSA (the Advanced Linux Sound Architecture) enable software mixing by default. All sounds which are played are converted to 48kHz (by default) and mixed in software. When I installed the new Ubuntu and it was set up this way, I was somewhat concerned about the sound quality implications of this setup. I dove into the ALSA source and discovered some very interesting things.

The first issue is the actual mixing. This is done with 24 bits of precision (32 bits are used internally, but the lowest 8 are used for saturation). The algorithm seems to be fairly good and I don't see any major quality implications are using it.

The second (and much bigger) issue is sample rate conversion. Obviously for software mixing all the signals need to be converted to a single rate. This rate, by default, is 48kHz. The algorithm used by default is a very rudimentry linear interpolation algorithm. This algorithm is fast but very low quality and is likely to audibly degrade the sound quality of 44100 material played through a mixed device. I tested this SRC using a loopback cable and some generated square, sine and triangle waves of various frequencies. It appears to add harmonic distortion of around -10dB in some cases and about -20dB on music. I'll post some graphs when I get home this afternoon.

There are a number of solutions to this problem.

1) Install the libasound_module_rate plugin and set defaults.pcm.rate_converter "samplerate_best" in your .asoundrc. This plugin uses the SRC_SINC_BEST_QUALITY algorithm from libsamplerate and seems to offer excellent quality. The problem here is that most distributions don't package this plugin and it is only included with very new versions of ALSA. I would say this is the ideal solution and it would be nice if the ALSA developers would make this (or at least libsamplerate's SRC_SINC_FASTEST algorithm) the default.

2) Set the dmix plug to use 44.1kHz. This is great if you are mostly listening to 44.1kHz material, but not so useful if you are listening to a mixture of 48kHz and 44.1kHz material.

3) Create seperate plugs for 44.1kHz and 48kHz material. This works fine if you don't want software mixing to work when playing both types of material simultaneously. A good setup here would be a 44.1kHz plug for used by default and by your MP3 player and a 48kHz plug used by your movie player. System sounds and other stuff can use either (I don't generally care about sound quality when watching Google Video content, for example).

ALSA by default seems to offer very dissapointing sound quality, but it is possible to set it up to offer much better quality. I will post a detailed guide in the next couple of days to explain how to set up your Linux machine for better playback and capture quality.

At least for Creative game soundcards with only one frequency of 48 kHz setting dmix plug to 44.1 kHz makes nothing good, the only way is to setup ALSA use high quality resampler to 48 kHz. It will be very useful to have good manual how to make it!

That is another good argument for high quality SRC in ALSA. It would be quite a bonus to Live!/Audigy owners to have a high quality SRC available, especially as these cards are well supported by ALSA already.

Thanks for the info. I'm replacing amarok and foobar with an mpd backend using alsa. It's amazing how difficult the latter is to setup properly.

After quick look at sources of ALSA I can say what rate converter plugin available only in version 1.0.11 or newer, for compiling plugin libsamplerate must be installed (together with developer files, for debian/ubuntu it's libsamplerate0-dev package). Also, ubuntu alsa-plugins even in 1.0.11 use only jack plugin from the sources when build binary package. I've open new bug at ubuntu launchpad.net, feel free to confirm.

Alsa since 1.0.9 has had much more sensible defaults (like dmix enabled by default, which despite the current quality problems, is a good idea) and is easier to set up. You could also have a look at my .asoundrc frontend kasound, which is still beta but might offer some help. I agree with you, though, that ALSA is a pain to set up. The developers have been doing a good job on making it easier recently.

iGold - I'll post to confirm that bug in alsa-plugins as soon as my net connection starts behaving. I am also posting a bug report against the equivalent Debian package.

Update: I have posted about this issue to the alsa-devel mailing list and received a number of good responses. Hopefully there will be enough interest among alsa developers that this issue will be fixed soon. I see it as a bit of a showstopping bug in ALSA and hope to communicate that to the list.

One of the more interesting replies I got was:

To which I replied

While this isn't, in my opinion, as big a problem as the bad SRC, it is one more problem with dmix and a reason you shouldn't use it for music playback (for now, at least) until this problem is fixed. Without dmix, ALSA's sound output quality isn't a problem - so don't panic about it.

Does anybody know how, for example, Foobar 2000's DSPs handle this problem of chunk size mismatch? Or do they not use chunks?

Thanks. Most of my alsa problems were to do with support of my chipset. Now my problems are mythtv wanting to use the card exclusively, even through ALSA, and software packaged with FC5 still using OSS. Yes, Firefox, i'm looking at you

Is this issue related to upstream alsa-plugins sources too? It's definitely debian/ubuntu packaging issue, are the developers want to fix it in debian? Or there is some other problem in alsa-plugins?

According to frequencies - is default linear alsa's SRC has no such problem? If it has the more quality algorithm will be already better till internal structure of ALSA not reworked.

What I was hoping to achieve with alsa-devel was to get a change in the default behaviour of ALSA on desktop systems to use a higher quality SRC algorithm. In my mind, while getting the plugin packaged is a start, many people are complaining that ALSA sound quality is poor and not that many know that it can be improved. It would be nice if the default behaviour of ALSA was improved so everybody could benefit from better sound quality.
From my reading of the source the linear SRC does still have this problem - but it's effect (compared to that of the poor SRC) is comparatively small. I agree that implementing a higher quality algorithm by default will improve things immensely. It would be interesting to know how Windows and OSX solve this problem.

Don't forget that there's the hw devices as well. Those should outright bypass dmix and directly output to the card. Sure, you don't get software mixing, but if you got a decent card it should do hardware mixing.

You might still get the resampling problem due to the card itself, but depending on the model, it might be just as good as samplerate_best.

The hw devices do go straight to the hardware, which solves the whole problem. However, it would still be nice to have good quality AND software mixing. Also, many cards, like ones based on the ENVY24HT, HT-S and PT (which include the AV710, ESI Juli@ many other popular cards) don't do hardware mixing.

For what it's worth, the samplerate (SNR 97dB, bandwidth 80%) plugin measures very well on my system and uses up an extra 4% cpu (over the standard linear interpolator). samplerate_best (SNR 97dB, bandwidth 97%) uses up an extra 20% (for a total of 22% when playing an MP3) which is, for me, unacceptably high. A happy medium is the samplerate_medium setting, offering (according the the libsamplerate docs) an SNR of 97dB and bandwidth of 90%, while using 7% CPU on my system. I haven't tried to ABX the two yet, but I will over the course of the next few days and give results. Based on the measurements, it shouldn't be too hard (1% THD in the linear version, for a start).

I have built packages of libasound2, libasound2-dev and libasound2-plugins version 1.0.11 for Ubuntu Dapper (standard version is 1.0.10) with full samplerate support. Drop me a PM and I will email them to you, or find web hosting for them. If there is any demand, I will build libasound2-plugins with samplerate support for Debian unstable at work tomorrow.

Hmm, thought I'd give this a try.



I don't notice any CPU usage difference at all between them. (I got a Celeron D 2.93Ghz) Although, I did notice a difference in sound between samplerate and samplerate_best. But, I don't really notice any difference between hw and samplerate_best. Guess in my case my SB Live! OEM is decent enough.

I sadly don't have any "professional" testing waves to use, so I was just using music I had to do the tests. Using just samplerate, there is a kinda of, muffleness in the highend. But both samplerate_best and hw sound, well, as they should I guess. Wish I had a patchcord, I'd do some recordings to see just how close samplerate_best and hw are.

What version of ALSA are you using? Do you have the rate plugin installed (look what's in /usr/lib/alsa-lib if you aren't sure). I would be very interested if you did not have an increase in CPU usage with the plugin.

Well, Kernel ALSA module version is 1.0.11rc4 (Kernel is 2.6.17-gentoo-r5), alsa-lib is 1.0.12_rc1-r1 and alsa-plugins is 1.0.12_rc1-r1. And rate_samplerate is present in /usr/lib/alsa-lib:



Maybe for some strange reason, my Celeron D just handles mucking around with audio data really well. It's not like I'm using any major CFLAGS either, just "-march=prescott -Os -pipe -funroll-loops -fomit-frame-pointer", that's it.

What did you use to play the files? I tried with mplayer first and got no change in cpu usage, but it jumped to around 27% using mpg321. I guess mplayer might automatically do the resampling internally.

I tried just mplayer. I haven't gotten around to emerging any other CLI players yet, so I'm not sure about mpg123/mpg321. For some reason, Audacious doesn't seem to like me setting the ALSA device to 48k or 48khq. Says it can't find the device.

K, just tried in Xine, ~12% CPU usage with samplerate, samplerate_best and hw.

Although, I did notice that if I set the pcm.48k or pcm.48khq as pcm.!default, other apps that use waves, (eg: aMSN using SDL's playsound command) tended to stutter on playback. And just now test playing a wave in mplayer causes the stuttering as well, but, only on short waves. On longer waves, there's a tiny stutter at the beginning, 1secs worth, but it's smooth playing after that. Odd that it only happens on waves, but not MP3s, OGGs or Flacs.

mplayer by default resamples everything to 48kHz internally, as far as I can see. Try using aplay (comes with the alsa-utils source) to play back a 44.1 wave file.

Hmm, well, I tried playing a wave of the first track from the Halo 2 OST with aplay, and well, I'm getting an error. If I just use "aplay Halo\ 2\,\ Volume\ 1\ -\ 01\ -\ Halo\ Theme\ \(Mjolnir\ mix\).wav" it works fine. But if I try to use "aplay --device=48k Halo\ 2\,\ Volume\ 1\ -\ 01\ -\ Halo\ Theme\ \(Mjolnir\ mix\).wav" or "aplay --device=48khq Halo\ 2\,\ Volume\ 1\ -\ 01\ -\ Halo\ Theme\ \(Mjolnir\ mix\).wav" it tosses up an error.

aplay --device=48k Halo\ 2\,\ Volume\ 1\ -\ 01\ -\ Halo\ Theme\ \(Mjolnir\ mix\).wav


aplay --device=48khq Halo\ 2\,\ Volume\ 1\ -\ 01\ -\ Halo\ Theme\ \(Mjolnir\ mix\).wav


Wonder if I'm missing something from my .asoundrc. I pretty much based it on the info from the PCM (digital audio) plugins page.

.asoundrc


EDIT:

Aha! Figured out what I was doing wrong. plug should be rate, and rate_converter should be converter.


Seems to work fine now. K, thanks to top I'm able to see that using 48k causes aplay to 5% CPU, and 48khq causes aplay to use 25% CPU, and hw only uses 0% CPU.

Still need to get a patchcord and see about doing some ABX tests to see if I can tell the difference between 48khq and hw. There is a difference with 48k though, mostly muffleness in the highend.

That's more like the CPU figures I was expecting, or I would be very dissapointed with my Athlon

For a start at ABXing, I would recomment the chenoa and mustang samples (search for them, I think I got them from ff123's site). I have done the default versus samplerate_high and samplerate_linear versus samplerate_high but have had no success with samplerate versus samplerate_high. It would be very interesting to see how you get on.

Well, I managed to do a simple form of ABX'ng. Pretty much I just had a friend make up some .asoundrc configs for me to try. Each config had three devices setup, Test1, Test2 and Test3. Pretty much I just had to try and figure out which of Test2 and Test3 was Test1. And I was using the mustang and duel samples to test with.
The commandline I was using was:


We started out with a simple comparing of samplerate and samplerate_order. Out of the 5 he sent me, I got 5 correct. Was pretty simple considering that samplerate_order is pretty bad. We just did this one to make sure my ears were working.

Comparing samplerate and samplerate_best managed to embarrass me though. Out of 10, I got 1 right, 2 wrong, and 7 unsure. And honestly, I think the one I got right was a guess.

Based on those results, I decided that a test between samplerate and hw was needed. Out of the 10 tests, I said unsure on all of them. I honestly could not tell a difference between them.

Guess for me, using just hw for my SB Live! OEM is good enough. But, if I were to use the onboard sound, guess I'd just use samplerate and not waste the CPU that samplerate_best takes.

If I understand correct input audio data for my SB Live! 24-bit must be in 48 (or 96) kHz. Under Windows creative's drivers do this work and convert 44.1kHz to 48kHz. And under Linux ALSA does the same things (not at dmix stage, but at hardware driver's one).
Or this card (and similar Creative's cards from Live!/Audigy family) can hardware resample 44.1kHz to 48kHz? It's important for me because from Windows review resampling on this card is bad and good software resampler required for a good sound (resampler of the card (or driver?) is bad but the DAC is pretty good especially for music playback in stereo mode). So when I using hw: device in ALSA is the card resample 44.1 kHz itself of ALSA does it before (as I can suppose just linear)?
If ALSA does then output through dmix (with default resampling) and to hw directly must get the same software conversion by ALSA and there is no difference at all between dmix+linear resampling and hw output.

The thing with the hw device, is that it's pretty much a direct port to the sound hardware. All ALSA does with it is set the path and toss the data at the card. Thus, the data you send must be something that the DAC can handle because ALSA won't touch it.

Thus by using the hw device with the Live!/Audigy cards, if it's doing resampling, it's doing the resampling in hardware.

Now, I'm not too sure about this, but I would hazard a guess that the EMU chip is doing the resampling. Hey, it would explain why it gets so hot. (I even put a heatsink on mine because I was getting worried.)

According to Wikipedia:(But DAC in it better then in Audigy 2 Value, it's as in Audigy 2 ZS.)
So your Live! 5.1 and my Live! 24bit 7.1 are not from same family. And may have different quality hardware resampler.

But knowledge about ALSA work with hw device is useful, thank you for explanation.

Can anyone give link to good test sample for checking resampling quality? I know about dial.wav but maybe better test sample exists?

hi iGold: here's some more hints about resampling and the EMU 10k1/2 - those guys btw know everything there is to know about them...
http://kxproject.lugosoft.com/direct.php?language=en

Indeed - samplerate_order is truly awful. samplerate_linear is much better, but still not much good.
This one is very easy with udial.wav, and possible the chenoa sample with headphones(search for them if you don't have them). I failed with everything else though.
You could try chenoa (search for it) - that's always treated me well for resampling tests. As far as I remember, the Live 24 can't resample in hardware at all, it's been a while since I read the specs but the lack of the EMU10k processor suggests that it lacks this capability.

Well, I just did a quick test of udial, before I get around to ABXng with it. Man, playing that through hw is havoc with my SB Live!, there's a weird sweeping noise that starts after the third tone. And, I'm getting the same sound with the default device as well. Using samplerate_linear and dmix the sound is quite a bit different, more smoother I guess.

... OK, samplerate_order sounds exactly the same as hw, just the weird noise is a tiny bit louder.

And, I can tell right away that samplerate sounds better on udial than samplerate_best. samplerate_best has some added freqs on the last four tones. Same with samplerate_medium. What I find odd is that the default device is supposed to use dmix, or so that's what the ALSA docs have been saying. But clearly by the sounds of it, it's just be an alias to hw. Maybe the ALSA setup under Gentoo is different, not sure...

default definately goes through dmix on my machine (Ubuntu 6.06), but it is possible that Gentoo is different. To me, udial sounds best on samplerate_medium - but it is a very artificial sample so i'm not too worried about optimising that one.

Now I also have tested different samplerate_* modes (not on my home Live! 24bit, but on work's integrated VIA 8235 with VT1616i). Sound from direct hw:0 output and dmix with samplerate_linear are the same. samplerate_order just terrible but samplerate (SRC_SINC_FASTEST) gives best, clear sound. medium and best variants give sound worse then samplerate but more better linear.
Strange sample! It makes fast to best and best to non best!

Sorry guys for this Off-topic, but does have anyone an idea (or has tested) the same on windows? Does it have the same low-quality mixer or converter? If yes, what are the possibilities to make it better?

If this is dependent on the hardware you use, I am mostly interested in the HDA built-in audio chips in notebooks (for example SoundMAX AD1986A)

Well, looking at the confs in /usr/share/alsa/cards, EMU10K1.conf does not use dmix for default. Almost all the other card's conf uses dmix, but the emu10k1 doesn't. I even checked the ALSA CVS, no dmix for the emu10k1. So, because of this, ALSA just uses plughw instead for default. So I guess only certain cards have been updated to use dmix. Even the conf for my on-board sound, VIA8237, doesn't use dmix as default.

Aha! According to http://alsa.opensrc.org/index.php?page=DmixPlugin:
NOTE: For ALSA 1.0.9rc2 and higher you don't need to setup dmix. Dmix is enabled as default for soundcards which don't support hw mixing.

Thats why dmix isn't enabled for my SB Live! 5.1, it supports hardware mixing.

As I know at least Live! 24bit on windows has the same problem with resampling and recommended way for sound/music playback is using software resample plugins for the player, but this solution is not system wide and will not work for every other applications.
So now ALSA with rate plugin gives better way to solve resampling issue then player based solutions for windows. It's nice.

According to the docs, dmix is enabled by default for cvards that don't support hardware mixing. Emu10k1 cards do - so they default to plughw.

The resampling problem is very usual with low cost soundcards also in Windows. My solution in Windows has been foobar2000 with resampler. There are few quite good resamplers for foobar2000 and the default PPHS resampler is quite good. You can test your audio hardware resampling with it. Use the problem sample mentioned earlier in this thread and test the resampler 48 kHz on and off. Check which setting sounds best with your hardware.

Today I had a quick try to compile alsa-lib 1.0.11 from ubuntu repository at my amd64 box but got strange errors and at the end got strange package. aplay <sample.wav> gives me errors about absence of dmix, etc. But it's no problem, I'll try later.
The good thing I got was the interesting behavior. When I play udial.wav directly to card with 'aplay -D hw:1 udial.wav' it gave me warning about "requested 44100 Hz, got 48000 Hz" and played absolutely clear but a bit higher and quicker. So it just played 44.1kHz sample at frequency 48kHz w/o any resampling at all.
As conclusion: ALSA hardware driver (from kernel) doesn't resample anything, it is work for ALSA library. And resampling works only with correct config for given soundcard.

Indeed it doesn't. The hw devices are completely raw - they don't do any SRC, they don't change the bit depth and they seem to be fairly low latency. It's like kernel streaming for Linux.

After successful upgrade of alsa{-driver,lib,util,plugins} on my amd64 box I checked different samlerate variants on Live! 24bit and there is no difference between "samplerate", "samplerate_medium" and "samplerate_best" with udial.wav - it sounds perfect anyway.

So "samplerate" is a winner for me! Minimal CPU usage with a good quality.

BTW: alsa 1.0.12 released recently.

Checked udial.ape with my KOSS Porta Pro & SoundMAX AD1986A. No EQ, no SRS, just the sound & the PPHS resampler on and off. I could not hear ABSOLUTELY any difference. If I enabled ultra mode, i could hear some pops, but not otherwise. Does that mean, that windows' mixer (or my hardware mixer - if it exists at all) does a good job?
I could not find the chenoa sample though.

Maybe your card support 44100 Hz natively and no resampling ever needed for it?

This is what the data sheet says:
Front DAC PCM Rate Register [15:0] (Sample Rate):
Function:
The sampling [24bit] frequency range is from 7 kHz (0x01B58) to 48 kHz (0xBB80) in 1 Hz increments. If 0 is written to VRA, then the
sample rates are reset to 48 kHz.

+ there is a doule-rate DAC for 96kHz. This probably means that iGold was right.
Further reading revealed that it had a hardware equalizer, analogue 5.1 downmixing to 2 channels, and several analogue summars for mixing inputs.

So if its DAC can handle any sample rate, the question arises, what would happen, if I used two different audio players, one at 44.1kHz and the other at 48kHz. It this case DirectSound would have to do the resampling, correct?

Update:
It's now clear.
The Windows mixer has also several levels of quality. It is accessble under: Control Panel/Sound Devices/Speaker Settings/Advanced/Performance.
I could clearly hear the problem with the lowest quality evel, but the mid and highest was already artefact-free with udial. Which also means that my sound card does NOT support 44.kHz by default, only with resampling.

The good news is, that I could not spot any increased CPU activity with the highest resampling quality level. This was the case regardless of the hardware acceleration level.

New version (1.0.12-1) libasound2-plugins in Debian fixes bug #384029 - it includes rate (and others) plugin now.

http://www.kikeg.arrakis.es/lowpass/Chenoa_16KHz.ape

A similar one:

http://www.kikeg.arrakis.es/lowpass/Androgyny_16KHz.ape

They are Monkey's Audio, so I think you'll need Windows to decode them, sorry.

udial.wav is a more extreme case, it should expose flaws more easily. But beware of listening to it at high levels, it can fry your tweeters and even your power amp.

kmixer, which is part of windows, is generally known for doing a terrible job with audio. There are several solutions for playback which often involve either the creation of virtual asio devices or as-is the case with foobar2000 kernel streaming (which bypasses kmixer altogether).

Of course, if you're doing this with anything other than some form of digital-out to a dac you're unlikely to notice the difference because the electromagnetics inside a pc case seriously degrade the quality of any analog in/out. Similarly so if you're listening to audio on laptop speakers.

~Chad

kmixer doesn't do that bad at the default setting of best quality of sample rate conversion.

See kmixer resampling measurements at http://www.kikeg.arrakis.es/measurements/

Edit: as to the need of outboard DACs for noise free audio, see the analog measurements. They are performed with and unexpensive, non-balanced internal card. Balanced internal soundcards usually offer even better noise performance. One of the best soundcards I know of (if not the best), the Lynx Two, is internal.

Kmixer does pretty well, and the CPU load is fairly low, too. Does anybody know what algorithm is used?

Sound card designs have come a long way - they perform amazingly well in what is a fairly harsh environment with loads of noise and pretty ugly power. It constantly amazes me how well good cards (like the Lynx Two) do in such a bad environment.

I tried to build kasound on Ubuntu Edgy and it asks for "KDE headers". Which package contains those? Or, do you have a package? (a Dapper one might work, too)

does anyone know if the sample perioid issue has been resolved in ALSA 1.0.13 ? I just got the libsamplerate plugin to work with ALSA and it sounds very good.

Hi cabbagerat,

Thanks for starting this excellent thread and your serious investigation.

Can you help me? I am using an old Linux distribution that only has ALSA 1.0.8, and i don't really want to upgrade this machine for the moment. The sound card is the onboard nvidia AC97 with an ALC850 codec, which I have connected using SPDIF to my A/V receiver. This sound card cannot output 44.1kHz to the SPDIF, so everything gets upsampled to 48kHz. And the default upsampling in ALSA 1.0.8 is the horrible linear interpolator - I can quite literally hear the artifacts (mostly aliasing) caused by the ALSA resampling.

I am using Amarok with Xine as the audio engine, and ALSA as the driver. I am not really feeling up to the task of trying to integrate the latest ALSA drivers, libraries and utilities to my heavily patched 2.6.11 kernel and relatively old Linux distribution.

Do you have any suggestions?

I have just read the piece of news about the debian update; this is great.
I am trying to figure out how I could alter /usr/share/alsa/pcm/dmix.conf so that it would use the samplerate_best plugin. It would probably the best way to modify the debian package, because the default configurations in /usr/share/alsa/cards/ would all be affected.

This is a bit offtopic maybe, but do you guys know how JACK Audio Connection Kit handles resampling? I always use JACK for Audio work on linux. (JACK backend driver is ALSA)

Settings I use are:
Realtime, 64 Frames/Period, 48000 Sample Rate, 2 Periods/Buffer, Forced 16 bit
Latency in this configuration, without realtime kernel patches, seems to be ~2.67ms according to qjackctl?

Anyway... I'm no expert in audio in linux. I hope someone knows more