CamillaDSP - How are you using it?

[Snoopy8]

I have been using CPUsets to allocate processes to individual CPUs and SQ has certainly improved.  One of the CPUs is dedicated to CamillaDSP and it is lightly loaded with my convolution filters.

https://www.snakeoil-os.net/forums/thread-592-post-4724.html#pid4724

[aussievintage]

44 minutes ago, Grizaudio said:

 

I wonder if this could be modified for 'other' streaming software's.

Niktech, are you saying you noticed a difference in SQ? or more for CPU cycle loading.   

 

Running moOde on a rPi 3, it still used very little cpu to just stream and play music.  What I am saying is that I think Camilla will be the main load.  I am still experimenting and waiting to see, but I suspect, there won't be any problems for most applications on my rPi4 that I currently use for moOde.

[Niktech]

1 hour ago, Grizaudio said:

 

I wonder if this could be modified for 'other' streaming software's.

Niktech, are you saying you noticed a difference in SQ? or more for CPU cycle loading.   

Yes, there is an improvement in sound quality. 
 

when I used to run windows I used to use Process Lasso + TrustedClean (unlimited instances of Majority Clean -ME/LE) and Fidelizer Pro to the same effect.

[davewantsmoore]

2 hours ago, Grizaudio said:

What does this setup look like Dave? 

It’s my speaker dev system…. To give me quick flexibility with filters in multi-way speakers or multi subs.   It’s windows, and I just use it like an 8x spdif sound card (to amps with spdif inputs).  
 

I also use this same source/box for multichannel tinkering (ambisonics) and stuff …. But I don’t have a good room setup for this.  One year soon this will all pivot (house build) so things will get more exciting, both for stereo and multichannel.  

[davewantsmoore]

17 hours ago, aris said:

now, I would say just run on Linux if you can!

1000%

 

I only run it on windows (yuck) because my sound card has bad/old Linux support, and I have speaker dev tools which are windows.  

[Grizaudio]

42 minutes ago, davewantsmoore said:

1000%

 

I only run it on windows (yuck) because my sound card has bad/old Linux support, and I have speaker dev tools which are windows.  

For sure, if your interface supports Linux, it’s the best option. 
 

The latest server version is running kernel 6.2, I think some beta versions are running 6.5…… from about 5.17 USB implementation improved considerably. 

[aris]

5 hours ago, Grizaudio said:

IMO, once ProDSP amp module SQ is on par with what I'm hearing in my system, I'll make the jump - for simplicity and elegance. 

Looking at your setup, running AES67/Dante DSP amplifiers would certainly simplify your setup, as you could easily run 4x8ch Pro DSP amplifiers, with signal routing via a AES67/Dante interface of your choice.  

 

The Linux Ravenna/AES67 module (open source version bondagit/aes67-linux-daemon) does support the above configuration, namely 4 seperate devices of 8ch each. Currently you need a network switch and to run PTP on a seperate device to properly work. Sigh. A configuration I’m working on involves a 4 port Ethernet card to connect to the endpoints. The maintainer of the above project is considering that a future feature request:) That way you don’t need a separate PTP source (just run in locally) and no switch. 
 

I’m not a big fan of proprietary protocols, for building into a product as it introduces design limitations that only a vendor can provide, so prefer open standards such as AES67 and AVB. 
 

Network (audio over IP) power amplifiers are generally lower in performance and/or super expensive.

But current gen class D such as Hypex and Purifi with an AoIP endpoint and multichannel DAC is achievable with some know now - so we can have good quality network amplification at a decent price point, albeit with some effort. 

 

[aris]

48 minutes ago, davewantsmoore said:

1000%

 

I only run it on windows (yuck) because my sound card has bad/old Linux support, and I have speaker dev tools which are windows.  

Nod. One of the configurations I’ve got running involve a Compute Module Pi4 board and PCIe 8ch cards. 
 

There are a few - very expensive - PCIe pro audio sound cards, with Linux support. These are mainly for broadcast studio use. 
 

Unfortunately the consumer cards are single ended so not easily adaptable into my multi channel amps (NC252MP based).

 

It is possible to have an appliance based distributed Audio over IP based Linux multichannel setup but it is expensive and somewhat complex to set up.

 

But I digress. CamillaDSP is the glue that makes all this possible!

[davewantsmoore]

19 minutes ago, Grizaudio said:

USB

Mine is PCIe.

 

10 minutes ago, aris said:

PCIe pro audio sound cards with Linux support

I thought I was buying one (16x digital outs) .... turns out they stopped with Slackware.

Kernel 2 and 32bit is fine... but.

 

10 minutes ago, aris said:

Unfortunately the consumer cards are single ended so not easily adaptable into my multi channel amps (NC252MP based).

Same amps here, but I use their DAC also (either the OEM parts, or the "Fusion" plate amps).

