6
« on: July 06, 2009, 03:10:05 am »
OK, I have been looking into ALSA's resampling system configuration. When you connect your hybrid/MD to an AMP using a digital connection such as SPDIF or HDMI, these have fixed/static sample rates, usually 48kHz for SPDIF and 96kHz for HDMI. If your source is DD, DTS or BluRay's HD audio, then the sample rate of the source will match the link speed ... ie it is native, and can just pump down the link with no modification. Even mp3 files with sample rates matching the link speed should be fine.
However, if the sample rate does not match, as is the case for most CD rips (usually 44.1kHz), then a sample rate conversion (SRC) needs to be done to upconvert or downconvert the sample rate to match the link speed. Otherwise, for instance, a CD ripped mp3 file, which only has 44100 samples/sec will replay those samples at 48000 samples per second making it play back significantly faster, and pitch bend the sound upwards.
Resampling, like this, can cause alsorts of harmonic distortions depending on the rate, and inaccuracies due to the interpolation algorithm used. LMCE uses the default settings of ALSA, but it is far from clear which resampler algorithm or rate this is, either under the ALSA supplied with 0710 or 0810. Certainly in the past, it used the fastest and lowest quality resampler, but I cannot determine for sure which one it uses now. In any case, I thought I would experiment with the options as ALSA has a "samplerate_best" option, that whilst it uses much more CPU (its a software resampler), apparently it results in a far better result.
I am using the udial.wav test sample (which I recently read can damage your tweaters if played at anything other than low volume... wish I had known that before!) which creates some dialing type touch tones, but has high frequencies that when distorted by resampling become an obvious siren-like overlay. So far I haven't really heard much difference between the default option and the higher quality one (ie I can still hear the siren in both tests), but I thought I would document what I have done so far, just in case it gives anybody else some ideas.
Essentially, the system-wide config is in /etc/asound.conf. As I understand it, any application (such as Xine_wrapper or just Amarok on the KDE desktop) that uses ALSA will read this file at each start up. There is also a user specific file, but that doesn't seem to exist in 0710, so I concentrated on the system-wide one.
By default on 0710, this is the content:
pcm_slave.convert48k {
pcm "spdif"
rate 48000
}
pcm.spdif_playback {
type plug
slave convert48k
}
pcm.asym_spdif {
type asym
playback.pcm "spdif_playback"
capture.pcm "plughw:0"
}
pcm.asym_analog {
type asym
playback.pcm "plug:dmix"
capture.pcm "plughw:0"
}
pcm.!default asym_spdif
The "plug" PCM plugin apparently can handle sample rate conversion, so you do not need to use the "rate" plugin to do this, however the keyword for "plug" is "rate_converter" whereas it is "converter" for the "rate" plugin.
So you should just have to change the above to this:
pcm_slave.convert48k {
pcm "spdif"
rate 48000
}
pcm.spdif_playback {
type plug
slave convert48k
rate_converter "samplerate_best"
}
pcm.asym_spdif {
type asym
playback.pcm "spdif_playback"
capture.pcm "plughw:0"
}
pcm.asym_analog {
type asym
playback.pcm "plug:dmix"
capture.pcm "plughw:0"
}
pcm.!default asym_spdif
The outstanding things are to work out whether this config is actually changing what ALSA does, as I cannot find any log files that say anything one way or the other. ALSA is mentioned but even when I made an error in the conf file, there were no errors/warnings in the logs... Whether ALSA still uses the low-quality/fast resampler by default.... Whether reloading the router constitutes the restart the "application" needs to re-read the /etc/asound.conf file in (because Xine_wrapper restarts).... what the test sound actually should sound like! ... and whether any of this is really going to make a meaningful difference...
suggestions, advice, tips?
Show Posts
I thought that adding a delay of, say, 30 seconds that the device had to be in range for before triggering pnp might ease this problem