RPi4 + CamillaDSP Tutorial

[jdubs]

I think the way that the Okto does it is best, there is mute indication and if you change the volume while muted it shows the change on the display but doesn't remove the mute. Once you unmute it will go to whatever the volume is on the display.

Yes! This sounds ideal. Thanks for your continued work on this, Michael!!

-Jim

 

[MCH]

I added mute functionality to flirc.py last night (see attached). It was a bit different than using the GUI mute because it didn't return to the previous volume when using cdsp.set_mute(). As a result I store the volume at time of mute and then revert to that when unmuted or if the volume is increased. Mute button is key left.

I think I will work towards having some sort of mute indication as I don't particularly like the behavior of the volume showing -99 and not knowing if the next volume increase will go to -98 or the previous setting. I think the way that the Okto does it is best, there is mute indication and if you change the volume while muted it shows the change on the display but doesn't remove the mute. Once you unmute it will go to whatever the volume is on the display.

Michael

Just tested. Works as intended.

Actually, it is so cool to be able to tune what the remote does. (well, if you know how to do it of course, not my case yet )

Thanks again Michael!

 

[snake69fast]

Hi! How to install and use CamillaDSP in picoreplayer? Thank you!

 

[mdsimon2]

Hi! How to install and use CamillaDSP in picoreplayer? Thank you!

You should be able to roughly follow this tutorial but there may be differences on required dependencies and DAC compatibility depending on kernel. I don't know how picoreplayer works but imagine you would set your playback device as an ALSA loopback to have the output processed by CamillaDSP. Maybe someone with more knowledge of picoreplayer can advise.

Michael

 

[somebodyelse]

You should be able to roughly follow this tutorial but there may be differences on required dependencies and DAC compatibility depending on kernel. I don't know how picoreplayer works but imagine you would set your playback device as an ALSA loopback to have the output processed by CamillaDSP. Maybe someone with more knowledge of picoreplayer can advise.

Michael

piCorePlayer is structured rather differently to most linuxes, so the installation process is rather different. The diyaudio thread below, along with the associated repositories, should cover it, but I've not tried following it yet.
https://www.diyaudio.com/community/...lerate-switching-esp32-remote-control.361429/
https://github.com/Lykkedk/SuperPlayer-v8.0.0--CamillaGUI-v0.6.0
https://github.com/Lykkedk/SuperPlayer-v8.0.0---SamplerateChanger-v1.0.0

 

[mdsimon2]

I added mute functionality to flirc.py last night (see attached). It was a bit different than using the GUI mute because it didn't return to the previous volume when using cdsp.set_mute(). As a result I store the volume at time of mute and then revert to that when unmuted or if the volume is increased. Mute button is key left.

I think I will work towards having some sort of mute indication as I don't particularly like the behavior of the volume showing -99 and not knowing if the next volume increase will go to -98 or the previous setting. I think the way that the Okto does it is best, there is mute indication and if you change the volume while muted it shows the change on the display but doesn't remove the mute. Once you unmute it will go to whatever the volume is on the display.

Michael

Updated flirc.py and oled.py (attached to OP) to implement this mute behavior. Also confirmed with Henrik that the muting in the GUI is not using set_mute() / get_mute() which is why it was operating differently than an IR triggered mute, sounds like this will get updated down the line to use set_mute() / get_mute(). Mute binding is still KEY_LEFT.

Michael

 

[Wirrunna]

Michael, For CamillaDSP RPi4 users waiting for the still unobtainable Motu Ultralight MK 5, the new Topping DM 7 appears to be a substitute output device however for the same cost the Motu UL Mk 5 provides input.
I'll wait for the Motu.

 

[mdsimon2]

Michael, For CamillaDSP RPi4 users waiting for the still unobtainable Motu Ultralight MK 5, the new Topping DM 7 appears to be a substitute output device however for the same cost the Motu UL Mk 5 provides input.
I'll wait for the Motu.

Supposedly the MOTU will be available again in August but we will see.

I think the MOTU is a better value than the DM7 due to much better i/o and support but the DM7 does have several features that make it attractive, namely IR volume control and trigger out.

