CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc

Jump to Latest
#5,882
I see this continously and hear "blips" at corresponding occasions... what's my problem?

Code: 
2025-05-15 17:05:54.966144 WARN [src/coreaudiodevice.rs:901] Samples were dropped, missing 1 buffers
2025-05-15 17:06:34.788297 WARN [src/coreaudiodevice.rs:901] Samples were dropped, missing 1 buffers
2025-05-15 17:07:14.749644 WARN [src/coreaudiodevice.rs:901] Samples were dropped, missing 1 buffers
2025-05-15 17:07:54.595038 WARN [src/coreaudiodevice.rs:901] Samples were dropped, missing 1 buffers
2025-05-15 17:08:34.440423 WARN [src/coreaudiodevice.rs:901] Samples were dropped, missing 1 buffers
2025-05-15 17:09:14.378680 WARN [src/coreaudiodevice.rs:901] Samples were dropped, missing 1 buffers
2025-05-15 17:09:54.061469 WARN [src/coreaudiodevice.rs:901] Samples were dropped, missing 1 buffers

Capt. samplerate: 44100
Rate adjust:
Clipped samples: 0
Buffer level: 382
DSP load: 5.3%
Message: OK

Only PEQs.

Mac Mini->USBisolator->USB->XMOS->i2s->DAC

//
 
#5,884
->
Code: 
description: Filtering, delay and EQ for the 2-channel S1 (Big Flower)
devices:
  adjust_period: null
  capture:
    channels: 2
    device: BlackHole 2ch
    format: null
    labels:
    - Lin
    - Rin
    type: CoreAudio
  capture_samplerate: 44100
  chunksize: 1024
  enable_rate_adjust: null
  multithreaded: null
  playback:
    channels: 8
    device: DIYINHK USB Audio 2.0
    exclusive: null
    format: null
    type: CoreAudio
  queuelimit: null
  rate_measure_interval: null
  resampler: null
  samplerate: 44100
  silence_threshold: null
  silence_timeout: null
  stop_on_rate_change: null
  target_level: null
  volume_limit: null
  volume_ramp_time: null
  worker_threads: null

//
 
#5,890
What does rate adjust do and how does it work?

I can't see why it should be necessary when using an USB interface really. The USB protocol should see to that the XMOS board is sufficiently supplied with data - no?

I'll try "enable_rate_adjust".

//
 
#5,891
Got this... will follow up both in terminal and by ear 🙂

Code: 
2025-05-15 18:42:47.791166 INFO [/Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/audio_thread_priority-0.32.0/src/rt_mach.rs:79] thread 6939 priority restored.
2025-05-15 18:42:47.907198 INFO [/Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/audio_thread_priority-0.32.0/src/rt_mach.rs:79] thread 65787 priority restored.
2025-05-15 18:42:48.000045 INFO [/Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/audio_thread_priority-0.32.0/src/rt_mach.rs:79] thread 8983 priority restored.
2025-05-15 18:42:48.028644 INFO [/Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/audio_thread_priority-0.32.0/src/rt_mach.rs:158] thread 67611 bumped to real time priority.
2025-05-15 18:42:48.034804 INFO [src/coreaudiodevice.rs:1260] The capture device supports pitch control
2025-05-15 18:42:48.035389 INFO [/Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/audio_thread_priority-0.32.0/src/rt_mach.rs:158] thread 8987 bumped to real time priority.
2025-05-15 18:42:48.035388 INFO [/Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/audio_thread_priority-0.32.0/src/rt_mach.rs:158] thread 68379 bumped to real time priority.
2025-05-15 18:42:48.047641 WARN [src/coreaudiodevice.rs:460] Playback interrupted, no data available
2025-05-15 18:42:48.082433 INFO [src/coreaudiodevice.rs:451] Restarting playback after buffer underrun
 
#5,892
"The capture device supports pitch control"

Does this now mean that the DACs "pitch" is changed continuously to follow the source (CDSP, MAC Mini, or what?)?

Who adjusts the rate as in "enable_rate_adjust"...? Is it CDSP who adjusts to "please" / follow the XMOS board? Or what?

Is it the rate of how fast 44,1k data is to be delivered or is actually the sample rate changed?

//
 
Last edited:
#5,894
From GitHub:

"When rate adjust is enabled the resampling ratio is dynamically adjusted in order to compensate for drifts and mismatches between the input and output sample clocks."

I would like:
  • No continuous resampling of music data in the source i.e. everything before the i2s interface to the DAC.
  • Trust my USB_2_i2S board in that it can maintain accurate (44,1) and stable (low wander) clocks for driving the D/A process
  • Trust that USB will see to that the asynchronous interface makes sure that the USB_2_i2S board is given data as it needs and requests so that no slips or repeats happens of PCM data.

... so, the whole chain believes it does 44,1 and the only variation that actually happens is that of the layer 1 physical deviations is in electrical clocks - i.e. Fs is 44,1 but clocks in DACs go a little to fast so the pitch is a little higher than theory note A / 440 Hz 😉 but its OK...

Is this not how it works?

//
 
#5,895
This is the relevant bit from the readme:
enable_rate_adjust (optional, defaults to false)

This enables the playback device to control the rate of the capture device, in order to avoid buffer underruns or a slowly increasing latency. This is currently supported when using an Alsa, Wasapi or CoreAudio playback device (and any capture device). Setting the rate can be done in two ways.

Some capture devices provide a way to adjust the speed of their virtual sample clock (also called pitch adjust). This is available with the Alsa Loopback and USB Audio gadget devices on Linux, as well as BlackHole version 0.5.0 and later on macOS. When capturing from any of these devices, the adjustment can be done by tuning the virtual sample clock of the device. This avoids the need for asynchronous resampling.
If asynchronous resampling is enabled, the adjustment can be done by tuning the resampling ratio. Then resampler must be set to one of the "Async" types. This is supported for all capture devices.
Click to expand...
 
#5,896
What does it imply to "adjust the speed of their virtual sample clock (also called pitch adjust)" - a music file contains data that is said to have been sampled at 44100s/s... what is a "virtual sample clock"?

Does this just mean to change the rate of which the PCM words are forwarded, i.e. no re-sampling?

//
 
#5,897
The rate adjust has been discussed here many times.

Every audio device consumes (playback) or produces (capture) samples at its rate. The audio clients which communicate with the device driver are slaved to that rate, the device is what sets the clock. Typically hardware devices have clocks fixed which cannot be fine-tuned. A virtual audio device uses system timers for the clocking which by principle is fine tunable as needed. Therefore some virtual/software audio devices (alsa loopback, linux USB gadget, MacOS BlackHole) offer a way to fine-tune their clock which CDSP uses (if rate adjust is enabled). For devices which do not offer this feature (basically all hardware devices) CDSP uses adaptive resampling to align the independent capture and playback clocks (again IF rate adjust is enabled in the config).
 
  • Thank You
  • Like
Reactions: TNT and HenrikEnquist
You must log in or register to reply here.
Top Bottom