Next11: Rate adjust give unstable buffer level

[HEnquist]

Ping @pavhofman The new rate adjust feature of next11 gives a buffer level and rate adjust that oscillate. When using the following config:

---
devices:
  samplerate: 192000
  chunksize: 4096
  target_level: 4096
  adjust_period: 3
  enable_resampling: true
  enable_rate_adjust: true
  resampler_type: Synchronous
  capture_samplerate: 44100
  playback:
    type: Alsa
    channels: 2
    device: "hw:Loopback,0,5"
    format: S32LE
  capture:
    type: Alsa
    channels: 2
    device: "hw:Loopback,0,1"
    format: S32LE

Gives this level and rate (first few minutes after start):

[HEnquist]

Comparing to master:

After thinking a little more.. The oscillations come from the unavoidable mismatch of chunksizes between the synchronous resampler and camilladsp itself.

The difference then is that the new one regulates much more carefully, which of course means it takes longer to reach the target. It's likely fine as it is.

[t123yh]

Maybe a hysteresis can be added to prevent oscillation?

[pavhofman]

@HEnquist I like the charts. Did you parse the log -> copy to some spreadsheet table? They go towards automated generating a chart similar to https://github.com/HEnquist/camilladsp/issues/203#issuecomment-1127293844 which would greatly help with troubleshooting timing issues and determining optimum settings.

As of the oscillations - I think the new method will eventually settle down more - the second peak is already smaller. But the main problem remains - convergence of the method requires that time AudioMessage::Audio spends in the processing thread does not fluctuate significantly. IMO that cannot be guaranteed in any way as it's outside of CDSP reach.

Maybe the AudioMessage::Audio could hold info about time it took from creation in the capture thread to receiving by the playback thread (i.e. all the processing + handling delays accumulated), and the pitch calculation could be somehow modified to account for this variable time. That way the variance could be filtered out and the calculated pitch would represent only the ratio of capture vs. playback rates.

[HEnquist]

I made them by simply copying numbers from the log to s spreadsheet. It wasn't quick but acceptable to test the idea. I'll try a different approach and just fake the whole thing in a python script. That should make it much easier to tune things, and to compare different algorithms.

There is actually already a timestamp in each AudioMessage. It's set when the AudioChunk is created in the capture thread, and then forwarded through the pipeline unchanged. It's just not used for anything yet. When I added it I was mainly thinking about measuring and logging latency (that I haven't gotten to yet) but it can very likely be used to improve pitch control too.

[pavhofman]

I think the data should be generated by the actual instance of CDSP running, on the specific system of someone who experiences problems.

IMO it could just generate data with timestamps, then a quick look at the debug logs could manually identify approximate time of the problem, and a script could generate some useful charts from the data collected around that time. So the input param of the script would be like the dump path, time from, time till.

[HEnquist]

I meant that I will start by making a python implementation of the rate adjust feedback function, and feed it some fake data to see how it reacts in different situations.

Later it would be a good idea to make a script for plotting data from a real log as well.

But I won't start on this now, need to finish some other stuff (the limiter and compressor etc) before I start on something new. The rate adjust can be improved, but I don't think there are any serious problems with how it works now.

[pavhofman]

I you want to, I can take a look at the live CDSP logging of the timing traces and the plotting. It would be a handy feature for any CDSP usecase, IMO. It would allow finetuning the params to squeeze down the overall latency to minimum, for any setup individually.

[t123yh]

I would like to add that it is worth trying to disable DVFS (dynamic voltage frequency switching) if you encounter unstable buffer levels. If you use BIG.little CPU (like RK3399), you can also try to pin the DSP and input task to one core. Because when frequency of CPU changes, the total latency of the processing pipeline changes, and thus buffer levels might be unstable.