You can drive there Hypex amps with a single ended source fine, but.

 

10 minutes ago, aris said:

It is possible to have an appliance based distributed Audio over IP based Linux multichannel setup but it is expensive and somewhat complex to set up.

I've been watching ever single AVB and similar came on the scene.

A long time ago I used to run some pretty complex pulseaudio stuff (sinks over the network, etc.), and also use it to run multiway speaker using USB stereo DACs piped through brutefir and other mind numbingly stupid things I would never recommend (then, or) now.... LOL.

 

10 minutes ago, aris said:

CamillaDSP is the glue

[Grizaudio]

20 minutes ago, aris said:

Network (audio over IP) power amplifiers are generally lower in performance and/or super expensive.

 

Hopefully over the next few years this gap will reduce.

Pro Tier 1 Class D technology is certainly improving. 

 

24 minutes ago, davewantsmoore said:

Mine is PCIe.

 

Old Skool. Nice  

 

24 minutes ago, davewantsmoore said:

Same amps here, but I use their DAC also (either the OEM parts, or the "Fusion" plate amps).

 

I played with the fusion software, how do you find it? I found it a little lacking in crossover selection etc, with stacking required. Do you find interfacing with the software stable and predictable? 

 

56 minutes ago, aris said:

I’m not a big fan of proprietary protocols, for building into a product as it introduces design limitations that only a vendor can provide, so prefer open standards such as AES67 and AVB. 

 

I can see that in your system configuration choices. There is certainly an art to creating elegant solutions with open source software. I'm all for it. 

I would be interested in hearing more about your Pi Compute/PCI solution...... and how CamillaDSP performed? Its certainly a direction I have considered, with a slightly different implementation. 

 

57 minutes ago, aris said:

But current gen class D such as Hypex and Purifi with an AoIP endpoint and multichannel DAC is achievable with some know now - so we can have good quality network amplification at a decent price point, albeit with some effort. 

 

100%. I'm always searching for elegance and simplicity in application. Less cables, less fuss, less hardware. 

So I like any approach which can simplify and maintain or improve sound quality. 

 

Purifi and Hypex have certainly changed the value v's performance landscape for amplification.

Just in this thread alone, there are many of us running Hypex and Purifi solutions. 

 

We have so many options available to us these days, we are really spoilt for choice when creating DSP or active solutions.  

...................

 

 

Moving back to Camilla...... Does anyone have their finger on the pulse regarding CamillaDSP V2 improvements? 

Any links for updates etc. 

 

[aris]

25 minutes ago, Grizaudio said:

Moving back to Camilla...... Does anyone have their finger on the pulse regarding CamillaDSP V2 improvements? 

Any links for updates etc. 

 

I’ve been watching Henrik’s PR and I have to say there are a lot of fixes and improvements. I’ve been running v2 pre release versions for a while and they are super stable. 
 

I’m sure it won’t be long now before it’s finalised and released. 
 

Your best option is to look at the commit history on next20 branch for details at the moment as well as the docs in the branch which have been updated. 

[aris]

The flexibility in CamillaDSP surpasses any DSP runtime that I’ve seen. The commercial variants are too rigid and constrained which is understandable given that most are resource bound by the underlying CPU, memory etc. 

 

With CamillaDSP and a good DSP toolkit (rePhase or Acourate) and modelling software (VituixCAD for example) you can do, learn and understand what’s going on with your speaker design and build.
 

Add OnShape for CAD and you almost have a complete design and produce toolset. 
 

I mention the above as supporting CamillaDSP. How you configure CamillaDSP is the important thing. The fact that CamillaDSP enables the ability for us is the amazing icing on the cake. 
 

 

[aris]

1 hour ago, Grizaudio said:

I would be interested in hearing more about your Pi Compute/PCI solution...... and how CamillaDSP performed? Its certainly a direction I have considered, with a slightly different implementation. 

I use the CM Pi4 as an endpoint, a front end to an active 8ch speaker. The CM Pi4  has a TSN (time sensitive networking, ie AVB) capable Ethernet device (with some issues but workable as a HW timestaming device) and so can be included in a TSN audio chain.

 

I sometimes run CamillaDSP on the CM Pi4 for monitoring the 8ch audio visually. CamillaDSP doesn’t take up much resources so it’s easy to fit it in between the endpoint (ie AES67 or AVB), and the DAC. In production I turn CamillaDSP off on the endpoint as a central CamillaDSP instance is running upstream. 

[davewantsmoore]

59 minutes ago, Grizaudio said:

I played with the fusion software, how do you find it?

Horrible.

 

59 minutes ago, Grizaudio said:

I found it a little lacking in crossover selection etc, with stacking required.

I don't find it's missing anything per se.... but it isn't very usable.