Michael

 

[MCH]

Updated flirc.py and oled.py (attached to OP) to implement this mute behavior. Also confirmed with Henrik that the muting in the GUI is not using set_mute() / get_mute() which is why it was operating differently than an IR triggered mute, sounds like this will get updated down the line to use set_mute() / get_mute(). Mute binding is still KEY_LEFT.

Michael

Not having the display set up yet, will keep your first flirc.py with the mute function you drafted.
I find it too risky to inadvertently press vol up while on mute and blow my ears when unmuting.

I would suggest to keep both files available for people not building the display.

Thanks again!

 

[mdsimon2]

Not having the display set up yet, will keep your first flirc.py with the mute function you drafted.
I find it too risky to inadvertently press vol up while on mute and blow my ears when unmuting.

I would suggest to keep both files available for people not building the display.

Thanks again!

Ahh, interesting, that is a good point. Thanks for the feedback.

Just added both to the post (flirc1.txt and flirc2.txt) and added some brief text about the differences.

I must say I like how easy it is to customize this stuff, very nice to be able to dial in your desired behavior.

Michael

 

[HenrikEnquist]

Thought I'd just mention that I'm working on updating the gui to use get/set_mute, as well as to watch for changes of the volume and mute settings in the dsp. This makes the gui behave properly when it's not the only client that may change the volume. It's nearly done, there will be a new preview of the gui shortly.

 

[McFly]

Please excuse my lack of Technical understanding but could one use this camillaDSP on a Rpi as an upgrade to a miniDSP 2x4HD which is currently used to drive 2 way active L+R channels in a home theatre setup? Or would there be latency issues? What extra hardware would I need to source?

(My miniDSP is only using IIR XO & PEQ filtering, but I would like to start playing with some FIR filtering at some stage, perhaps starting with a crossover correcting all pass filter or similar ie Grimm LS1 style)

 

[mdsimon2]

Please excuse my lack of Technical understanding but could one use this camillaDSP on a Rpi as an upgrade to a miniDSP 2x4HD which is currently used to drive 2 way active L+R channels in a home theatre setup? Or would there be latency issues? What extra hardware would I need to source?

(My miniDSP is only using IIR XO & PEQ filtering, but I would like to start playing with some FIR filtering at some stage, perhaps starting with a crossover correcting all pass filter or similar ie Grimm LS1 style)

Can you give a few more details on what you are trying to do? When you say home theatre setup are saying implement 2 way active L + R as part of a larger 5.1, 7.1, etc system?

What inputs are you looking for?

I would be a bit hesitant to use CamillaDSP in a system where I was only using CamillaDSP on some of the channels. You are looking at at least 30 ms delay with CamillaDSP which is rather large to compensate for in the other channels. You would also need to worry about stability of that delay. You would definitely need to use a device that can be clocked by your source (i.e. TOSLINK / SPDIF interface of an audio interface) but even then I think I would be worried about slight timing differences ruining my phase matching.

Michael

 

[McFly]

Can you give a few more details on what you are trying to do? When you say home theatre setup are saying implement 2 way active L + R as part of a larger 5.1, 7.1, etc system?

What inputs are you looking for?

I would be a bit hesitant to use CamillaDSP in a system where I was only using CamillaDSP on some of the channels. You are looking at at least 30 ms delay with CamillaDSP which is rather large to compensate for in the other channels. You would also need to worry about stability of that delay. You would definitely need to use a device that can be clocked by your source (i.e. TOSLINK / SPDIF interface of an audio interface) but even then I think I would be worried about slight timing differences ruining my phase matching.

Michael

I'm currently running a 5.1.2 system, all from a denon X3700H. The main front left and front right analogue pre-outs (so forget the subwoofers) go to a miniDSP 2x4HD anologue inputs, doing PEQ and XO all IIR, with the 4 outputs feeding a 4 channel amplifier to power highs and midbasses of the front left and right speakers (no passive XOs). This works pretty well with only IIRC ~5ms delay (edit:relative to the other channels which are just running from the AVRs amplifier channels)

So I would need 2 analogue inputs and 4 analogue outputs. Was hoping to play around with more DSP options as I have a pi 4 here already.

