CamillaDSP with DAC8x on RPI5 / working, but with dropouts

[mario222]

Hi all,

I am trying to get CamillaDSP properly running, but having some issues, I would like to discuss and kindly ask for help. But first of all, thank you @HenrikEnquist for effort put into CamillaDSP development, it is great peace of software. And tutorial by @mdsimon2 is also great, simplifying setup process significantly.

My chain is iPhone - WiimPRO - hifime S2 digi (TOSLINK in, USB out) - Rpi5 (with CamillaDSP) - DAC8x. I carefully red https://github.com/mdsimon2/RPi-CamillaDSP?tab=readme-ov-file tutorial and made all described setup steps. I am running Raspberry Pi OS from original RPI 64 microSD card and original RPI power source. RPI is powering whole chain, including WiimPRO.

I managed to get everything running and with vanilla (unmodified) dac8x_sa9227.yml file(s) I can hear the sound coming out of DAC8x. I did not make any new filters yet, becouse even with this basic setup I hear dropouts every 7 to 10 seconds. I tried various capture sample rates, but the result is the same. WiimPRO is set to fixed output samplerate...
I tried also a different chain: iPhone - shairport-sync - Rpi5 (with CamillaDSP) - DAC8x, with clean install on different SD card, but the result was exactly the same.

The second issue is that the OLED display (3.2” diagonal SSD1322 OLED display) is not working at all...but did not have the time to investigate yet. Checked wiring twice thought .

Searching this and other forums did not revealed any helpful hint... is there anything I should try to locate the problem?

Thanks in advance.

 

[staticV3]

Hi @mario222! Welcome to ASR.

Here are some suggested CamillaDSP parameters, specifically for the DAC8x: https://www.audiosciencereview.com/...d-and-afterwards-degraded-sound-quality.65596

If those don't help, could you try enabling the debug log?
Does it show error messages coinciding with the signal drops?

 

[mario222]

Hi @mario222! Welcome to ASR.

Here are some suggested CamillaDSP parameters, specifically for the DAC8x: https://www.audiosciencereview.com/...d-and-afterwards-degraded-sound-quality.65596

If those don't help, could you try enabling the debug log?
Does it show error messages coinciding with the signal drops?

Thanks for the response. I set configuration as recommended in thread you posted in streamer configuration. The result is however unfortunately the same / dropouts each few secs. I also se a debug option for camilladsp... log is included in the post. I looked also at the OLED problem and I am getting error messages in rpi journal - pasted in enclosed file...

 

[mdsimon2]

The only thing that looks odd in your config is queuelimit of 64. Is there a reason you set it so high compared to default of 4?

For troubleshooting, I'd try a few things.

First eliminate CamillaDSP from the chain. You could output directly from shairpoint-sync to the dac8x, just use plughw:sndrpihifiberry as your output instead of the ALSA loopback. If you still have issues we know it isn't CamillaDSP related.

I also wonder if the OLED error is related to the problem. It seems like the issue is that GPIO pins are already allocated. I'd stop oled.service and see if that solves it. It would be good to run gpioinfo (may. need to install gpiod) and see how the pins are allocated.

If you still have issues I'd run CamillaDSP directly from the command line without any other services (oled.service, flirc.service, camillagui.service). This will give a cleaner log that will be easier to troubleshoot.

I don't have a RPi5 set up with a dac8x and an oled display currently, but I can try it this afternoon and report back as well.

Good luck!

Michael

 

[mario222]

The only thing that looks odd in your config is queuelimit of 64. Is there a reason you set it so high compared to default of 4?

For troubleshooting, I'd try a few things.

First eliminate CamillaDSP from the chain. You could output directly from shairpoint-sync to the dac8x, just use plughw:sndrpihifiberry as your output instead of the ALSA loopback. If you still have issues we know it isn't CamillaDSP related.

I also wonder if the OLED error is related to the problem. It seems like the issue is that GPIO pins are already allocated. I'd stop oled.service and see if that solves it. It would be good to run gpioinfo (may. need to install gpiod) and see how the pins are allocated.

If you still have issues I'd run CamillaDSP directly from the command line without any other services (oled.service, flirc.service, camillagui.service). This will give a cleaner log that will be easier to troubleshoot.

