@QuickDraw McGraw Please can you run the delay extraction command on logs from CDSP 3.0b4 which uses snd_pcm_delay instead of snd_pcm_avail in 3.0? Thanks.
grep -o -e "Averager: added value [0-9]*" camilladsp.log | awk '{print $NF}' | sort | uniq -c@phofman haven't found any 3b4. I thought you meant 3b2
Code:
/usr/local/bin/camilladsp3.3b2 -l trace -o /home/shizuma/camilladsp.log /home/shizuma/.config/.camilladsp/v3/90deg-D1.yml
grep -o -e "Averager: added value [0-9]*" camilladsp.log | awk '{print $NF}' | sort -h | uniq -c > averager.txtI have installed camilladsp v3.0.0 and camillagui v3.0.0 on my raspberry pi 4 running raspberry pi os bullseye.
Camillagui seems to work in my browser. However, when I launch camilladsp, camillagui reports that camilladsp state is offline.
Capture device is stdin and playback device is my USB DAC.
Camilladsp logfile does not report errors (see below the last few lines produced in debug mode).
Please also find below the very simple(empty) configuration.
Any help would be appreciated.
2025-01-18 22:00:27.810039 DEBUG [src/alsadevice.rs:427] Opening Playback device "hw:AUDIO" with parameters: HwParams { channels: Ok(2), rate: "Ok(192000) Hz", format: Ok(S32LE), access: Ok(RWInterleaved), period_size: "Ok(2048) frames", buffer_size: "Ok(16384) frames" }, SwParams(avail_min: Ok(4096) frames, start_threshold: Ok(1) frames, stop_threshold: Ok(16384) frames)
2025-01-18 22:00:27.810109 DEBUG [src/alsadevice.rs:432] Playback device "hw:AUDIO" successfully opened
2025-01-18 22:00:27.810147 DEBUG [src/bin.rs:272] Playback thread ready to start
2025-01-18 22:00:27.810158 DEBUG [src/bin.rs:275] Both capture and playback ready, release barrier
2025-01-18 22:00:27.810173 DEBUG [src/bin.rs:277] Supervisor loop starts now!
2025-01-18 22:00:27.810181 DEBUG [src/alsadevice.rs:1141] Starting playback loop
2025-01-18 22:00:27.810191 DEBUG [src/alsadevice.rs:459] Playback device supports pausing the stream
2025-01-18 22:00:27.810195 DEBUG [src/alsadevice.rs:462] Playback loop uses a buffer of 4096 frames
2025-01-18 22:00:27.810221 DEBUG [src/processing.rs:103] Processing loop starts now!
2025-01-18 22:00:27.810185 DEBUG [src/filedevice.rs:666] starting captureloop
2025-01-18 22:00:27.810356 DEBUG [src/filedevice.rs:265] preparing captureloop
2025-01-18 22:00:27.810405 DEBUG [src/alsadevice.rs:495] Playback thread has real-time priority.
2025-01-18 22:00:27.852553 DEBUG [src/filedevice.rs:411] Entering stalled state
description: This configuration has no filters, no mixers, no processors and no pipelines
(i.e. it does nothing).
devices:
adjust_period: null
capture:
channels: 2
format: S32LE
type: Stdin
capture_samplerate: null
chunksize: 4096
enable_rate_adjust: null
playback:
channels: 2
device: "hw:AUDIO"
format: S32LE
type: Alsa
queuelimit: 1
rate_measure_interval: null
samplerate: 192000
silence_threshold: -60
silence_timeout: 3
stop_on_rate_change: null
target_level: null
volume_ramp_time: null
filters: null
mixers: null
pipeline: null
processors: null
title: Empty
Camillagui seems to work in my browser. However, when I launch camilladsp, camillagui reports that camilladsp state is offline.
Capture device is stdin and playback device is my USB DAC.
Camilladsp logfile does not report errors (see below the last few lines produced in debug mode).
Please also find below the very simple(empty) configuration.
Any help would be appreciated.
2025-01-18 22:00:27.810039 DEBUG [src/alsadevice.rs:427] Opening Playback device "hw:AUDIO" with parameters: HwParams { channels: Ok(2), rate: "Ok(192000) Hz", format: Ok(S32LE), access: Ok(RWInterleaved), period_size: "Ok(2048) frames", buffer_size: "Ok(16384) frames" }, SwParams(avail_min: Ok(4096) frames, start_threshold: Ok(1) frames, stop_threshold: Ok(16384) frames)
2025-01-18 22:00:27.810109 DEBUG [src/alsadevice.rs:432] Playback device "hw:AUDIO" successfully opened
2025-01-18 22:00:27.810147 DEBUG [src/bin.rs:272] Playback thread ready to start
2025-01-18 22:00:27.810158 DEBUG [src/bin.rs:275] Both capture and playback ready, release barrier
2025-01-18 22:00:27.810173 DEBUG [src/bin.rs:277] Supervisor loop starts now!
2025-01-18 22:00:27.810181 DEBUG [src/alsadevice.rs:1141] Starting playback loop
2025-01-18 22:00:27.810191 DEBUG [src/alsadevice.rs:459] Playback device supports pausing the stream
2025-01-18 22:00:27.810195 DEBUG [src/alsadevice.rs:462] Playback loop uses a buffer of 4096 frames
2025-01-18 22:00:27.810221 DEBUG [src/processing.rs:103] Processing loop starts now!
2025-01-18 22:00:27.810185 DEBUG [src/filedevice.rs:666] starting captureloop
2025-01-18 22:00:27.810356 DEBUG [src/filedevice.rs:265] preparing captureloop
2025-01-18 22:00:27.810405 DEBUG [src/alsadevice.rs:495] Playback thread has real-time priority.
2025-01-18 22:00:27.852553 DEBUG [src/filedevice.rs:411] Entering stalled state
description: This configuration has no filters, no mixers, no processors and no pipelines
(i.e. it does nothing).
devices:
adjust_period: null
capture:
channels: 2
format: S32LE
type: Stdin
capture_samplerate: null
chunksize: 4096
enable_rate_adjust: null
playback:
channels: 2
device: "hw:AUDIO"
format: S32LE
type: Alsa
queuelimit: 1
rate_measure_interval: null
samplerate: 192000
silence_threshold: -60
silence_timeout: 3
stop_on_rate_change: null
target_level: null
volume_ramp_time: null
filters: null
mixers: null
pipeline: null
processors: null
title: Empty
It Is a fresh install.
CamilldaDSP, just for testing purposes, starts by means of the following command:
camilladsp and camillagui start as normal user (not super user)
Thank you
CamilldaDSP, just for testing purposes, starts by means of the following command:
camilladsp -l debug -o ~/camilladsp/camilladsp.log ~/camilladsp/configs/Empty.ymlcamilladsp and camillagui start as normal user (not super user)
Thank you
Ok, you are just missing the -p option for telling which port to use for the websocket server.
Maybe check config/camillagui.yml in your camillagui directory. AFAIK the default port for the web socket is 1234 and if the camilla_port: line points to that you don’t need to specify a port when running camilladsp.
No, you always need to specify a port, otherwise the websocket server gets disabled.
Thanks! The measured delays are dynamic (lots of varied values), unlike those for the version with avail in 3.0 (very coarse input data for the feedback regulator). BUT it does not seem that we could say that pcm.avail() gives only coarse values while pcm.delay gives detailed values. IIUC this closely depends on the device/driver/alsa plugin used. Exact behavior of these methods depends on the implementation of these methods in the downstream code, they seem to behave inconsistently (e.g. https://lore.kernel.org/alsa-devel/d3607e2e-51ba-3c62-4232-c035eda98dbb@ivitera.com/T/#u ).
Nevertheless I think we should investigate what options are available (in this particular case of the pipewire plugin) because the granularity of the values reported by the pipewire plugin's pcm.avail() = snd_pcm_avail for the feedback controller may cause capture/playback synchronization issues at tighter latencies (or high CPU loads).
IIUC the previous version actually did not call snd_pcm_delay (pcm.delay in rust), but snd_pcm_status_alloca -> snd_pcm_status_get_state -> snd_pcm_status_get_delay (pcmdevice.status().ok().map(|status| status.get_delay()) in rust). The new version calls snd_pcm_avail, no allocation and filling of the status struct involved.
Actually IIUC the discussion of alsa developers I linked above avail is the correct measure for this use case of working with the buffer. Delay (which should include the device latency too) is intended for syncing purposes (like AV lipsync). IIUC it may even happen that snd_pcm_delay returns value larger than buffer size if the driver reports a large device latency (unless capped somewhere in alsa code).
I simply overlooked that little detail...🙂 Now camillagui sees camilladsp. Thank you.
Ah yes you are correct, thanks! I remembered wrong.
This was also my conclusion after reading up on this.
I have tried improving the buffer level measurement to include any chunks waiting in the channel. This seems to work well, and helps when using large values for target_level. It can even be larger than the buffer size, and the feedback still works as it should.
That does seem like a very good solution. IIUC the sequence of the initial non-blocking writes up to buffer size should yield identical target_level for the averager (the data are either in the queued chunk, or in the device buffer, just each write moves the data from one part of the sum to the other part). Also it could allow larger latencies than output buffer size. Some devices have the output buffer size limited - e.g. the unmodified usb gadget has 16 pages i.e. 64kB https://github.com/torvalds/linux/b...c04/drivers/usb/gadget/function/u_audio.c#L26. That makes at 192kHz/32bit/10ch only 8ms - very short for a full buffer. I increase it in my test kernels, but the stock value is this low. Making a chain fit this strict timing is quite difficult, especially with low-power SoCs like RK3308. Now this method can allow target_level larger than the buffer size (after modifying the limit check https://github.com/HEnquist/camilla...e436de888c24c17182b63d051/src/config.rs#L1828 ), allowing several chunks in the processing -> playback queue as a safety margin for CPU load peaks.
Still I wonder what was causing the glitches with the status delay calls - IMO a small allocation should not cause that and IIUC a kernel call is involved for both versions (snd_pcm_status for pcm.status() vs. snd_pcm_avail for pcm.avail() ).
Yes, I changed the limit for Alsa to (4 + queuelimit) * chunksize. Next step is to update the other backends the same way.
@HenrikEnquist , I would like to report that the ‘unzipped’ executable file of camilladsp (raspberry pi version) had unknown owner and group.
I would suggest to compress the file with the
I would also recommend users to uncompress the file with the
That said, camilladsp and camillagui version 3.0.0 are working great. I only miss the information about the version of camilladsp and pycamilladsp in camillagui, which was present in previous versions.
Thanks a lot for your great job and continuing support.
I would suggest to compress the file with the
--numeric-owner option of the tar command so that no owner and group information is included in the file.I would also recommend users to uncompress the file with the
--no-same-owner option of the tar command, so that no owner and group information possibly stored in the archive file is given.That said, camilladsp and camillagui version 3.0.0 are working great. I only miss the information about the version of camilladsp and pycamilladsp in camillagui, which was present in previous versions.
Thanks a lot for your great job and continuing support.
Very good suggestion, thanks!
They should still be there, but I moved them to a tooltip since they take some space and shouldn't change very often. Just hover over the version number in the lower left.
Hey there, I wanted to thank you Henrik for the great piece of software you've developed here. It fuels our family with music and mates perfectly with music streaming services (through Lyrion music server and squeezelite) but also from the turntable.
Just one remark though, when I discovered v3 may solve the ALSA device interactions to remove a small glitch that happened every 20 seconds or so, I upgraded. In a disordered fashion. The camilladsp binary, then later the GUI when I found the configuration file format had changed, then struggled till I realized the pycamilladsp lib had too to be upgraded. And finally came back to an operational state.
There would be several options to enforce consistency between the various packages:
But again, thank you for the hard work !
Just one remark though, when I discovered v3 may solve the ALSA device interactions to remove a small glitch that happened every 20 seconds or so, I upgraded. In a disordered fashion. The camilladsp binary, then later the GUI when I found the configuration file format had changed, then struggled till I realized the pycamilladsp lib had too to be upgraded. And finally came back to an operational state.
There would be several options to enforce consistency between the various packages:
- have a meta-package to deploy them all ;
- have distro packages ;
- keep them separate but integrate version check to better guide users.
But again, thank you for the hard work !
Yes there are, bug most of them are quite specific to one operating system or even a specific distribution of that system. I tried to do something that can work on all systems with the least amount of differences, that's the only way it gets feasible at all.
First, the major version numbers need to match. V3.x of CamillaDSP needs v3.x of Python libraries and gui. The gui backend ships with Python requirements for pip, conda and poetry. And finally there are complete setup scripts that take care of everything. Those are still not updated for the V3 release yet though.
Packages for different Linux distributions, installers for Mac and windows etc would be super nice, but take too much time to create and maintain. With a large team, sure no problem. But I'm just me 😀
This isn't really an issue, more of an observation with v3.
I had commented in the past about the different behavior of interfaces when they come out of pause -> https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-7469575.
Previously the Okto dac8 PRO gave a completely clean log, even switching between paused and running states. This was nice because if there was an issue like a buffer underrun it was obvious in the log. Now both the Okto and the MOTU Ultralite Mk5 show the following when coming out of pause.
I assume there has been some change in the pause behavior or the log reporting. Is it possible to get to a "clean log" which avoids these sort of messages?
Michael
I had commented in the past about the different behavior of interfaces when they come out of pause -> https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-7469575.
Previously the Okto dac8 PRO gave a completely clean log, even switching between paused and running states. This was nice because if there was an issue like a buffer underrun it was obvious in the log. Now both the Okto and the MOTU Ultralite Mk5 show the following when coming out of pause.
Code:
2025-01-26 00:08:18.924985 INFO [src/bin.rs:781] CamillaDSP version 3.0.0
2025-01-26 00:08:18.925016 INFO [src/bin.rs:782] Running on linux, aarch64
2025-01-26 00:08:18.933958 INFO [src/alsadevice.rs:117] PB: Starting playback from Prepared state
2025-01-26 00:08:29.672393 WARN [src/alsadevice.rs:122] PB: device is in an unexpected state: SND_PCM_STATE_PAUSED, Paused
2025-01-26 00:08:29.673645 WARN [src/alsadevice.rs:122] PB: device is in an unexpected state: SND_PCM_STATE_PAUSED, Paused
2025-01-26 00:08:29.675118 WARN [src/alsadevice.rs:122] PB: device is in an unexpected state: SND_PCM_STATE_PAUSED, Paused
2025-01-26 00:08:29.676364 WARN [src/alsadevice.rs:122] PB: device is in an unexpected state: SND_PCM_STATE_PAUSED, Paused
2025-01-26 00:08:29.678407 INFO [src/alsadevice.rs:556] PB: device stalled
2025-01-26 00:08:29.684613 INFO [src/alsadevice.rs:547] PB: device resumed normal operation
2025-01-26 00:08:41.792005 WARN [src/alsadevice.rs:122] PB: device is in an unexpected state: SND_PCM_STATE_PAUSED, Paused
2025-01-26 00:08:41.793477 WARN [src/alsadevice.rs:122] PB: device is in an unexpected state: SND_PCM_STATE_PAUSED, Paused
2025-01-26 00:08:41.794725 WARN [src/alsadevice.rs:122] PB: device is in an unexpected state: SND_PCM_STATE_PAUSED, Paused
2025-01-26 00:08:41.796006 WARN [src/alsadevice.rs:122] PB: device is in an unexpected state: SND_PCM_STATE_PAUSED, Paused
2025-01-26 00:08:41.798048 INFO [src/alsadevice.rs:556] PB: device stalled
2025-01-26 00:08:41.804873 INFO [src/alsadevice.rs:547] PB: device resumed normal operation
2025-01-26 00:09:04.981113 WARN [src/alsadevice.rs:122] PB: device is in an unexpected state: SND_PCM_STATE_PAUSED, Paused
2025-01-26 00:09:04.982339 WARN [src/alsadevice.rs:122] PB: device is in an unexpected state: SND_PCM_STATE_PAUSED, Paused
2025-01-26 00:09:04.983559 WARN [src/alsadevice.rs:122] PB: device is in an unexpected state: SND_PCM_STATE_PAUSED, Paused
2025-01-26 00:09:04.985061 WARN [src/alsadevice.rs:122] PB: device is in an unexpected state: SND_PCM_STATE_PAUSED, Paused
2025-01-26 00:09:04.987107 INFO [src/alsadevice.rs:556] PB: device stalled
2025-01-26 00:09:04.996968 INFO [src/alsadevice.rs:547] PB: device resumed normal operation
2025-01-26 00:09:25.906756 WARN [src/alsadevice.rs:122] PB: device is in an unexpected state: SND_PCM_STATE_PAUSED, Paused
2025-01-26 00:09:25.907988 WARN [src/alsadevice.rs:122] PB: device is in an unexpected state: SND_PCM_STATE_PAUSED, Paused
2025-01-26 00:09:25.909238 WARN [src/alsadevice.rs:122] PB: device is in an unexpected state: SND_PCM_STATE_PAUSED, Paused
2025-01-26 00:09:25.910744 WARN [src/alsadevice.rs:122] PB: device is in an unexpected state: SND_PCM_STATE_PAUSED, Paused
2025-01-26 00:09:25.912789 INFO [src/alsadevice.rs:556] PB: device stalled
2025-01-26 00:09:25.920619 INFO [src/alsadevice.rs:547] PB: device resumed normal operationI assume there has been some change in the pause behavior or the log reporting. Is it possible to get to a "clean log" which avoids these sort of messages?
Michael