Thank you!
I'm a little confused by the configuration instructions provided for CamillaDSP on Github. It states:
I played music all day yesterday. I just checked my journal log file and camilladsp.log, and CamillaDSP didn't throw any errors. To be safe I will set it back to default, which is the chunksize value.
I'm a little confused by the configuration instructions provided for CamillaDSP on Github. It states:
- target_level (optional, defaults to the chunksize value)
The value is the number of samples that should be left in the buffer of the playback device when the next chunk arrives. Only applies when enable_rate_adjust is set to true. It will take some experimentation to find the right number. If it's too small there will be buffer underruns from time to time, and making it too large might lead to a longer input-output delay than what is acceptable. Suitable values are in the range 1/2 to 1 times the chunksize. (Emphasis added).
I played music all day yesterday. I just checked my journal log file and camilladsp.log, and CamillaDSP didn't throw any errors. To be safe I will set it back to default, which is the chunksize value.
Last edited:
Yes, that formulation is a bit confusing. IMO it should append "recommended for minimum latency". If you do not care about latency, then IMO the maximum timing safety is preferrable, i.e. keeping the buffer as full as reasonably possible. That gives you maximum time to underflow in case of sudden CPU surge which would delay processing chunks. What is your playback buffer size (CDSP logs or /proc/asound/PLAYBACK_CARD/pcm0p/sub0/hw_params)?
On your playback device? What is the device? And what is the buffer size on your gadget capture device?
The playback device is a miniDSP MCH Streamer Kit. I am using the SPDIF output. I am looking at /proc/asound/SPDIF/pcm0p/sub0/hw_params.
My USB gadget capture device (UAC2Gadget) also has buffer_size: 4096.
My USB gadget capture device (UAC2Gadget) also has buffer_size: 4096.
Last edited:
Under Devices --> Buffers I have my chunksize set to 4096 since Tidal streams as high as 192k.
But, if I remember correctly, camilladsp-setrate will automatically set the chunksize to an appropriate size when the capture samplerate changes. So, perhaps I could recuce the chunksize to 1024.
EDIT: camilladsp-setrate is changing the buffer_size. A song just came on that was streaming at 192k, and the buffer_size for my UAC2Gadget increased to 8192.
EDIT2: I changed Device --> Buffers --> chunksize to 1024. I then changed songs streaming at different rates. When I went back to a song streaming at 44.1k both the SPDIF (playback device) and UAC2Gadget (capture device) had buffer_size: 4096.
But, if I remember correctly, camilladsp-setrate will automatically set the chunksize to an appropriate size when the capture samplerate changes. So, perhaps I could recuce the chunksize to 1024.
EDIT: camilladsp-setrate is changing the buffer_size. A song just came on that was streaming at 192k, and the buffer_size for my UAC2Gadget increased to 8192.
EDIT2: I changed Device --> Buffers --> chunksize to 1024. I then changed songs streaming at different rates. When I went back to a song streaming at 44.1k both the SPDIF (playback device) and UAC2Gadget (capture device) had buffer_size: 4096.
Last edited:
Does CDSP log chunksize also 4096? That would mean your buffer is only one chunk large which is not optimal. Although the code may work because it's nicely coded to write the chunk into the playback device buffer in several writes if full write does not work out https://github.com/HEnquist/camilla...8c24c17182b63d051/src/alsadevice.rs#L179-L195 . Still I would suggest to make sure the playback buffer is at least 2 chunks.
Capture buffer may be different, especially should CDSP resample between different capture and playback rates.
Capture buffer may be different, especially should CDSP resample between different capture and playback rates.
I am looking at my camilladsp.log right now. It does not seem to indicate the chunksize.
EDIT: My journal log file showed buffer overrun events when I changed the chunksize to 1024. So, I will leave Device --> Buffers --> chunksize at 4096.
I will monitor for any other errors and increase Device --> Rate adjust --> target_level to be 8192 if I have any errors.
EDIT: My journal log file showed buffer overrun events when I changed the chunksize to 1024. So, I will leave Device --> Buffers --> chunksize at 4096.
I will monitor for any other errors and increase Device --> Rate adjust --> target_level to be 8192 if I have any errors.
Last edited:
Did you try 2048 (i.e. two chunks per buffer)?
The chunksize is logged e.g. https://github.com/HEnquist/camilla...6de888c24c17182b63d051/src/alsadevice.rs#L462 - debug log requires parameter -v (verbose) of CDSP.
The chunksize is logged e.g. https://github.com/HEnquist/camilla...6de888c24c17182b63d051/src/alsadevice.rs#L462 - debug log requires parameter -v (verbose) of CDSP.
My log indicates "Playback loop uses a buffer of 4096 frames".
I will try 2048 for the chunksize.
I will try 2048 for the chunksize.
I now have the following settings:
Buffers:
chunksize: 4096
queuelimit: default
Rate adjust:
enable_rate_adjust: yes
adjust_period: 3
target_level: 8192
Now I am getting buffer overrun events showing in my journal log file when a 192k song comes on. I tried 2048 for the chunksize, but no change.
This is strange because yesterday I was not getting any buffer overruns. I listened to the same playlist.
EDIT: This is a non-issue. It only occurs when the song changes to a 192k song, but not while the song is actually playing.
Buffers:
chunksize: 4096
queuelimit: default
Rate adjust:
enable_rate_adjust: yes
adjust_period: 3
target_level: 8192
Now I am getting buffer overrun events showing in my journal log file when a 192k song comes on. I tried 2048 for the chunksize, but no change.
This is strange because yesterday I was not getting any buffer overruns. I listened to the same playlist.
EDIT: This is a non-issue. It only occurs when the song changes to a 192k song, but not while the song is actually playing.
Last edited:
The target_level at 8192 gave me an issue when the streaming samplerate changed from a song at 192k to a song at 44.1k - CamillaDSP stopped and the state showed inactive. I set the target_level back to default, and it is again working when the samplerate changes.
I am not sure you already have a version which supports target level larger than buffer size https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-7928985 .
IMO it's important to understand what the target level actually does. The feedback capture rate adjuster tries to keep the average playback buffer fill at configured target level, via changing the capture rate (= input data flow speed), through direct rate change or through fine-tunable asynchronous resampler. That means the requested target level should be within buffer size. If you set it over the real buffer size, the rate adjuster can never reach its target, and will keep speeding up capture data flow.
There is a CDSP version coming which will include into the momentary delay calculation chunks waiting for being written to the playback buffer, along with the actual buffer fill. That will allow target levels larger than playback buffer which can increase timing safety with hardware-limited playback buffers.
In your case I would try to configure two chunks per buffer, target level at 75% of the buffer, using the logs for confirmation that your requested chunksize actually results in the desired buffer size.
IMO it's important to understand what the target level actually does. The feedback capture rate adjuster tries to keep the average playback buffer fill at configured target level, via changing the capture rate (= input data flow speed), through direct rate change or through fine-tunable asynchronous resampler. That means the requested target level should be within buffer size. If you set it over the real buffer size, the rate adjuster can never reach its target, and will keep speeding up capture data flow.
There is a CDSP version coming which will include into the momentary delay calculation chunks waiting for being written to the playback buffer, along with the actual buffer fill. That will allow target levels larger than playback buffer which can increase timing safety with hardware-limited playback buffers.
In your case I would try to configure two chunks per buffer, target level at 75% of the buffer, using the logs for confirmation that your requested chunksize actually results in the desired buffer size.
I have CamillaDSP version 3.0.0 installed.
In my testing so far, seting the target_level to 75% of the chunksize, which is 3072 in my case, or leaving it at default, which is 100% of the chunksize, both seem to work without significant issues. The only issue that I have seen is a buffer overrun when playback changes from a 44.1k song to a 192k song, but it only occurs the moment the song changes and then clears; it does not occur while the 192k song actually plays or when there is a change to another song with a lower samplerate.
I listened to music continuously for many hours last night after setting the target_level to default and I didn't hear any audible issues. It all seems to be working fantastic.
Yes, when sample rate changes, camilladsp-setrate sets the chunk size according to what is recommended in the help pages of camilladsp.
Please let me know if there is a more clever way of managing that parameter. I could schedule an update of camilladsp-setrate.
@mevang I am afraid the real optimal values depend also on the devices and the recommended values may not work properly https://github.com/marcoevang/camil...5e78dec6d61ebb0521d0/setrate_util.c#L122-L127 E.g. the default gadget in mainline kernel has limited buffer size in bytes. Running it at multiple channels at 192kHz yields buffer sizes smaller than the recommended chunk size, and chunk size needs to be modified accordingly. IMO at best CDSP would modify the chunksize internally (similarly to how alsa methods snd_hw_params_set_XXX_near work) because it has all the information available. But since such feature would be of very low priority for Henrik, maybe your code could have these values configurable.
Thank you! I'm not confident there needs to be a change on your part regarding the chunk size. It seems to be working well, at least for me.
The issues I ran into happened while experimenting with different settings trying to find the optimal configuration. I think I have found that. I listened for a long time last night and have been listening to music all morning. I have not heard a single glitch, and my logs look clean (other than the momentary buffer overrun I noted on a change from 44.1k to 192k, which is inconsequential in my opinion since it clears before the song starts playing).
There is only one minor issue of any consequence that I notice. I have to make sure that the first song I play is streamed at the samplerate set in Devices --> samplerate. For example, if the samplerate is set at 44100 and I start with a 96k song, it does not play until I change the song or the samlperate setting. After that, it works perfect.
It is not that big of a deal, though. If I start a new streaming session and I run into that issue, I just change the samplerate or the song. After the first song camilladsp-setrate takes over and controls everything nicely.
Thank you HenrikEnquist, mevang, phoman for all of your work and support for these projects!!! I greatly appreciate everything you do!!!
This could de done by loading a configuration file defining the desired chunk size for each supported sample rate. As soon as I have some spare time, I might release a version of camilladsp-setrate incorporating this feature. But I would really like to know if there are any camilladsp-setrate users interested in this feature.
In my setup, immediately after alsa initialisation, camilladsp-setrate always captures a rate change event indicating the greatest sample rate supported by the playback device. When the first track starts playing, a rate change is captured indicating the correct sample rate to be set in camilladsp. No issues in my setup.
As I understand it, in your setup it seems that the rate change event is only captured from the second track onwards. The log obtained with the ‘--loglevel notice’ option might provide useful information in this regard. If you have the time and willingness, please post the traces of the log file.
I would install it. Perhaps it may prevent future issues. But, I have been playing music all day, with songs/albums ranging from 44.1k - 192k, and have not had any issues.
Yes. However, the issue may be intermittent. This morning it occured when I first started playing music. This afternoon I saw an update to CamillaGUI was released. I installed it and rebooted my Pi. The first album I played was streamed at 192k, but it started playing immediately.
I just changed my loglevel from "err" to "notice". If the issue happens again I will post it.