Posts: 58
Threads: 7
Joined: May 2023
Reputation:
2
Next question: Is there a way to optimize the performance? Currently I use an RPi3, and I want to use CamillaDSP to correct the sound linearity.
To test whether this works in principle I currently run CamillaDSP with the „flat“ configuration, simply to see whether the processing is in time. While with normal datarates this seems to be no problem, I just now listened to music with 24/96, and I got some audible „clicks“ which went away when I turned CamillaDSP off.
It would be nice if I could continue to use the RPi3…
Posts: 1,281
Threads: 24
Joined: Jun 2022
Reputation:
42
(06-14-2023, 07:59 PM)jbaumann Wrote: Next question: Is there a way to optimize the performance? Currently I use an RPi3, and I want to use CamillaDSP to correct the sound linearity.
To test whether this works in principle I currently run CamillaDSP with the „flat“ configuration, simply to see whether the processing is in time. While with normal datarates this seems to be no problem, I just now listened to music with 24/96, and I got some audible „clicks“ which went away when I turned CamillaDSP off.
It would be nice if I could continue to use the RPi3…
It looks like Camilla is needing more computational power than the Pi3 is capable of... anyway, some logs could help determine if the problem is in the software domain at least. Looking for xruns or device-not-ready..
Maybe playing around with MPD buffers and cache could help...?
Posts: 13,429
Threads: 304
Joined: Mar 2018
Reputation:
545
(06-14-2023, 07:59 PM)jbaumann Wrote: Next question: Is there a way to optimize the performance? Currently I use an RPi3, and I want to use CamillaDSP to correct the sound linearity.
To test whether this works in principle I currently run CamillaDSP with the „flat“ configuration, simply to see whether the processing is in time. While with normal datarates this seems to be no problem, I just now listened to music with 24/96, and I got some audible „clicks“ which went away when I turned CamillaDSP off.
It would be nice if I could continue to use the RPi3…
You prolly need to bump the chunk size parameter.
- Stay with Flat config
- Open CamillaDSP Config
- Scroll down to Pipeline editor section
- Set Status to ON
- OPEN Pipeline editor
- Enter 4096 for chunksize
- Click either "Apply to DSP" or "Apply and save"
Re-test
Posts: 58
Threads: 7
Joined: May 2023
Reputation:
2
Chunk size seems to be the solution.
I first tried it with 4096, which didn‘t help, 16384 worked much better. I have to re-listen tomorrow to be sure (there might have been one small click still).
What is the disadvantage of a bigger chunksize?
Posts: 13,429
Threads: 304
Joined: Mar 2018
Reputation:
545
Thats a huge bump!
Your best bet for more detailed questions on Camilla settings would be the diyAudio thread.
Mention that you have a 3B, 24/96 file and had to bump the chunk size way up. Someone may have some insights or other settings you can try.
Posts: 58
Threads: 7
Joined: May 2023
Reputation:
2
Hi Tim,
thanks for the pointer. I assume you mean this thread: https://www.diyaudio.com/community/threa...tc.349818/
Cheers, Joe
Posts: 58
Threads: 7
Joined: May 2023
Reputation:
2
I didn‘t have the time to look into the issue with CamillaDSP again until now. I started with 24/96 material again, with a chunk size of 1024, and lo and behold, absolutely no audible clicks or problems at all.
The main change I made is the introduction of the OverlayFS, meaning that all file operations are faster by an order of magnitude. And the sd card I‘m using is definitely not fast, so this might have been the underlying cause after all.
I‘ll continue with testing, but for the moment I‘m happy :-)
Cheers, Joe
Posts: 58
Threads: 7
Joined: May 2023
Reputation:
2
Ok, I was wrong it seems. It isn‘t necessarily the chunk size. Instead, if I reload the UI, half a second to two seconds later there is a short interruption of the music. Thus it seems that parts of the UI are executed with a priority that is high enough to cause problems in the audio pipeline. It gets a bit better with larger chunk sizes, but is still reproducible…
Cheers, Joe
Posts: 13,429
Threads: 304
Joined: Mar 2018
Reputation:
545
(07-10-2023, 02:45 PM)jbaumann Wrote: Ok, I was wrong it seems. It isn‘t necessarily the chunk size. Instead, if I reload the UI, half a second to two seconds later there is a short interruption of the music. Thus it seems that parts of the UI are executed with a priority that is high enough to cause problems in the audio pipeline. It gets a bit better with larger chunk sizes, but is still reproducible…
Cheers, Joe
Very odd. I've never experienced this.
Particularly during development, Browser reloads can be frequent and audio has always played perfectly regardless of what features are enabled for example CamillaDSP, Bluetooth, Airplay etc, or what the CPU load happens to be.
Maybe it's a side effect of the modifications you are testing out?
Posts: 58
Threads: 7
Joined: May 2023
Reputation:
2
07-13-2023, 05:41 PM
(This post was last modified: 07-14-2023, 07:04 AM by jbaumann.)
I have conducted a number of experiments, and the best result was with chunk size 2048 (as you suggested) and queue limit 6 (it was 1 before). Going too high with the queue limit (larger than 12) leads to audible distortions again, so there is a window that more or less works.
I have also copied the test track to the SD card to guarantee that the network cannot create additional problems. And I reduced the number of frontend instance to 1, simply to be sure that this isn‘t the source of the problem.
The result is that I get nearly no distortions on an RPi3 with the mentioned settings, but as soon as I put too much load on the frontend, I get them again.
I did all of these tests with my modifications (the OverlayFS), and without the modifications. No real difference there (I could have gotten the feeling that with the OverlayFS it works a bit better, but this might be a placebo effect, so I ignore it).
I ordered an RPi4 with 4GB which now arrived. I just switched to it (same SD card, same configuration, same everything), and it simply works. I can do what I want with the frontend, get the data over the network, nothing irritates it in the slightest.
[Update: I found one song that produced the same distortions as with very large queue limits on the RPi3. I changed the queue limit to 4, which is the default setting for CamillaDSP as I understand it, and it works fine]
So the final conclusion is that for 16/44.1 the RPi3 is a good device even with CamillaDSP. If you want to play 24/96 or higher, then this is possible with an RPi3 as long as you do not use further processing with CamillaDSP. If you want (or need) 24/96 and further processing (or higher data rates), then you need an RPi4.
[Maybe with placing the different parts of the audio processing queue on dedicated cores this could be optimized, but my suggestion at this point would be „buy an RPi4“]
Cheers, Joe
|
