somebodyelse
Master Contributor
- Joined
- Dec 5, 2018
- Messages
- 6,257
- Likes
- 6,088
The notable gaps being the lack of a Studio ADC8x, or digital I/O equivalents. Maybe one day if we're lucky...
-
Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!
RPi + CamillaDSP Tutorial
- Thread starter mdsimon2
- Start date
Wirrunna
Active Member
My Hifiberry ADC8x arrived today, installed and recognized by CamillaDSP after updating the kernel.
Configured a mixer with two balanced inputs and 4 unbalanced. Only tested unbalanced input with REW so far, will try a balanced input in the next day or two after I make up an input lead, although a 1/4" headphone adapter to 3mm stereo should work as a 1/4" TSR plug.
Configured a mixer with two balanced inputs and 4 unbalanced. Only tested unbalanced input with REW so far, will try a balanced input in the next day or two after I make up an input lead, although a 1/4" headphone adapter to 3mm stereo should work as a 1/4" TSR plug.
Wirrunna
Active Member
I have a Raspberry Pi 5 running raspberry pi os, DAC8x. Trying and failing to get desktop audio, eg from browser, to play through an ALSA loopback to Camilla.
I Stupidly and embarrassingly posted a question I intended to put here on the diyAudio forum (both sites open in tabs). Rather than have the same question open in both forums I wondered if anyone willing to could have a look. I imagine quite a lot of people engage on both but very Sorry! I posted over two posts.
www.diyaudio.com
I Stupidly and embarrassingly posted a question I intended to put here on the diyAudio forum (both sites open in tabs). Rather than have the same question open in both forums I wondered if anyone willing to could have a look. I imagine quite a lot of people engage on both but very Sorry! I posted over two posts.
CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc
Thanks! I think this should go inte the GitHub manual page. //
My first post on the forum, really appreciate Michael's thread - it really helped to get me going. All works (almost) perfectly, but now I struggle to resolve the issue with noise/pops when music is paused. My set-up is Wiim Pro -> toslink (set to fixed 96kHz sample rate) -> Hifime S2 Digi -> USB to RPI5 -> USB to SMSL PO100 (probably not really required in the setup, just got fixated on using async USB, which old Marantz does not have) -> Coaxial to Marantz NA7004. I use CamillaDSP for room correction DSP - not there yet, but really lots of fun and learning. And here is an issue - when I pause playback there are crackling noises audible. Initially I thought it was Wiim's output issue, but Wiim directly to Marantz does not experience this issue. And TV set via toslink to Hifime S2 - issue is even worse. When there is something played all is fine. To make things more awkward - the severity of the issue depends on optical cable used (that made me think initially that something was wrong with Wiim's output) - ranging from almost no issue at all (and setting CamillaDSP pause to 5 seconds makes it bearable, as most of the times there are no cracks within 5 seconds) to cracks almost all the time. Any tips on where to start looking would be appreciated.
CDSP does not recognize playback as stopped - it says it is "Running", and there are those little clicks visible on input (and output) in WebUI. If I am lucky (and with some cables, with others clicks they are constant), CamillaDSP will go to PAUSED after 5 seconds, if the click does not occur within 5 seconds (then sometimes it goes back to Running, and to Paused, etc). When Wiim goes into standby due to lack of activity, CDSP goes to Stalled, but it nicely recovers once music is restarted and goes to running. And as long as music plays it is fine, no issues between songs, just when playback is paused. However I see lots of such entries in log file:
2025-04-23 15:48:27.507883 WARN [src/alsadevice.rs:113] PB: Prepare playback after buffer underrun
and I think (I will triple check later today) that those occurr when the playback was paused. But what this would have to do with cable used?
- Thread Starter
- #2,409
Can you share your configuration file?
This is probably a dumb question, but can you really fix the Wiim Pro sample rate at 96 kHz? I don't have a Wiim Pro anymore, but I thought you could only set a maximum rate, and it would switch to lower rates below that. So, you could fix the rate at 44.1 kHz because there was not a rate lower, but not at anything higher.
Michael
This is probably a dumb question, but can you really fix the Wiim Pro sample rate at 96 kHz? I don't have a Wiim Pro anymore, but I thought you could only set a maximum rate, and it would switch to lower rates below that. So, you could fix the rate at 44.1 kHz because there was not a rate lower, but not at anything higher.
Michael
I do not remember since which firmware upgrade on Wiim Pro, but right now there is a Fixed Resolution toggle. If switched on, you set a fixed rate (which in my case is 96kHz/24 bit) on either coaxial or toslink, if off, you set the maximum rate (so in that case it would behave as you described). I am sure it works, as playback works totally fine regardless of different sampling rates on Tidal - Wiim does the resampling, and CamillaDSP reports 96000 rate, no issues there. Config file is attached - it is super basic. Perhaps I should add something to stop at inactive setting?
- Thread Starter
- #2,411
I am not sure this will solve your issue, but you need to have async resampling and rate adjust enabled as the Wiim Pro / S2 Digi clock is not synced with the SMSL PO100 clock.
I'd start with 512 chunk size and 1536 target level and see how that goes. If you still get buffer underruns, I'd watch the buffer level and see how it corresponds to when you are seeing issues. You may need to increase chunk size / target level and/or lower adjust_period.
Michael
I'd start with 512 chunk size and 1536 target level and see how that goes. If you still get buffer underruns, I'd watch the buffer level and see how it corresponds to when you are seeing issues. You may need to increase chunk size / target level and/or lower adjust_period.
Michael
In addition to Michael's major fix - do you have this commit in your CDSP build https://github.com/HEnquist/camilladsp/commit/9a7afb4c887eb1dffe66f32082cb0ee35091c040 ?
Also - using SPDIF for this type of communication is not the best way, USB via USB gadget would be better. The reason is when incoming SPDIF stream stops, the capture alsa device read by CDSP will just cease providing samples. CDSP will have to time out and handle the issue. While USB gadget would report the rate change immediately (because the host player sends a specific info about stopping the stream to the device) and CDSP (via its controller) could react accordingly right away. Yes, CDSP can pause after repeated device read timeout (after some further non-trivial timeout defined by the silence_timeout param), but it may affect overall latency and some devices do not work nicely with upon unpausing. It's always better to avoid automatic pausing/unpausing, if possible.
Henrik did a great job with documenting the config options https://github.com/HEnquist/camilladsp?tab=readme-ov-file#configuration , it's IMO a must read for more complex chains like yours. CDSP can do many things and default config values cannot encompass any arbitrary chain.
Also - using SPDIF for this type of communication is not the best way, USB via USB gadget would be better. The reason is when incoming SPDIF stream stops, the capture alsa device read by CDSP will just cease providing samples. CDSP will have to time out and handle the issue. While USB gadget would report the rate change immediately (because the host player sends a specific info about stopping the stream to the device) and CDSP (via its controller) could react accordingly right away. Yes, CDSP can pause after repeated device read timeout (after some further non-trivial timeout defined by the silence_timeout param), but it may affect overall latency and some devices do not work nicely with upon unpausing. It's always better to avoid automatic pausing/unpausing, if possible.
Henrik did a great job with documenting the config options https://github.com/HEnquist/camilladsp?tab=readme-ov-file#configuration , it's IMO a must read for more complex chains like yours. CDSP can do many things and default config values cannot encompass any arbitrary chain.
Now I am etting this warning when the issues appear.
2025-04-23 17:47:20.789252 WARN [src/socketserver.rs:540] Lost connection: WebSocket protocol error: Connection reset without closing handshake
2 things I totally do not understand:
* issue gets significantly (like order of magnitude) worse with some optical cables
* now when I paused the playback there was short click, then silence, CamillaDSP paused, roughly after a minute noise started and it is really bad now. As you see buffer level is super low:
And parameters are:
State:
RUNNING
Capt. samplerate:
96000
Rate adjust:
1.0003
Clipped samples:
5
Buffer level:
6
DSP load:
5.5%
Message:
OK
2025-04-23 17:47:20.789252 WARN [src/socketserver.rs:540] Lost connection: WebSocket protocol error: Connection reset without closing handshake
2 things I totally do not understand:
* issue gets significantly (like order of magnitude) worse with some optical cables
* now when I paused the playback there was short click, then silence, CamillaDSP paused, roughly after a minute noise started and it is really bad now. As you see buffer level is super low:
And parameters are:
State:
RUNNING
Capt. samplerate:
96000
Rate adjust:
1.0003
Clipped samples:
5
Buffer level:
6
DSP load:
5.5%
Message:
OK
Last edited:
Unfortunately Wiim Pro does not have USB out, and except for this it does all I want - auto switches to optical in when TV starts playing, has trigger out which I paired with Arduino and IR diode, so it starts all the other devices when playback starts.
Will double check if I have March update you mentioned included. And to clarify - the issue is not with unpausing - then it all works fine - the cracks are when there is nothing to be played.
Thank you for all the hints, will keep on looking!
Until CDSP flips to status PAUSED (which is after 5 secs as configured in your silence_timeout), it may produce issues since the capture read constantly times out (buffer underrun). I would try lowering the silence_threshold param down to almost zero (it's in db and you capture in 16bits - no format specified - so I would try sth like -90) and lowering the silence_timeout to 1 sec or even less. For explanation see the configuration doc.
Ignore the warning - it was something else. Issues are exactly the same with rate adjust and resampling - and actually no warnings in the log. Look at sshot below - this in and out levels below are actually the noise - which is completely gone after I restart playback (and which is much smaller and intermittent with a different cable, which I totally struggle to understand...). The issue occurs as well when I bypass SMSL interface and go directly from RPI USB to Marantz NA 7004. Also when I use Wiim volume control without stopping playback, and put it to 0/100 issues occur, when it is at 1/100 - some intermittent, unfrequent clicks, 2/100 - no audible issues at all (which seems to confirm all is fine during playback, but it is super annoying).
And I do have latest CDSP version. Started thinking about different interface from Wiim to RPI (but I am not sure if there are many options, there are some hats, but I saw some info about issues with them as well). If anyone has suggestions on the interface (although @mdsimon2 - I understand from your guide that you actually used this hifime interface, and no similiar issues on your side)
Attachments
Last edited:
- Thread Starter
- #2,418
Something seems very wrong if your buffer level is so low.
I believe leaving target level as default will set it as equivalent to chunk size. As I mentioned before, try setting chunk size to 1536. You should see rate adjust managing the buffer level to roughly stay at 1536.
The only time I've seen a buffer run down like that when using appropriate settings for rate adjust is when you have a sample rate mismatch. The S2 is not like some other devices in that if you send it say 44.1 kHz but are running CamillaDSP at a higher rate, it will kind of work, but the playback will be choppy, and the buffer level will fluctuate a lot.
To eliminate sample rate mismatch as a variable I'd try setting max output on the Wiim to 44.1 kHz and run CamillaDSP at 44.1 kHz and see how that goes.
EDIT: Would you mind sharing your convolution filters? I am interested if they are doing anything weird. Might be a good idea to bypass them and see if you still have issues.
Michael
I believe leaving target level as default will set it as equivalent to chunk size. As I mentioned before, try setting chunk size to 1536. You should see rate adjust managing the buffer level to roughly stay at 1536.
The only time I've seen a buffer run down like that when using appropriate settings for rate adjust is when you have a sample rate mismatch. The S2 is not like some other devices in that if you send it say 44.1 kHz but are running CamillaDSP at a higher rate, it will kind of work, but the playback will be choppy, and the buffer level will fluctuate a lot.
To eliminate sample rate mismatch as a variable I'd try setting max output on the Wiim to 44.1 kHz and run CamillaDSP at 44.1 kHz and see how that goes.
EDIT: Would you mind sharing your convolution filters? I am interested if they are doing anything weird. Might be a good idea to bypass them and see if you still have issues.
Michael
Last edited:
Unfortunately no changes:
* set the rates to 44.1 kH everywhere (Wiim out, Camilla capture and samplerate)
* target level at 1536
* bypassed the filters
* playback at normal volume: buffer around 1500 no issues
* lower volume in Wiim app to 0/100, not pausing playback - lots of constant and quite loud noise , buffer goes down, but stays around 1400. No warnings in the log. After 1-2 minutes of this noise, capture device is stalled (so silence at last...) and CamillaDSP restarts just fine if I turn the volume up
* turn volume up to 1 - random noises, turn volume up in Wiim app to 2/100 - all good - silence... Like if S2 could not handle 0s stream
* and I know I am repeating myself, but this is the greatest mystery to me. 2 out of 3 toslink cables I have - behavior like above. 3rd cable - it is much better, there are random cracks at 0 volume, but with the other 2 it is non-stop crackling noise. Otherwise there is no difference in those 3 cables when playing music (not to my ears at least, and I would not expect much difference between toslink cables). So why they behave so differently in relation to silence and S2....
Maybe I just purchase one of the Rpi digihats with coaxial input (b
Thank you - the noise in most of the cases is well above -50 unfortunately. And just to clarify, I think that CDSP defaults to highest supported format according to https://github.com/HEnquist/camilladsp/blob/master/backend_alsa.md. I changed them to S32LE, but it does not really make any difference.
Similar threads
