Re: [Loopdub-devel] Sample Rate Configuration

[Stephen S. <rad...@gm...>]

> The attached patch adds two new configuration parameters to
> .loopdub.conf: HardwareSampleRate and InternalSampleRate.
> HardwareSampleRate is the sample rate used for the audio output; it
> corresponds to Player::m_nHwSampleRate. InternalSampleRate is the
> sample rate used for internal processing; it corresponds to the new
> static variable Player::m_nSampleRate, which replaces the old
> SAMPLE_RATE constant defined in player.h.

Very nice, thanks.
I've been wanting to do something like that.  I'd been thinking of
using the command line but the configuration file is a much better
solution.  Maybe the command line could be used to override the
configuration file.  I'll look into command line stuff sometime, but
for now the configuration file is a real bonus.

I committed your patch, plus a small one on top that initializes the
m_cfg* variables properly.
(If I didn't add the variables to the configuration file, the values
were initialized to zero, which didn't work too well.  :)


> It is arguable that InternalSampleRate and HardwareSampleRate should
> be merged; that is, that they should always be the same. The advantage
> would be increased simplicity (both in the code and from the user's
> perspective); the disadvantage would be decreased flexibility. What do
> you think?

Actually I just recently added the HardwareSampleRate thing and the
dependency on libsamplerate.  (after the 0.3 release)

This was because in fact on my laptop, ALSA refuses to allow the
soundcard to be initialized at 44100 Hz.  I guess this is because it
doesn't support upsampling in the driver, and the hardware clock
probably runs at 48000 Hz.  However, I had a huge database of loops
that were all encoded at 44100, so they were playing too fast.  I had
to introduce the upsampling in order to get my loops to play at the
right speed.

Ideally the InternalSampleRate wouldn't be specified by the user, but
loopdub would just use the sample rate information in the wav file
header.
This would mean a different call to the resampling algorithm for each
loop, however, increasing CPU usage.  Not sure it's a good trade-off
if all my loops are encoded at the same samplerate.  Perhaps something
more 'intelligent' (i.e., nasty and complicated) could be used to do
the resampling before or after mixing depending on whether all the
loop samplerates are the same.

By the way, here's an open problem:  it's somewhat difficult to ensure
that there is no clicking due to the differences between buffer sizes
before and after resampling.  For this reason I chose a very specific
buffer size that was an integer multiple of the ratio between
44100/48000.  It's a bit specific, and I'd like to make it more
general in the future.. the user should be able to specify the buffer
size.  However, due to resampling, if this ratio doesn't work out to
an integer you get a lot of clicking.

anyways, thanks for the patch.
Steve