[Clam-devel] SampleRate problem in chordata (and NetworkEditor) related with the PA backend (problem and proposed solutions)
h at ordia.com.ar
Thu Feb 26 21:05:51 PST 2009
I think this is a very well known bug, i'm talking about the PortAudio
audio backend sampleRate value hardcoded to 48000Hz. I always been
using jack as backend for NetworkEditor, so i just realized about this
bug playing with chordata, which only has PortAudio as audio backend.
By doubts, the problem seems that playing a file at 44100Hz, if the
backend is set-up at 48000 there is not automatic sampleRate
conversion and you get a distorted pitch.
Having in mind most common audio files are recorded(saved) in 44100,
the audio/feedback result in chordata is specially awful. So i believe
this should be solved ASAP, at least for chordata, since is more
common end user oriented.
After found this problem, i tried many 'solutions':
* I recompiled the portaudio backend with 44100 as default sampleRate
and all ok.
* I replaced portaudio with jack as backend in chordata since with it
it's feasible to set-up the SR of the backend when you start the jackd
daemon (but this solution excludes platforms differents from linux)
* Resample before the output if the SR of the input file does not meet
with the current backend SR (in the case of portaudio). The problem
here is that increases the cpu load and seems more vulnerable to
* Set up the PortAudio backend depending on the file that's going to be played?
what do you think? which is the best way to overcome with this issue?
Related with this, recently i faced with another problem that i've
been _suffering_ lately, NetworkEditor is always loading jack as
backend, beyond jackd is running or not (for me it's a problem because
sometimes i'd like to run NE with PA as backend). Checking the code i
learned there is a backend autoselection process, first tries with
jack (if it's present), then with PA. I'd like to have the option of
let me force the backend. Related to this, I did an small proof of
concept using command line, but, the best _framework_  (i mean
by this an object oriented solution, free as speech, small, easy and
clear) i have found to parse command line options is qt based. Just as
an example, looks like:
GetOpt opts(argc, argv);
opts.addOption('b', "backend", &backend);
Very similar to scons options, don't? but I don't fully like the idea
about include an external framework (altough it's just a couple of
files) for command line parsing based in qt because it couldn't be
cleanly reused in command line apps (where a lot of arguments have
Ok, we still can implement it in a simpler way, although OTOH,
overload a graphic application with command line options, maybe isn't
the best way to go, but NE is missing of a configuration
section/window. What do you think about this?
Well, just let me know if you find some of these hacks useful and
would you like to see them commited (or check the patchs) or i just
keep them as my own workarounds to solve my own needs... :P
 I adapted the resample plugin to achieve this.
 NetworkEditor --help
Usage: NetworkEditor [file] Network filename.
[-b OR --backend] The backend can be JACK,
PortAudio or Auto.
[--help]: This help.
./NetworkEditor -b PortAudio
./NetworkEditor -b JACK
 I tested:
* getopt (ported to qt4 by me)
* cmdLine, argtable, etc
 please understand i'm lazy, you'll agree with me that is more
funny to code audio dsp related things
More information about the clam-devel