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

@HenrikEnquist, @phofman - thank you both! I've been stress-testing the player for the past couple hours with the updated limits and target_level set to 3 chunksizes. -> zero xruns, despite hammering camilladsp with half a dozen websocket requests threads + running another half dozen tasks cpu intensive tasks, + copying large files over the network (wireless) every now and then. Great!
 
On v3, I'm getting XRUN's on the Loopback Capture. This was discussed briefly in another thread.

@phofman and @HenrikEnquist I'm attaching tracelogs, config, and graph of testscripts/log_load_and_level.py.

With chunksize=2k, target_level=6k I observe capture overruns, followed by playback underruns.

I'm using next30 and have merged the skip_instead_of__block branch.

Increasing chunksize to 4k (and target_level to 12k) doesn't help - the same behaviour is observed.

In the trace log , have a look around lines 518 and 65399 where the "Capture: read overrun, trying to recover. Error: ALSA function 'snd_pcm_readi' failed with error 'Broken pipe (32)'" error is reported.

Any suggestions welcome, I'm starting to go a bit crazy.
 

Attachments

  • cdsp-config.txt
    cdsp-config.txt
    564 bytes · Views: 36
  • cdsp-monitor.png
    cdsp-monitor.png
    155.7 KB · Views: 38
  • cdsp-trace-log-short.txt
    cdsp-trace-log-short.txt
    6.7 MB · Views: 33
Last edited:
Getting some as well.
2024-11-06 10:57:57.808257 WARN [src/alsadevice.rs:122] PB: device is in an unexpected state: SND_PCM_STATE_PAUSED, Paused
2024-11-06 10:57:57.848840 WARN [src/alsadevice.rs:122] PB: device is in an unexpected state: SND_PCM_STATE_PAUSED, Paused
2024-11-06 10:57:57.934710 INFO [src/alsadevice.rs:556] PB: device stalled
2024-11-06 10:57:57.939042 INFO [src/alsadevice.rs:547] PB: device resumed normal operation
2024-11-06 11:02:29.025549 WARN [src/alsadevice.rs:202] PB: write underrun, trying to recover. Error: ALSA function 'snd_pcm_writei' failed with error 'Broken pipe (32)'
2024-11-06 11:06:54.096989 WARN [src/alsadevice.rs:113] PB: Prepare playback after buffer underrun
2024-11-06 11:11:22.923327 WARN [src/alsadevice.rs:113] PB: Prepare playback after buffer underrun
2024-11-06 11:42:27.682474 WARN [src/alsadevice.rs:122] PB: device is in an unexpected state: SND_PCM_STATE_PAUSED, Paused

devices:
adjust_period: 30
capture:
channels: 6
device: hw:Loopback,1,0
format: S32LE
labels:
- FL
- FR
- RL
- RR
- FC
- LFE
link_mute_control: null
link_volume_control: null
stop_on_inactive: null
type: Alsa
capture_samplerate: null
chunksize: 2048
enable_rate_adjust: null
multithreaded: null
playback:
channels: 6
device: pipewire
format: S32LE
type: Alsa
queuelimit: 16
rate_measure_interval: null
samplerate: 48000
silence_threshold: -80
silence_timeout: 5
stop_on_rate_change: null
target_level: 6143
volume_limit: null
volume_ramp_time: null
worker_threads: null

OS: Fedora Linux 40 (Workstation Edition) x86_64
Kernel: 6.8.7-300.fc40.x86_64
Resolution: 1920x1080, 1920x1080
DE: Cinnamon 6.2.9
WM: Mutter (Muffin)
WM Theme: Mint-Y-Dark-Blue (Adwaita)
Theme: Mint-Y-Dark-Blue [GTK2/3]
Icons: Mint-Y-Blue [GTK2/3]
Terminal: gnome-terminal
CPU: AMD A10-7850K Radeon R7 4C+8G (4) @ 3.700GHz
GPU: AMD ATI Radeon R7 Graphics
Memory: 3089MiB / 31022MiB
 
Last edited:
@siraaris : IMO the actual period size of half the buffer and twice the chunksize may not work reliably. Things like this do happen when many channels are used, the drivers often have limits which start showing up at these situations. That's why I always keep asking what the actual hw params are being used, not just what are those requested by CDSP.

Code:
2024-11-07 02:20:29.676070 DEBUG [src/alsadevice_buffermanager.rs:57] Setting buffer size to 8192 frames
2024-11-07 02:20:29.676081 DEBUG [src/alsadevice_buffermanager.rs:70] Device is using a buffer size of 8192 frames
2024-11-07 02:20:29.676082 DEBUG [src/alsadevice_buffermanager.rs:78] Setting period size to 1024 frames
2024-11-07 02:20:29.676083 DEBUG [src/alsadevice_buffermanager.rs:94] Device is using a period size of 4096 frames
2024-11-07 02:20:29.676606 DEBUG [src/alsadevice.rs:427] Opening Playback device "RME-HDSPe-MADI" with parameters: HwParams { channels: Ok(32), rate: "Ok(96000) Hz", format: Ok(S32LE), access: Ok(RWInterleaved), period_size: "Ok(4096) frames", buffer_size: "Ok(8192) frames" }, SwParams(avail_min: Ok(4096) frames, start_threshold: Ok(1) frames, stop_threshold: Ok(8192) frames)