I develop all my filters elsewhere, and then just "replicate" them in the Hypex filter manager.... so, I get by.

 

27 minutes ago, aris said:

With CamillaDSP and a good DSP toolkit (rePhase or Acourate) and modelling software (VituixCAD for example)

These tools are very problematic for speaker design, unless you really really know what you're doing.   A big example being that they do no send clear signals when the data you are using doesn't represent reality......  I'm no proponent of passive crossovers, but at least back in the day you really needed well sorted speaker measurements and/or simulations, otherwise your typical "baffle step correction and crossover" didn't fit the data (and you had to ask "why" ... and you learned it was the data).

hese days we can make all sort of "mistakes".... feed wrong data, linearise out diffractions, etc. etc.. and get "perfect result" (but only looks perfect).

Anyways.... grumpy old (barely middle aged) man </soapbox>.

 

[davewantsmoore]

1 minute ago, davewantsmoore said:

These tools are very problematic

Oh - I don't mean to suggest you did anything wrong.... just shudder at the recommendation. (but of course, anything can be used well, or misused).    You can of course, do any of the "right" things in rePhase or Accurate, or similar.

[Grizaudio]

2 hours ago, aris said:

next20 branch 

Sorry what's this? can you share a link? 

[aris]

Yes, the tools need good data and the results need a great deal of experience (ie pain) to interpretation to iterate to a good result. That’s a whole other issue and I agree that there are big gaps and pitfalls.

Edited July 11, 2023 by aris

[tripitaka]

2 hours ago, davewantsmoore said:

You can of course, do any of the "right" things in rePhase or Accurate, or similar.

 As a bumbling fool of HiFi, I must say that I absolutely love Rephase,  its power makes me feel like a god tho I've discovered 'less is more' when you don't really know what you are doing

[aris]

8 hours ago, Grizaudio said:

Sorry what's this? can you share a link? 

 

This should get you a list of changes for v2 (still work in progress). Note that it's mostly code!

 

I sometimes browse the repository branch directly (https://github.com/HEnquist/camilladsp/tree/next20)

 

 

Edited July 11, 2023 by aris

[davewantsmoore]

13 hours ago, tripitaka said:

I absolutely love Rephase

Being able to adjust the phase independently of the amplitude (which is what rePhase can help you do, that many others can't) isn't a tool which really helps us in a speaker design.....   but in an overall "room" correction, it can be good tool.

[tripitaka]

I had a brief flirtation with CamillaDSP on an RPi4, but must have been something wrong since it didn't sound great, I'll revisit it at some stage. But can I ask the brains trust, how you are formatting the FIR impulses you are uploading, eg, 32bit 48kHzWAV file?

[Grizaudio]

13 hours ago, tripitaka said:

I had a brief flirtation with CamillaDSP on an RPi4, but must have been something wrong since it didn't sound great, I'll revisit it at some stage. But can I ask the brains trust, how you are formatting the FIR impulses you are uploading, eg, 32bit 48kHzWAV file?

I’m out atm, so a short and sweet message…

 

Your FIRs need to match the sampling rate set in CamillaDSP….
 

if you are using multiple FIRs, my advice is to keep tap lengths the same, especially across channels, although Henrick confirmed with me mixing tap counts is ok. 
 

All my FIRs are wave 64bit I believe,  mono, via rephrase. 
 

 

 

Edited July 12, 2023 by Grizaudio

[Grizaudio]

14 hours ago, aris said:

 

This should get you a list of changes for v2 (still work in progress). Note that it's mostly code!

 

I sometimes browse the repository branch directly (https://github.com/HEnquist/camilladsp/tree/next20)

 

 

Thanks Aris 

I touched base with Henrick. 
many thanks 

[Grizaudio]

10 hours ago, tripitaka said:

I had a brief flirtation with CamillaDSP on an RPi4, but must have been something wrong since it didn't sound great, 

 

Likely config, filter or setup issues. 

I personally don't hear a difference between Roon's convolution engine and CamillaDSP. 

Both are quality solutions. 

 

My hope is a better GUI and user experience over time.

Improving the GUI, and making it easier to select, implement and alter filters would be amazing.

A traditional tap and drag response interface would be very welcome. 

 

I believe V2 is trying to implement some of this, in GUI changes. 

 

But everything you need is there. 

Edited July 12, 2023 by Grizaudio

[Grizaudio]

On 11/7/2023 at 1:12 PM, Snoopy8 said:

I have been using CPUsets to allocate processes to individual CPUs and SQ has certainly improved.  One of the CPUs is dedicated to CamillaDSP and it is lightly loaded with my convolution filters.

https://www.snakeoil-os.net/forums/thread-592-post-4724.html#pid4724

I’m curious how I would implement this for Roon bridge, Camilla, Ubuntu on my Pi? Any helpful ideas.