hence the pointlessness of using DAC / multi channel DAC at all
And of course hence my interest doing it over DANTE
I am hoping to get some progress on that side of it this summer
Having tested a nicely overclocked CM4 - writing it with this now...if I get my way and I do get the Dante implementation I am looking for it's 64 ch, and forget the whole DAC discussion becomes it becomes irrelevant. (you can have your DAC wherever you like on Dante)
How does Dante handle clocks? IIUC it requires adaptive resampling in the "renderers" as the stream carries time info.
What renderers are available on the market? IMO an I2S multichannel DAC is easier than multiple FPGAs with proprietary Dante code (how do you build one on your own?) plus handling the clock adaptation to local clock by the DAC. But I may be wrong, I have just read a few publicly available pages.
What renderers are available on the market? IMO an I2S multichannel DAC is easier than multiple FPGAs with proprietary Dante code (how do you build one on your own?) plus handling the clock adaptation to local clock by the DAC. But I may be wrong, I have just read a few publicly available pages.
Like this?
Also works for fir filters, but the phase unwrapping is really tricky and will probably never be perfect:
This won't make it into the next gui release. That one is nearly done and I don't want to delay it. But the next one will have it.
The command line plotting tool has it if you use this branch: GitHub - HEnquist/pycamilladsp-plot at groupdelay
I dont get how you went from my statement to the conclusion you made? The requisite fiddling needed to use dante is over the top. why exactly does any use of it make a multichannel dac irrelevant? you still need one, or in your case anywhere from 8 x 8ch to 32 x 2ch of them ... yes, it allows you to place it in the speaker, but unless you want 32 separate 2 channel dacs in your 64 channel system, I would say an 8 channel dac is rather relevant.
Your 64ch use case is hardly normal ... I briefly looked at the dante system after the dead end thread here, that was so full of excitement and then disappointment, but the hurdles needed (glue logic/FPGA) to get even a basic 2 channel dac is off-putting. I have zero need for more than 8 channels and that goes for all but perhaps 1% of users. Dante is a trick piece of hardware, but availability through large MOQ, or a small, limited number of NOS available at a single reseller on ebay ... isnt exactly enticing.
agreed, i'm confused about what this over complication brings to the party ... add to that the fact he hasnt even started his project ... and ....
Last edited:
Dante is AES 67.
You can buy an off the shelf DAC that plugs into AES67 and gigabit ethernet. Latency is neglible as it's all done thru Dante Audinate controller systems.
Being as convolution is a native part of the system a Linux-Dante interface (yes for now in Dev) brings the possibility to run a DSP into as many channels as you like.
It already runs on AMD64 linux, hence the interest in porting to ARM 64 and Pci-e.
I managed to install the GUI and it is running - it displays the web page. However, it is stating "Not connected to CamillaDSP". I have camilladsp running as a service. I installed all the necessary things (I think), I get even plots in the GUI. I would be grateful for any help with debugging (and later how to start the GUI after power on before login). I have a Behringer 10ch USB soundcard on the way, so later the fun will begin with setting up a 2x4 crossover.
Is there a way to check if everything was installed correctly?
Edit: I always figure out shorty after posting the question
I had to edit the service file to add -p1234 to the running command.
Now how would I run the gui as system service? Create a service file with python3 /pathto/camillagui/main.py?
Is there a way to check if everything was installed correctly?
Edit: I always figure out shorty after posting the question
I had to edit the service file to add -p1234 to the running command.Now how would I run the gui as system service? Create a service file with python3 /pathto/camillagui/main.py?
Last edited:
There is more ways how to start it. There is no need to start it before the service, it will connect anyway.
- Make your user autologin and add the command (something like /usr/bin/python3 /home/USER/camilladsp/camillagui-backend/main.py) to your Startup Applications.
- Or you can just paste it to the /etc/rc.local if your OS has it
- Or add the .service file
- Make your user autologin and add the command (something like /usr/bin/python3 /home/USER/camilladsp/camillagui-backend/main.py) to your Startup Applications.
- Or you can just paste it to the /etc/rc.local if your OS has it
- Or add the .service file
I have been following this work for some time, and I must say I am really impressed with the results! The group delay filter in the new version got my attention. Would it be possible to use this to remove group delay at the low frequencies. i.e 20-100 hz ? I have tried this with FIR filters on MiniDSP but it added severe pre echo effect and not very pleasant to listen to
As xorcz wrote there are many ways. Since you already have the systemd service file for camilladsp working, the quickest is probably to just copy and modify that one.
The group delay plot is just a plot that shows the group delay of the filters. There is no special filter for correcting group delay. To do that you will have to use FIR filters, like you already tried. Maybe you can find a better way to create the FIR filter coefficients, that doesn't have as much pre-echo? What did you use?
Thank you for your quick reply, I've followed the recipe on minidsp page (example 1) correcting loudspeaker phase using rephase and importing that to minidsp 2x4 hd
rePhase FIR Tool
I got a Behringer UMC1820 soundcard and I was able to set a config file with a 2 to 8 mixer.I can see the card in aplay -l and I can control volume in alsamixer. But when starting CamillaDSP, I get an error: "Playback error: ALSA function 'snd_pcm_hw_params_set_channels' failed with error 'EINVAL: Invalid argument'". Any ideas on what could be wrong will be appreciated.
A USB audio device specifies one or more alternate settings with supported channel count, samplerate, and samples size combinations. If the alsa hw device is opened with one of the supported combinations, the snd-usb-audio driver automatically tells the device which altsetting to use and accepts that combination. All other combinations are refused. An unsupported combination can be automatically "aligned" to the closest supported combination by the plug plugin (plughw:xxx).
The altsetting combinations are listed in /proc/asound/cardXX/stream0 file.
The altsetting combinations are listed in /proc/asound/cardXX/stream0 file.
Last edited: