HydrogenAudio

CD-R and Audio Hardware => Audio Hardware => Topic started by: cabbagerat on 2006-08-21 10:56:22

Title: ALSA sample rate conversion
Post by: cabbagerat on 2006-08-21 10:56:22
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.
Title: ALSA sample rate conversion
Post by: iGold on 2006-08-21 11:38:17
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!
Title: ALSA sample rate conversion
Post by: cabbagerat on 2006-08-21 12:13:53
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.
Title: ALSA sample rate conversion
Post by: seanyseansean on 2006-08-21 12:34:50
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.
Title: ALSA sample rate conversion
Post by: iGold on 2006-08-21 12:47:48
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 (https://launchpad.net/distros/ubuntu/+source/alsa-plugins/+bug/57089) at ubuntu launchpad.net, feel free to confirm.
Title: ALSA sample rate conversion
Post by: cabbagerat on 2006-08-21 13:03:22
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.
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 (http://www.sourceforge.net/projects/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.
Title: ALSA sample rate conversion
Post by: cabbagerat on 2006-08-21 16:13:48
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:
Quote
The problem is actually far more complicated than you described. A fair amount of ALSA core will have to be modified to really fix the problem. The main problem is the buffer and period sized as they pass through dmix. For example, if the sound card hardware is running with 1024 samples per period at 48000, and an application wished to use a sample rate of 44100, the application should really get 940.8 samples per period. That is nor possible, so the application gets 940. dmix then tries to convert 940 samples to 1024 samples ready for the hardware. So, even if the dmix algorithm used the super high quality sample rate conversion function, the actual rate change applied would still be slightly off.

To which I replied
Quote
In the scenario that you presented the application is told that there are 940 samples per period. ALSA, internally, converts these to 1024 samples per period at 48kHz sample rate. So the material (sampled at 44100Hz) is played back at a rate of 44062Hz? I don't know enough about the field to know if this error (0.08%) will be audible.

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?
Title: ALSA sample rate conversion
Post by: seanyseansean on 2006-08-21 16:15:22

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.
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 (http://www.sourceforge.net/projects/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.


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
Title: ALSA sample rate conversion
Post by: iGold on 2006-08-21 16:52:01
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.

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.
Title: ALSA sample rate conversion
Post by: cabbagerat on 2006-08-21 16:57:44
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?

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.
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.
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.
Title: ALSA sample rate conversion
Post by: CyberFoxx on 2006-08-21 18:35:25
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.
Title: ALSA sample rate conversion
Post by: cabbagerat on 2006-08-21 19:52:43
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.
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.
Title: ALSA sample rate conversion
Post by: CyberFoxx on 2006-08-21 21:54:13
Hmm, thought I'd give this a try.

Code: [Select]
pcm.48khq {
        type plug
        slave {
                pcm "hw:0,0"
                rate 48000
        }
        rate_converter "samplerate_best"
}

pcm.48k {
        type plug
        slave {
                pcm "hw:0,0"
                rate 48000
        }
        rate_converter "samplerate"
}


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.
Title: ALSA sample rate conversion
Post by: cabbagerat on 2006-08-21 22:28:50
Hmm, thought I'd give this a try.
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.
Title: ALSA sample rate conversion
Post by: CyberFoxx on 2006-08-21 22:48:44
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:

Code: [Select]
cyberfoxx@Sally /usr/lib/alsa-lib $ ls -al libasound_module_rate_samplerate*
lrwxrwxrwx 1 root root   35 2006-08-21 12:40 libasound_module_rate_samplerate_best.so -> libasound_module_rate_samplerate.so
-rwxr-xr-x 1 root root  994 2006-08-21 12:40 libasound_module_rate_samplerate.la
lrwxrwxrwx 1 root root   35 2006-08-21 12:40 libasound_module_rate_samplerate_linear.so -> libasound_module_rate_samplerate.so
lrwxrwxrwx 1 root root   35 2006-08-21 12:40 libasound_module_rate_samplerate_medium.so -> libasound_module_rate_samplerate.so
lrwxrwxrwx 1 root root   35 2006-08-21 12:40 libasound_module_rate_samplerate_order.so -> libasound_module_rate_samplerate.so
-rwxr-xr-x 1 root root 5176 2006-08-21 12:40 libasound_module_rate_samplerate.so


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.
Title: ALSA sample rate conversion
Post by: eido on 2006-08-22 00:19:56
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.


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.
Title: ALSA sample rate conversion
Post by: CyberFoxx on 2006-08-22 01:12:29
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.
Title: ALSA sample rate conversion
Post by: cabbagerat on 2006-08-22 07:37:04

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.
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.
Title: ALSA sample rate conversion
Post by: CyberFoxx on 2006-08-22 22:12:43
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
Code: [Select]
ALSA lib pcm_rate.c:1308:(snd_pcm_rate_open) Cannot open library for type x▒A
aplay: set_params:962: Unable to install hw params:
ACCESS:  RW_INTERLEAVED
FORMAT:  S16_LE
SUBFORMAT:  STD
SAMPLE_BITS: 16
FRAME_BITS: 32
CHANNELS: 2
RATE: 44100
PERIOD_TIME: (85331 85332)
PERIOD_SIZE: (3763 3764)
PERIOD_BYTES: (15052 15056)
PERIODS: (3 4)
BUFFER_TIME: (341315 341316)
BUFFER_SIZE: 15052
BUFFER_BYTES: 60208
TICK_TIME: 1000


aplay --device=48khq Halo\ 2\,\ Volume\ 1\ -\ 01\ -\ Halo\ Theme\ \(Mjolnir\ mix\).wav
Code: [Select]
ALSA lib pcm_rate.c:1308:(snd_pcm_rate_open) Cannot open library for type te_best
aplay: set_params:962: Unable to install hw params:
ACCESS:  RW_INTERLEAVED
FORMAT:  S16_LE
SUBFORMAT:  STD
SAMPLE_BITS: 16
FRAME_BITS: 32
CHANNELS: 2
RATE: 44100
PERIOD_TIME: (85331 85332)
PERIOD_SIZE: (3763 3764)
PERIOD_BYTES: (15052 15056)
PERIODS: (3 4)
BUFFER_TIME: (341315 341316)
BUFFER_SIZE: 15052
BUFFER_BYTES: 60208
TICK_TIME: 1000


Wonder if I'm missing something from my .asoundrc. I pretty much based it on the info from the PCM (digital audio) plugins (http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html) page.

.asoundrc
Code: [Select]
pcm.48khq {
        type plug
        slave {
                pcm "hw:0,0"
                rate 48000
        }
        rate_converter "samplerate_best"
}

pcm.48k {
        type plug
        slave {
                pcm "hw:0,0"
                rate 48000
        }
        rate_converter "samplerate"
}


EDIT:

Aha! Figured out what I was doing wrong. plug should be rate, and rate_converter should be converter.
Code: [Select]
pcm.48khq {
        type rate
        slave {
                pcm "hw:0,0"
                rate 48000
        }
        converter "samplerate_best"
}

pcm.48k {
        type rate
        slave {
                pcm "hw:0,0"
                rate 48000
        }
        converter "samplerate"
}


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.
Title: ALSA sample rate conversion
Post by: cabbagerat on 2006-08-22 22:53:12
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.
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.
Title: ALSA sample rate conversion
Post by: CyberFoxx on 2006-08-23 22:34:42
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:
Code: [Select]
aplay --quiet --device=<device> <wave>


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.
Title: ALSA sample rate conversion
Post by: iGold on 2006-08-24 04:39:58
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.
Title: ALSA sample rate conversion
Post by: CyberFoxx on 2006-08-24 06:20:20
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.)
Title: ALSA sample rate conversion
Post by: iGold on 2006-08-24 06:52:25
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:
Quote
The Sound Blaster Live! 24-bit was not actually a member of the Sound Blaster Live! family, because it lacked the EMU10k1/10k2 processor. It was a stripped down version of the Audigy 2 Value, with an SNR of 100 dB, software based EAX, no advanced resolution DVD-Audio Playback, and no Dolby Digital 5.1 or Dolby Digital EX 6.1 playback.
(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?
Title: ALSA sample rate conversion
Post by: Patsoe on 2006-08-24 08:21:15
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 (http://kxproject.lugosoft.com/direct.php?language=en)
Title: ALSA sample rate conversion
Post by: cabbagerat on 2006-08-24 09:07:32
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.

Indeed - samplerate_order is truly awful. samplerate_linear is much better, but still not much good.
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.
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.
Can anyone give link to good test sample for checking resampling quality? I know about dial.wav but maybe better test sample exists?
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.
Title: ALSA sample rate conversion
Post by: CyberFoxx on 2006-08-24 10:11:44
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...
Title: ALSA sample rate conversion
Post by: cabbagerat on 2006-08-24 10:46:48
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.
Title: ALSA sample rate conversion
Post by: iGold on 2006-08-24 10:48:05
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!
Title: ALSA sample rate conversion
Post by: Matyas on 2006-08-24 11:05:24
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)
Title: ALSA sample rate conversion
Post by: CyberFoxx on 2006-08-24 11:45:15
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.


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 (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.
Title: ALSA sample rate conversion
Post by: iGold on 2006-08-24 11:49:40
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.
Title: ALSA sample rate conversion
Post by: cabbagerat on 2006-08-24 12:02:58
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.
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.
Title: ALSA sample rate conversion
Post by: askoff on 2006-08-24 21:23:42
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)

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.
Title: ALSA sample rate conversion
Post by: iGold on 2006-08-25 04:28:46
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.
Title: ALSA sample rate conversion
Post by: cabbagerat on 2006-08-25 08:02:25
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.
Title: ALSA sample rate conversion
Post by: iGold on 2006-08-25 15:36:07
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.
Title: ALSA sample rate conversion
Post by: Matyas on 2006-08-26 02:37:32
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.


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.
Title: ALSA sample rate conversion
Post by: iGold on 2006-08-26 09:46:36
Maybe your card support 44100 Hz natively and no resampling ever needed for it?
Title: ALSA sample rate conversion
Post by: Matyas on 2006-08-26 10:25:37
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.
Title: ALSA sample rate conversion
Post by: iGold on 2006-09-11 15:46:23
I am also posting a bug report against the equivalent Debian package.

New version (1.0.12-1) libasound2-plugins in Debian fixes bug #384029 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=384029) - it includes rate (and others) plugin now.
Title: ALSA sample rate conversion
Post by: KikeG on 2006-09-11 16:07:02
http://www.kikeg.arrakis.es/lowpass/Chenoa_16KHz.ape (http://www.kikeg.arrakis.es/lowpass/Chenoa_16KHz.ape)

A similar one:

http://www.kikeg.arrakis.es/lowpass/Androgyny_16KHz.ape (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.
Title: ALSA sample rate conversion
Post by: cheuschober on 2006-09-13 00:06:20
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)


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
Title: ALSA sample rate conversion
Post by: KikeG on 2006-09-13 07:52:29
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/ (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.
Title: ALSA sample rate conversion
Post by: cabbagerat on 2006-09-13 08:46:55
See kmixer resampling measurements at http://www.kikeg.arrakis.es/measurements/ (http://www.kikeg.arrakis.es/measurements/)
Kmixer does pretty well, and the CPU load is fairly low, too. Does anybody know what algorithm is used?

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.
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.
Title: ALSA sample rate conversion
Post by: towolf on 2006-09-13 14:22:16
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)
Title: ALSA sample rate conversion
Post by: askoff on 2006-11-10 22:35:01
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.
Title: ALSA sample rate conversion
Post by: Gigapod on 2006-11-14 10:43:23
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?
Title: ALSA sample rate conversion
Post by: damaki on 2006-11-14 11:04:10
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.
Title: ALSA sample rate conversion
Post by: profoX on 2006-11-14 11:47:09
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
Title: ALSA sample rate conversion
Post by: cabbagerat on 2006-11-15 14:30:43
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.
Which distribution? Some are more easy than others to graft new parts onto old systems.

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.
From the documentation included with the source of ALSA plugins 1.0.11:

Quote
You can use this rate converter plugin by defining a rate PCM with "converter" parameter, such as:

   pcm.my_rate {
      type rate
      slave.pcm "hw"
      converter "samplerate"
   }

The plug plugin has also a similar field, "rate_converter".

Or, more easily, define a global variable "defaults.pcm.rate_converter",
which is used as the default converter type by plug and rate plugins:

   defaults.pcm.rate_converter "samplerate"

Write the above in your ~/.asoundrc or /etc/asound.conf.

The following converter types are available:

  - samplerate_best   Use SRC_SINC_BEST_QUALITY
  - samplerate_medium   Use SRC_SINC_MEDIUM_QUALITY
  - samplerate      Use SRC_SINC_FASTEST
  - samplerate_order   Use SRC_ZERO_ORDER_HOLD
  - samplerate_linear   Use SRC_LINEAR
I agree that modifying the defaults might be a good idea. The problem is finding a default that both those with old hardware and those with strict quality requirements will find acceptable. I think SRC_SINC_FASTEST is about right - but there are a lot of factors to consider.
Title: ALSA sample rate conversion
Post by: Gigapod on 2006-11-15 23:18:27
Which distribution? Some are more easy than others to graft new parts onto old systems.

Hi cabbagerat,
Thanks for taking the time to help. It's a Mandriva 2005, which I have promised myself to upgrade some day to Debian Etch or Ubuntu, but right now it has to stay that way. 
What do you recommend?
Title: ALSA sample rate conversion
Post by: cabbagerat on 2006-11-16 05:57:14

Which distribution? Some are more easy than others to graft new parts onto old systems.

Hi cabbagerat,
Thanks for taking the time to help. It's a Mandriva 2005, which I have promised myself to upgrade some day to Debian Etch or Ubuntu, but right now it has to stay that way. 
What do you recommend?
Unfortunately I have no experience with Mandriva whatsoever - I haven't used an RPM distro since RedHat 5, so I don't know what to advise. The short answer is that you need to update to ALSA lib 1.0.11 or later - but this might require more complex upgrades. You might successfully build ALSA-lib and ALSA-plugins from source and "make install" them, but I'm not sure.

It would probably be easier (if this is a home PC and not a server or something) to upgrade to Ubuntu 6.10 or the latest Fedora.
Title: ALSA sample rate conversion
Post by: wizkid on 2007-04-23 09:49:46
Has anyone gotten this to work on Fedora Core 6? I have alsa version 1.0.14rc (i think, i'm not at home right now) but i do not have the samplerate files in my /usr/lib/alsa-lib. Either Fedora puts them somewhere else, or they don't include them at all. Any ideas?
Title: ALSA sample rate conversion
Post by: wizkid on 2007-04-26 18:13:37
Scratch that, i got it working in Ubunty 7.04  ... now if i could only find a way to kill this insane popping/crackling  on trackchange...
Title: ALSA sample rate conversion
Post by: askoff on 2007-04-26 18:37:31
Scratch that, i got it working in Ubunty 7.04  ... now if i could only find a way to kill this insane popping/crackling  on trackchange...

Yes. That's very anoying issue. I hope it gets resolved soon.
Title: ALSA sample rate conversion
Post by: wizkid on 2007-04-26 23:04:26

Scratch that, i got it working in Ubunty 7.04  ... now if i could only find a way to kill this insane popping/crackling  on trackchange...

Yes. That's very anoying issue. I hope it gets resolved soon.


Seems to be alsa related too, since it happends no matter what player i'm using. Tried changing buffers and some other settings but to no avail... 
Title: ALSA sample rate conversion
Post by: seeker010 on 2007-05-07 06:56:07
Has anyone gotten this to work on Fedora Core 6? I have alsa version 1.0.14rc (i think, i'm not at home right now) but i do not have the samplerate files in my /usr/lib/alsa-lib. Either Fedora puts them somewhere else, or they don't include them at all. Any ideas?

yes. this is quite a good thread, I'm glad I found it!

for those that care
Code: [Select]
yum install libsamplerate-devel

then download alsa-plugins-1.0.14rc1a.tar.bz2     
go to downloaded directory and do
Code: [Select]
tar -jxvf alsa-plugins-1.0.14rc1a.tar.bz2
cd alsa-plugins-1.0.14rc1
./configure --prefix=/usr
make
make install
Title: ALSA sample rate conversion
Post by: samtek on 2008-05-27 11:39:07
I'm resurrecting an old thread (again) but I wanted to add something important. Amarok by default does not seem to obey .asoundrc or resamples by itself or something..... Either way it makes the udial sample sound terrible whereas mplayer (using alsa) and aplay sound fine. I have spent hours trying to fix this and I have finally succeeded. I am using arch linux. Here are my steps:

1. Install libsamplerate and alsa-plugins
2. Put "defaults.pcm.rate_converter "samplerate_best"" in .asoundrc (without the first and last "s)
3. Go to the amarok configuration, Engine tab, select alsa as the output plugin.
4. (This is the one that took me hours to figure out) Under 'ALSA Device Configuration' in the 'Mono' and 'Stereo' boxes put "hw:0" (again without the "s). This made the udial sample sound the same as with mplayer and I'm sure my music sounds more crisp
Title: ALSA sample rate conversion
Post by: cabbagerat on 2008-05-27 12:50:29
I'm resurrecting an old thread (again) but I wanted to add something important. Amarok by default does not seem to obey .asoundrc or resamples by itself or something..... Either way it makes the udial sample sound terrible whereas mplayer (using alsa) and aplay sound fine. I have spent hours trying to fix this and I have finally succeeded. I am using arch linux. Here are my steps:

1. Install libsamplerate and alsa-plugins
2. Put "defaults.pcm.rate_converter "samplerate_best"" in .asoundrc (without the first and last "s)
3. Go to the amarok configuration, Engine tab, select alsa as the output plugin.
4. (This is the one that took me hours to figure out) Under 'ALSA Device Configuration' in the 'Mono' and 'Stereo' boxes put "hw:0" (again without the "s). This made the udial sample sound the same as with mplayer and I'm sure my music sounds more crisp
On most ALSA configurations, using the "hw:0" devices bypasses dmix and resampling. I don't know what ArchLinux does, but I think the reason you don't hear the problem is that your card is playing udial at the native 44100Hz. What sound card do you have?

For the record, resampling to 48000 using samplerate_medium and samplerate_best with the newest libsamplerate sound absolutely perfect on udial.
Title: ALSA sample rate conversion
Post by: samtek on 2008-05-27 12:59:31
Interesting. I think you might be right about it bypassing dmix. Any ideas what I could change to get it to resample properly and go through my alsa settings? My CPU usage is lower when I use amarok than with mplayer which suggests it isn't using the samplerate_best setting I set. Why on earth do the default settings for alsa in amarok not use my .asoundrc?

I am using the onboard sound (AD1988 Chip) on my Asus P5B. I have no idea if it can play at 44100 but I would have thought that it doesn't.

edit: So...using "aplay -D plug:pcm.48khq *.wav" I get:
Quote
Playing WAVE 'udial.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
ALSA lib pcm_rate.c:1369:(snd_pcm_rate_open) Cannot find rate converter
Segmentation fault


I was using this .asoundrc:
Quote
pcm.48khq {
        type plug
        slave {
                pcm "hw:0,0"
                rate 48000
        }
        rate_converter "samplerate_best"
}


However if I use "defaults.pcm.rate_converter "samplerate_best"" in .asoundrc I get higher cpu usage than with no .asoundrc so the rate_converter is working. This is great (when using mplayer or aplay) but when I try to play flash videos in firefox, flash crashes with something like:
Quote
npviewer.bin[26668]: segfault at 0 ip f49fac14 sp ffab39d0 error 4 in libasound.so.2.0.0[f49ad000+c1000]


Forgetting my flash woes for a moment. If I set amarok alsa output to front (rather than hw:0) it also works with no distortion. Is this also bypassing dmix or something?
Title: ALSA sample rate conversion
Post by: cabbagerat on 2008-05-27 14:49:48
While ALSA device is your mplayer using?

It seems that by default the front device has "softvol" enabled but not dmix. Only the "default" device seems to have dmix enabled out of the box. If you use this device for everything, everything should get resampled and mixed with the default rate converter. If you set that to samplerate_whatever it should use that.

You might need to ask these questions on one of the ALSA mailing lists to get a sensible answer.
Title: ALSA sample rate conversion
Post by: samtek on 2008-05-27 14:51:53
Thanks. I have no idea what device mplayer is using...it's just using -ao alsa. I shall post on the alsa list.
Title: ALSA sample rate conversion
Post by: gkmeyer on 2008-06-08 16:30:11
I had this whole thing figured out a while back when I was trying to get my old Chaintech AV-710 working with no resampling in software.  I don't have time this minute, but I'll go back into my notes and settings to see if I can help. 

I'm on Arch too btw.
Title: ALSA sample rate conversion
Post by: Samizdat on 2008-09-04 16:25:51
I'm running Ubuntu Hardy 8.04 on a 32-bit Athlon and an A7N8XE mobo.  My sound software is ALSA and the sound card ID follows:
00:05.0 Multimedia audio controller: nVidia Corporation nForce Audio Processing Unit (rev a2)
00:06.0 Multimedia audio controller: nVidia Corporation nForce2 AC97 Audio Controler (MCP) (rev a1)
   Subsystem: ASUSTeK Computer Inc. nForce2 AC97 Audio Controler (MCP)

Can anyone help me with the following Internet Archive show: Brahms - Tragic Overture in D Minor, Op. 81 (http://www.archive.org/details/l.f.2006-05-23.flac16)

The original FLAC file has a sample rate of 48 KHz, which file I will temporarily keep in the show till I resolve the problem: the playback speed is too fast.

As you can see, the solution I have applied is to resample the performance at 44.1 KHz.

First of all, is my diagnosis of too-fast playback correct, or is there something wrong with my hardware and/or software?

Secondly, if resampling is not the solution, what is?