I don't have a RPi5 set up with a dac8x and an oled display currently, but I can try it this afternoon and report back as well.

Good luck!

Michael

Thank you very much. I tried also default 4, and some other options...but result was the same. I will try direct output to dac8x and OLED experiments next weekend - I have access to my workshop only during weekends. Input signal indicators of CamillaGUI were always green during dropouts, so I suppose there should not be a problem with input signal...though I am thinking about plugging some SPDIF or analog signal directly to Wiim PRO to rule out possible Wifi/router problems. Will see next weekend...

 

[phofman]

My chain is iPhone - WiimPRO - hifime S2 digi (TOSLINK in, USB out) - Rpi5 (with CamillaDSP) - DAC8x. I carefully red https://github.com/mdsimon2/RPi-CamillaDSP?tab=readme-ov-file tutorial and made all described setup steps. I am running Raspberry Pi OS from original RPI 64 microSD card and original RPI power source. RPI is powering whole chain, including WiimPRO.

Your CDSP config shows using loopback capture device - I guess it's the chain with shareport-sync, right?
As Michael says - you need to troubleshoot your chain step by step, starting from the playback. First I would play some file to your DAC8x with aplay or sox - to test your output I2S part. Then CDSP with aloop as input, but playing something locally. Then the remote part.

As of hifime S2 dig - if your Wiim allows USB output, you could connect RP5 in USB gadget mode directly to Wiim (after having sorted out the dropouts issue) and use it as USB device with integrated DSP.

 

[voodooless]

Did you add an ASRC in your config? If not, that is probably the issue.

 

[phofman]

Did you add an ASRC in your config? If not, that is probably the issue.

IIUC that posted config has loopback with rate_adjust enabled with async resampler 44.1 -> 96. Despite the async resampler being not necessary (because of the rate_adjust), it should not produce any glitches.

 

[mdsimon2]

I did some troubleshooting with this and I think the OLED issue is related to the dropout issue.

When the dac8x is connected to the RPi 5, GPIO 5 shows as being used by "hasadc". I see that @phofman provided some insight to this behavior here -> https://www.diyaudio.com/community/...-analog-to-hdmi-converter.425941/post-7975977 and it is related to detecting the adc8x.

I can re-assign "data bus 3" from GPIO 5 to 11. I will also re-assign "data bus 5" from GPIO 2 to 7 and "data bus 7" from GPIO 3 to 8 as Hifiberry implies that GPIO 2 and 3 are used for configuration in the link below.

GPIO usage of HiFiBerry boards | HiFiBerry

I've tested this on the RPi 5 with a dac8x as well as a RPi4 and it works fine.

Only downside is that existing users will need to re-wire if they do a new install, but I think it is better to make the tutorial universal so that it works for all applications.

Michael

 

[mario222]

Your CDSP config shows using loopback capture device - I guess it's the chain with shareport-sync, right?
As Michael says - you need to troubleshoot your chain step by step, starting from the playback. First I would play some file to your DAC8x with aplay or sox - to test your output I2S part. Then CDSP with aloop as input, but playing something locally. Then the remote part.

As of hifime S2 dig - if your Wiim allows USB output, you could connect RP5 in USB gadget mode directly to Wiim (after having sorted out the dropouts issue) and use it as USB device with integrated DSP.

Yes, it is the chain with shareport-sync - it is unmodified configuration from @mdsimon2 tutorial. Unfortunately Wiim PRO USBC is only for power supply. And you are right, I have to do isolated tests of subchain to pinpoint the problem.

 

[mario222]

IIUC that posted config has loopback with rate_adjust enabled with async resampler 44.1 -> 96. Despite the async resampler being not necessary (because of the rate_adjust), it should not produce any glitches.

It is true. Even in camilladsp log you can find: 2025-09-07 10:55:45.712101 WARN [src/alsadevice.rs:802] Async resampler is used but not needed since capture device supports rate adjust. Consider switching to Synchronous type to save CPU time.

 

[mario222]

I did some troubleshooting with this and I think the OLED issue is related to the dropout issue.

When the dac8x is connected to the RPi 5, GPIO 5 shows as being used by "hasadc". I see that @phofman provided some insight to this behavior here -> https://www.diyaudio.com/community/...-analog-to-hdmi-converter.425941/post-7975977 and it is related to detecting the adc8x.

