I’m essentially writing a custom combiner for two or more oscillators.
My setup looks like:
channel1 -> oscillator -> dsp1
channel2 -> oscillator -> dsp2
channel3 -> combiner dsp
Each channel seems to be 44.1khz, and the dsp too (using channel::getFrequency and dsp::getDefaults).
I have a custom callback on dsp1 and 2 which fill a buffer, the combiner dsp basically reads the buffers and does some funky stuff with the numbers and outputs it to it’s own outbuffer.
The problem is the dsp1 and dsp2’s read callback are called approximately 10% more frequently than the combiner dsp’s callback.
This leads me to believe that they’re running at 48khz, and the combiner is running at 44.1, but I’ve checked all the channels and all the dsps, and they all say 44.1khz.
I don’t think it’s a simple threading problem either because the combiner never catches up. It just continues to lag more and more behind the oscillator’s dsp.
Any idea what could be causing this?
- oZZ asked 10 years ago
The channel and dsp frequencies returned by channel::getFrequency and dsp::getDefaults say 44.1khz though. If they’re actually 48khz, shouldn’t they say 48khz? at least the dsp::getDefaults call. That’s what I was refering to when I said I think it’s a bug.
The dsp engine runs at the output rate set in setSoftwareFormat. This is 48khz by default.
Any units that are on the right hand side of a resampler (a unit which does nothing but resample from the source rate to the dsp system’s rate of 48khz for example) is processing at the specified rate.
If you used System::playDSP it would have one of these, if you manually connected it it wouldn’t.
There is no bug regarding this behaviour or a whole load of other stuff would be breaking.
Please login first to submit.