Thanks for the reply Michael. Looks like I might stay status quo to avoid the audio delay. (About to start up my rant about TV manufacturers not including video delay, how hard would that be... grumble grumble)

 

[jensgk]

I would be a bit hesitant to use CamillaDSP in a system where I was only using CamillaDSP on some of the channels. You are looking at at least 30 ms delay with CamillaDSP which is rather large to compensate for in the other channels.

Would it be possible to run the other channels through some neutral filters in CamillaDSP just to get the same order of delay on all channels?

 

[mdsimon2]

I'm currently running a 5.1.2 system, all from a denon X3700H. The main front left and front right analogue pre-outs (so forget the subwoofers) go to a miniDSP 2x4HD anologue inputs, doing PEQ and XO all IIR, with the 4 outputs feeding a 4 channel amplifier to power highs and midbasses of the front left and right speakers (no passive XOs). This works pretty well with only IIRC ~5ms delay.

So I would need 2 analogue inputs and 4 analogue outputs. Was hoping to play around with more DSP options as I have a pi 4 here already.

Thanks for the reply Michael. Looks like I might stay status quo to avoid the audio delay. (About to start up my rant about TV manufacturers not including video delay, how hard would that be... grumble grumble)

It does make me curious. Rather than the absolute delay my bigger concern is the potential for variable delays in the device running CamillaDSP.

I think I will run some tests starting from an OpenDRC-DI (so I have ability to implement a lot of delay) in to a stereo DAC and then route one DAC output channel in to a MOTU M4 connected to a RPi4 running CamillaDSP. I can then compare the M4 output to the stereo DAC otuput using a Cosmos ADC to see the relative timing.

I wonder if I account for the delay of the non-CamillaDSP channel in the OpenDRC-DI if that delay stays stable or if it drifts a bit. Still the absolute delay of CamillaDSP is probably too much as I imagine most devices do not have the ability to implement 30+ ms of delay.

Would it be possible to run the other channels through some neutral filters in CamillaDSP just to get the same order of delay on all channels?

If you are running everything through CamillaDSP you do not have an issue. The problem is that some of the channels will not run through CamillaDSP. As mentioned above if the delay is fixed and does not drift then you should be able to account for the delay difference but it also will require a lot of delay (30+ ms).

Michael

 

[McFly]

Ahh I follow now! So ideally one would route all channels through an interface that can support those channels and then send the signal to external amps to fix the delays to every channel.

I see my AVR has a max delay of only 20ft between channels.

 

[artmis]

Hello, would the focusrite 4i4 be a good alternative to the motu m4? I would get the m4 but the volume knob doesn't control 2 of the outputs, which is unfortunate. I'm looking at the specs for the 4i4 and it says the line inputs 3 and 4 are fixed gain. Does that mean it is similar to the Motu m4?

 

[mdsimon2]

Ahh I follow now! So ideally one would route all channels through an interface that can support those channels and then send the signal to external amps to fix the delays to every channel.

I see my AVR has a max delay of only 20ft between channels.

Just ran the test. Two legs to the measurement setup are as follows:

1 -> OpenDRC-DA8 -> ch 1 -> Cosmos ADC L
2 -> OpenDRC-DA8 -> ch 2 -> MOTU M4 analog ch 1 input -> CamillaDSP -> MOTU M4 analog ch4 output -> Cosmos ADC R

At first I tried to do 96 kHz, 512 chunk size and no resampling however without resampling I would often get a capture error saying I was providing an invalid argument. It always worked with BalancedAsync resampling enabled.

For a given session I could dial in a delay that would perfectly sync the two channels but if I restarted CamillaDSP or the RPi the delay changed. It was always between 13-15 ms which was lower than anticipated but the variability of the delay after restarts would be a no-go for anything relying on phase matching.

I had anticipated that the relative delay might shift during a given session as I would see buffer levels changing but in practice no delay shifting was observed on the output which was very nice.

Michael

 

[McFly]

Legend thanks for doing that. Answers the question. Ill stick with AIO solutions for time being (minidsp 2x4HD in this case)