[Clam-devel] SampleRate problem in chordata (and NetworkEditor) related with the PA backend (problem and proposed solutions)
Hernán Ordiales
h at ordia.com.ar
Fri Feb 27 09:45:12 PST 2009
On Fri, Feb 27, 2009 at 11:11 AM, David García Garzón
<dgarcia at iua.upf.edu> wrote:
> A Divendres 27 Febrer 2009 06:05:51, Hernán Ordiales va escriure:
>> I think this is a very well known bug, i'm talking about the PortAudio
>> audio backend sampleRate value hardcoded to 48000Hz[1]. 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)[2]. The problem
>> here is that increases the cpu load and seems more vulnerable to
>> underflows.
>>
>> Other solutions:
>> * 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?
>
> I would be very glad if you can manage this long term pending issue. The ideal
> setup for me I would be wave file handlers do the transcoding to a given
> sample rate nominal to the network (as the network could have samplerate
> dependencies) and then the backends transparently recode network samplerate to
> the one of the device (or trying to configure backend to the network
> samplerate). Devil is on the details so maybe we should write down some use
> cases to think on each solution whether it fits, or at least writing down
> current ones in order not to generalize too much.
but this could not be implemented with a couple of resample
processings? i mean, one at _beginning_ of the network (transcoding
the file to the network SR) and the other one at the _end_ setting up
the correct SR to the backend...
> But whatever the solution we choose what we need is something to resample and
> current resample plugin does NOT work. So if you based your new processing in
> the old one, i guess they wont work either.
well, i just did a simple test consisting in a filereader playing a
file at SR=44.1kHz connected to a samplerate processing with 44.1k to
48k ratio and an audiosink with a backend setup at SR=48kHz (default
PA or jack at 48k) and worked ok (well sometimes has some underflows,
but does not sound bad pitched). Network is attached
i just changed the way of configuring the SR ratio and changed the
interpolator method to get less underflows
> The main problem is that I was using the 'feed-the-whole-audio' simple
> interface. This is not ok for most ratios where the processing just fails to
> output anything.
so, it's not working in all cases, but works for example for my
proposed network?
> Libsamplerate offers an streaming interface where you feed an input and an
> output buffer but as far as i read it doesn't give you any guaranties that it
> will fill the output buffer for a given input size. I guess we should look to
> the source code to know which are the needed framesizes in order for us to set
> up the latency. I got blocked there and stopped the spike so if you want to go
> deeper on the research, it is perfect.
ok, i will check it
>> 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[3], but, the best _framework_ [4] (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);
>> bool help;
>> opts.addSwitch("help", &help);
>> QString backend;
>> opts.addOption('b', "backend", &backend);
>> QString file;
>> opts.addOptionalArgument("file", &file);
>>
>> 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
>> more sense!)
>>
>> Ok, we still can implement it in a simpler way[5], 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?
>
> Code for that is in the Prototyper which allows to provide a sorted list of
> preferences. I planned to unify NetEditor with that code in Prototyper. Anyway
> if you change the NetworkEditor options think on Prototyper too.
Oh, then i think i can take the code from prototyper and put it into NE... :-)
> About introducing more libraries, please be carefull so that the libraries are
> available at least as package in debian/ubuntu and can be (cross)compilable
> for windows and mac. Introducing a non-portable dependency in such a central
> part of the framework could mean losing support for a platform.
don't worry, i have this issue present
anyway the framework i mentioned is qt based so i supposed it's also
crossplatform, but should be tested before, of course
> Also about the options we are considering to introduce boost.program_option[1]
> which is available in most platforms and we already have used it in the
> raytracer.
>
> [1] http://www.boost.org/doc/libs/1_38_0/doc/html/program_options.html
thanks, i'll check it
> If the library you suggest were integrated into Qt, it would be perfect as we
> wouldnt need to include a new library but i guess is a third party based on
> Qt, not just Qt. Also if it is about two files and the license is compatible
> we could include it.
yes, it's only two files and the license (i think) is modified BSD.
Check the patch in the attachments (the patch includes the library and
differs wrt. the one of the link because it's ported to qt4)
> Hey, i meet people from froglogic at the QtDevDays.
:-D
>> 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
>>
>>
>> Cheers
>>
>> [1] CLAM/src/Flow/Networks/BackEnds/PANetworkPlayer.cxx
>> PANetworkPlayer::PANetworkPlayer()
>>
>> : mPreferredBufferSize(paFramesPerBufferUnspecified)
>>
>> , mSamplingRate(48000)
>> , mPortAudioStream(0)
>> , mError(paNoError)
>>
>> why?
>
> 1. No resampling algorithms integrated so we need to supose on SR for all
> 2. Most modern soundcards are 48k
> 3. We have some requirements of 48k for barcelonamedia
> 4. We moved most algorithms/backends to default 48k
>
>
>> [3] 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
>>
>>
>> [4] I tested:
>> * getopt (ported to qt4 by me)
>> http://www.froglogic.com/pg?id=PublicationsFreeware&category=getopt
>> * http://code.google.com/p/simpleopt/
>> * cmdLine, argtable, etc
>>
>> [5] please understand i'm lazy, you'll agree with me that is more
>> funny to code audio dsp related things
>
> --
> David García Garzón
> (Work) dgarcia at iua dot upf anotherdot es
> http://www.iua.upf.edu/~dgarcia
>
>
thanks for the feedback
--
Hernán
http://h.ordia.com.ar
GnuPG: 0xEE8A3FE9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 44100-to-48000.clamnetwork
Type: application/octet-stream
Size: 959 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20090227/ba8fb8f5/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: getopt.patch
Type: text/x-diff
Size: 26292 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20090227/ba8fb8f5/attachment-0003.patch>
More information about the clam-devel
mailing list