I can re-assign "data bus 3" from GPIO 5 to 11. I will also re-assign "data bus 5" from GPIO 2 to 7 and "data bus 7" from GPIO 3 to 8 as Hifiberry implies that GPIO 2 and 3 are used for configuration in the link below.

GPIO usage of HiFiBerry boards | HiFiBerry

I've tested this on the RPi 5 with a dac8x as well as a RPi4 and it works fine.

Only downside is that existing users will need to re-wire if they do a new install, but I think it is better to make the tutorial universal so that it works for all applications.

Michael

I did some troubleshooting with this and I think the OLED issue is related to the dropout issue.

When the dac8x is connected to the RPi 5, GPIO 5 shows as being used by "hasadc". I see that @phofman provided some insight to this behavior here -> https://www.diyaudio.com/community/...-analog-to-hdmi-converter.425941/post-7975977 and it is related to detecting the adc8x.

I can re-assign "data bus 3" from GPIO 5 to 11. I will also re-assign "data bus 5" from GPIO 2 to 7 and "data bus 7" from GPIO 3 to 8 as Hifiberry implies that GPIO 2 and 3 are used for configuration in the link below.

GPIO usage of HiFiBerry boards | HiFiBerry

I've tested this on the RPi 5 with a dac8x as well as a RPi4 and it works fine.

Only downside is that existing users will need to re-wire if they do a new install, but I think it is better to make the tutorial universal so that it works for all applications.

Michael

Great, thanks, this is good news indeed. I looked at your github and found new version of oled.py. So I guess I have to just rewire and use new oled.py... is that correct?

 

[mdsimon2]

Great, thanks, this is good news indeed. I looked at your github and found new version of oled.py. So I guess I have to just rewire and use new oled.py... is that correct?

Yes, download the new oled.py and wire per the instructions currently on the Github tutorial. I've been running the S2 + dac8x + OLED setup for the last two days and it seems fine.

Michael

 

[mario222]

Thank you very much for all advice. Dropouts are still there unfortunately, even with rewiring and instaling new oled.py (I post picture for reference). I decided then to stop camillagui, oled and camilladsp services and try just bare dac8x with RPI5. Did not help. The next step was to use dac8x on RPI5 without adapter and disconnect all the other peripherals. Even with such bare setup (RPI5+dac8x playing youtube video on dac8x), droputs are still there. Droputs dissappear when for example HDMI is used as sound output... The next logical step is to post a question to hifiberry forum, this is clearly not camilladsp problem. I am sorry for bothering you with my questions.

 

[phofman]

Are the dropouts present when hooking the hat directly onto the Pi, not using the extension flat cable?

 

[mario222]

Are the dropouts present when hooking the hat directly onto the Pi, not using the extension flat cable?

Yes, exactly. A they dissappear when I switch sound output to HDMI for example...

 

[phofman]

OK, IIUC you are still having pulseaudio/pipewire in your test chain. Try playing directly wav with aplay to the hw:X device (of course while having that device disabled in pulseaudio/pipewire).

 

[mario222]

OK, IIUC you are still having pulseaudio/pipewire in your test chain. Try playing directly wav with aplay to the hw:X device (of course while having that device disabled in pulseaudio/pipewire).

Thanks. It is true, pipewire processes are running. I will try also to modify buffer settings for pipewire, and if that or your idea does not help, will try again on clean RPI OS...

 

[mario222]

Well flashed a clean 64 bit RPI OS, tried a youtube video playback from chromium, on dac8x ..no dropout at all. Though, I do not understand the problem with previous SD card, now everything works fine. I will add / connect in step by step manner all other components and camilladsp software and i hope that this time with more success . Thank you very much for all replies.

 

[mario222]

Well flashed a clean 64 bit RPI OS, tried a youtube video playback from chromium, on dac8x ..no dropout at all. Though, I do not understand the problem with previous SD card, now everything works fine. I will add / connect in step by step manner all other components and camilladsp software and i hope that this time with more success . Thank you very much for all replies.

...and some additional discussion about the problem can be found here: https://support.hifiberry.com/hc/en-us/community/posts/30306418917405-dac8x-droputs-each-few-seconds