First I would suggest to play with aplay and diagnose RME driver hw_params limist (using the --dump-hw-params parameter). If the RM driver does not accept smaller period than 4096 frames at 32 channels, you will have to increase chunksize to at least one (preferrably two) minimum period sizes.

The trace log is important, but unfortunately since it's not complete (snipped in the middle), it does not show why at the beginning the capture loop spent about 20ms waiting for data (which is exactly what 2048 frames at 96kHz last) but in the second part after snip the capture loop spends only microsecs (i.e. the capture buffer is getting fuller and fuller, eventually ending with overrun). Grep the log for "Capture waited for Some" to see what I mean.
 
It's what I've noted when attempting to set the period size manually. I'm just running an instance of CDSP where there is a periodic capture issue. Capture issues occur roughly every 1m40s.

I have not been able to idenfity a process or job as cause. Any ideas?
 

Attachments

  • Screenshot 2024-11-07 at 4.41.51 am.png
    Screenshot 2024-11-07 at 4.41.51 am.png
    221.5 KB · Views: 35
Buffer can be set to twice the period only? What method does the setup use (some auxiliary software for RME?)
With aplay, I can use periods as per below (but the buffer is always 2x period).

--------------------
ACCESS: MMAP_NONINTERLEAVED RW_NONINTERLEAVED
FORMAT: S32_LE
SUBFORMAT: STD
SAMPLE_BITS: 32
FRAME_BITS: [512 2048]
CHANNELS: [16 64]
RATE: [32000 192000]
PERIOD_TIME: (333 256000]
PERIOD_SIZE: [64 8192]
PERIOD_BYTES: [4096 2097152]
PERIODS: 2
BUFFER_TIME: (666 512000]
BUFFER_SIZE: [128 16384]
BUFFER_BYTES: [8192 4194304]
TICK_TIME: ALL
--------------------
 
Last edited:
@QuickDraw McGraw : Rate adjust not enabled in your config - seach for "Loopback" in https://github.com/HEnquist/camilladsp/ to read about the rate adjust.
Hi,

On purpose. Whenever I enable it, I get a confusing message in CDSP log telling me not to do so. Alsa is already handling it. Tested and confirmed multiple times already. No idea what it means.

2024-11-06 14:18:02.937488 INFO [src/alsadevice.rs:547] PB: device resumed normal operation
2024-11-06 14:18:31.960141 INFO [src/alsadevice.rs:789] Capture device supports rate adjust
2024-11-06 14:18:32.007284 INFO [src/alsadevice.rs:117] PB: Starting playback from Prepared state
 
On purpose. Whenever I enable it, I get a confusing message in CDSP log telling me not to do so. Alsa is already handling it. Tested and confirmed multiple times already.
Please can you show the message? IMO the logs says to not use async resampling when rate adjust with loopback or gadget is used. But in that config the rate adjust is disabled completely. How does alsa handle syncing one soundcard clock to another sound device clock (to which the pipewire server/alsa device is slaved)?
 
That is the message "2024-11-06 14:18:31.960141 INFO [src/alsadevice.rs:789] Capture device supports rate adjust'
Yes, it means that the device supports adjusting its rate and CDSP would be able to adjust its rate. For CDSP to do so its rate-adjust functionality must be enabled explicitely (disabled by default because it's quite a complicated method).
 
  • Like
Reactions: QuickDraw McGraw
Problem as in "never going to get it to work", or "maybe could get it to work"?
Good question. IMHO the code for rate adjust as is will not work optimally with just two periods per buffer as typically the reported alsa delay (i.e. buffer fill) is updated at period boundary by the driver and there would be two incoming chunks per one period. Henrik is considering adding an inner thread to the alsa thread (used e.g. already in CDSP wasapi adapter which uses only two periods per buffer as well). IIUC such a change would uncouple the chunk size from the buffer/period sizes (apart of other positive effects).
 
Actually it's the opposite. This message is shown when rate adjust has been enabled. Not while it's disabled.
There are two questions - whether the DEVICE supports rate adjust, and whether CDSP's config enables control of that device rate adjustment. That msg is result of CDSP checking required alsa controls of the device - see the code at https://github.com/HEnquist/camilla...e16fce19db1d815a6/src/alsadevice.rs#L736-L754 plus https://github.com/HEnquist/camilla...e16fce19db1d815a6/src/alsadevice.rs#L788-L795 . In that code there are no checks whether the rate adjust functionality is actually enabled by CDSP, which on the other hand is e.g. in https://github.com/HEnquist/camilla...96738e16fce19db1d815a6/src/alsadevice.rs#L450 plus https://github.com/HEnquist/camilla...e16fce19db1d815a6/src/alsadevice.rs#L613-L630 . It means that message is output if the device supports rate adjustment, regardless whether usage/control of that feature is enabled in CDSP.
 
Last edited: