CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.

Jump to Latest
HenrikEnquist

HenrikEnquist

Member
Joined 2016
Ok, then this problem looks very familiar. There has been problems before with spdif input hats that freeze and can't recover when the signal stops and comes back. I don't remember exactly what device it was last time (it was a while ago) but I suspect it is the same. We never found any solution, the device or the driver has some issue that seems difficult to work around.
Can you use a converter to connect the TV output to the aes input on the Octo instead? I would expect that to behave better.
 
V

varunach

Member
Joined 2023
HenrikEnquist said:
Ok got it :) You have an extra Volume filter in the pipeline, reacting to fader Aux1.
In v2.0 there is always a volume control, no need to add one as a filter. The Aux1 fader will be set to -6 dB by the mpd2cdspvolume daemon:

The Aux faders are not (yet) exposed in the UI, only the Main one is. Which means this extra volume control is stuck at -6 dB.

The solution is simply to get rid of the Volume filter :)
Click to expand...
@HenrikEnquist that explains it! Thank you. I removed the Volume filter and I do notice a change in loudness/volume 😀 Having said that now the 'Clipped samples' counter is shooting up. For one of the local songs I usually listen to, the counter shot up to ~300 clipped samples which seems odd. Looks like I need to have some sort of attenuation to avoid that? What's the best filter/configuration to avoid clipped samples in general?
 
P

phofman

Member
Joined 2005
HenrikEnquist said:
There has been problems before with spdif input hats that freeze and can't recover when the signal stops and comes back. I don't remember exactly what device it was last time (it was a while ago) but I suspect it is the same. We never found any solution, the device or the driver has some issue that seems difficult to work around.
Click to expand...

That soundcard is combo of RPi I2S and WM8804.

If WM8804 stops sending I2S clocks, userspace will detect xrun, send snd_pcm_prepare -> the rpi i2s driver will call bcm2835_i2s_clear_fifos() https://github.com/raspberrypi/linu...5c1ae45/sound/soc/bcm/bcm2835-i2s.c#L630-L635 which will:

1) read current I2S status https://github.com/raspberrypi/linu...939725c1ae45/sound/soc/bcm/bcm2835-i2s.c#L170

2) stop I2S peripheral at the given direction https://github.com/raspberrypi/linu...939725c1ae45/sound/soc/bcm/bcm2835-i2s.c#L179

3) wait a while for the I2S peripheral to indicate running PCM clock (bclk), log "I2S Sync error" to dmesg if timed out. https://github.com/raspberrypi/linu...5c1ae45/sound/soc/bcm/bcm2835-i2s.c#L199-L207

4) restart the I2S device with the previous status https://github.com/raspberrypi/linu...5c1ae45/sound/soc/bcm/bcm2835-i2s.c#L213-L215

If WM8804 is not sending any clocks, the indication should be the "I2S Sync error" error in dmesg. I have seen those errors in my tests with RPi I2S, this works. It's very likely the I2S will get stuck when requested to start with no incoming PCM clock, without proper initialization routine done in snd_pcm_open + snd_pcm_start -> bcm2835_i2s_startup + bcm2835_i2s_trigger + bcm2835_i2s_hw_params.

Now the WM8804 can be told to output its internal clock when no SPDIF stream is incoming, so that downstream keeps receiving a valid I2S signal. The register AIFRX bit 7 SYNC_OFF https://www.mouser.com/datasheet/2/76/WM8804_v4.5-1141948.pdf page 61. The default value is "0 = LRCLK, BCLK are not output when S/PDIF source has been removed". The wm8804 linux driver does not seem to set this bit at all - https://github.com/search?q=repo:raspberrypi/linux WM8804_AIFRX&type=code + init value https://github.com/raspberrypi/linu...bdd939725c1ae45/sound/soc/codecs/wm8804.c#L54

IMO if the driver set the SYNC_OFF bit in wm8804_reg_defaults, the SPDIF receiver would keep sending zeros when no signal was preset, CDSP would not stall on capture, and the chain would be running continuously with zero samples (at the initial samplerate, of course).

IMO to test the hypotheses the user-space i2c-get/i2c-set utils could be used to read the register value and set the SYNC_OFF bit. If proven to work OK, the driver could be modified or maybe just running the user-space I2C setup upon loading the wm8804 module could do, provided the WM8804 is not reinitialized at snd_pcm_open.
 
  • Like
Reactions: 1 user
TimCurtis

TimCurtis

Member
Joined 2012
moodeaudio.org
HenrikEnquist said:
Ok got it :) You have an extra Volume filter in the pipeline, reacting to fader Aux1.
In v2.0 there is always a volume control, no need to add one as a filter. The Aux1 fader will be set to -6 dB by the mpd2cdspvolume daemon:

The Aux faders are not (yet) exposed in the UI, only the Main one is. Which means this extra volume control is stuck at -6 dB.

The solution is simply to get rid of the Volume filter :)
Click to expand...

Looks like @varunach was using an old Camilla 1x config file that had a volume filter. The one I posted is what we ship for Camilla 2 and it only contains dither and gain (set to 0) filters.
 
M

mdsimon2

Member
Joined 2013
HenrikEnquist said:
Can you use a converter to connect the TV output to the aes input on the Octo instead? I would expect that to behave better.
Click to expand...

@STUNTfingers, as suggested by Henrik, using the Okto AES input with the Okto in USB / AES mode is a great solution. I've been using an Okto like this for a few years with an Apple TV and CamillaDSP and it works great.

Interestingly enough, in my experience the Okto is the only device where CamillaDSP will not report a buffer under run when going from the PAUSED to RUNNING state. It seems to do this by consuming samples in a way that other devices do not. You can see this by observing the buffer level on the Okto is always much lower than similar devices with identical chunk size settings, this reduction in buffer level occurs after going from PAUSED to RUNNING just once. The post below and subsequent discussion cover this behavior.

https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-7469575

Michael
 
M

mdsimon2

Member
Joined 2013
In USB / AES mode, the Okto uses the AES input derived clock to control the timing of data sent to the DAC from the USB host after processing. The DAC itself is clocked asynchronously from a local oscillator. The manual has a description of this, but I think the explanation in this link gives a bit more detail -> https://www.audiosciencereview.com/...nts-of-okto-dac8-8ch-dac-amp.7064/post-333521.

But yes, this setup allows you to avoid aysnc resampling.

Michael
 
STUNTfingers

STUNTfingers

Member
Joined 2019
Thank you Phofman, Henrik and MDsimon, really appreciate the help with this. I feel like it must be something simple as all I need to do I turn the OKTO on first then switch the TV on and it works every time. In the 1.5 years I've been running this setup I've only reset the PI twice maybe.

@phofman thank you for your detailed reply, unfortunately I do not know enough about linux to investigate your suggestion but maybe this is helpful for others to try.

@mdsimon2 currently the setup is as follows:

TV (optical out) --> (SPDIF hat input) RPI running CDSP -- (USB out of RPI) --> (USB in) OKTO DAC 8 (pure USB mode)

Are you suggesting to just switch the mode of the DAC to AES USB instead of pure USB? Also with your setup using the Apple TV I assume you're not getting multichannel audio to the DAC like 5.1 from in the OKTO?
 
Last edited:
M

mdsimon2

Member
Joined 2013
STUNTfingers said:
Are you suggesting to just switch the mode of the DAC to AES USB instead of pure USB? Also with your setup using the Apple TV I assume you're not getting multichannel audio to the DAC like 5.1 from in the OKTO?
Click to expand...

Yes, get rid of the SPDIF input HAT and switch the Okto to USB / AES mode. You'll set the Okto as your CamillaDSP capture device.

You will need some converters to get from TOSLINK to AES but that is pretty simple. The easiest way is a TOSLINK to coaxial converter with a RCA to XLR cable. This should work fine but if it doesn't you'll just need a RCA to BNC cable with a SPDIF to AES transformer like the Canare BCJ-XP-TRB.

With the AppleTV I am only doing stereo via a HDMI to SPDIF extractor. I have experimented with multichannel audio out of the Apple TV using a HDMI to I2S board and a Raspberry Pi 5 but ran in to some issues, see this thread for more info -> https://www.audiosciencereview.com/...ill-get-a-whole-lot-easier-and-cheaper.48233/.

Another alternative if you only want compressed DD 5.1 is to get a Dolby DP562 converter which can convert DD 5.1 to 3x AES in to the Okto. They are cheap on e-bay.

Michael
 
P

phofman

Member
Joined 2005
STUNTfingers said:
unfortunately I do not know enough about linux to investigate your suggestion
Click to expand...
Doing the test would be quite simple. The I2C address should be 0x3b according to the driver, and the address of the register is 0x1C (28 decimal), setting bit 7 (MSB). In the end four commands - getting I2C adapter ID (most likely I2C 1, according to the driver) and checking the codec adddress with i2cdetect, reading the current register value with i2cget, and writing the updated value to the same register with i2cset, exactly as described in https://vocal.com/resources/development/using-the-linux-i2c-tools-software/ . More details e.g. https://www.abelectronics.co.uk/kb/article/1092/i2c-part-3-i2c-tools-in-linux . IMO it would be useful to find out if it resolves the issue with hifiberry-digi + RPi I2S combo.
 
Last edited:
ChrisMmm

ChrisMmm

Member
Joined 2005
I have just upgraded to vesion 2 from version 1, both the DSP and the GUI. Specifically Camillagui 2.1.0 (also tried 2.1.1) but I am getting the following on starting the gui:
ImportError: cannot import name 'Draft202012Validator' from 'jsonschema'

I saw an earlier post somebody had the same problem and and old version of Python3 was mentioned. I think the version I have is the latest 3.10.12. This is running on Ubuntu server 22.04 (amd64) with latest updates applied. I specifically checked all the python3 software and its all up to date.

Any help or suggestions much appreciated.

Have been running Camilladsp for a couple of years and its run perfectly since updating to version 1, I have updated a couple of times and this is the first problem I have had to date.
 
M

maravedis

Member
Joined 2009
I appreciate this is a long shot and might need it's own thread - but here goes....

I'm sure all those who have experienced Baach filters will agree - there is no going back. It's worth every penny and more.
https://www.bacch.com/ubacch
I'd really love to find a way of integrating Baach with CamillaDSP. At the moment I'm running the Bacch VST plugin in Reaper but it seems that there is an ALSA version available. I don't have the expertise to do this myself.
https://static1.squarespace.com/sta...59642833195/BACCH4ALSA_Product_Brief_v1.0.pdf
How feasible would it be to use this in conjunction with CamillaDSP - perhaps on a RPI4?
 
TNT

TNT

Member
Joined 2003
Paid Member
Is the BAACH algorithm known? Probably not so not going to be implemented via CDSP filters.

So I assume you need to get a VST plug compatible player to run on a Pi and then feed Camilla into order to achieve this.

Could CDSP provide a VST execution environment as a "Processor"?

//
 
P

phofman

Member
Joined 2005
The BACCH4ALSA info https://static1.squarespace.com/sta...59642833195/BACCH4ALSA_Product_Brief_v1.0.pdf says their "alsa version" is a library and an app designed to read from alsa - process -write to alsa, just like CDSP. You can always put snd-aloop between CDSP and bacch4alsa.

Theoretically CDSP could be modified to use the mentioned library (if someone had access to its API). But the given list of supported platforms is quite short (and there is no source code to recompile for other platforms, IIUC).
 
You must log in or register to reply here.
Top Bottom