@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.
@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
Last edited:
Getting some as well.
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
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.
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.
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.
@QuickDraw McGraw : Rate adjust not enabled in your config - seach for "Loopback" in https://github.com/HEnquist/camilladsp/ to read about the rate adjust.
Buffer can be set to twice the period only? What method does the setup use (some auxiliary software for RME?)
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?
I have not been able to idenfity a process or job as cause. Any ideas?
Attachments
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:
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.
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)?
@phofman
That is the message "2024-11-06 14:18:31.960141 INFO [src/alsadevice.rs:789] Capture device supports rate adjust'
Likely I confused with another setting. I don't understand half of them and I've been playing with the config for 2 months.
But thanks, your explanation makes sense. Updated config accordingly.
That is the message "2024-11-06 14:18:31.960141 INFO [src/alsadevice.rs:789] Capture device supports rate adjust'
Likely I confused with another setting. I don't understand half of them and I've been playing with the config for 2 months.
But thanks, your explanation makes sense. Updated config accordingly.
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).
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).
@HenrikEnquist : Please would you consider extending the msg "Capture device supports rate adjust" with a conditioned "but rate adjust is not enabled"? Thanks!
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: