On a project I'm working on, I'm making a DSP/Server (https://www.lattepanda.com/lattepanda-sigma). The only thing I have in mind is CamillaDSP. That leaves a lot of resources on the table. Is there any other software I can/should use with all the extra overhead?
Hi,
I find your question a bit weird or at least formulated in a strange way.
I would rather ask what are your real needs? If you want to implement a kind of loudspeaker management unit ( a stand alone dsp dedicated to loudspeakers) then no need for a power dedicated workstation/server.
It'll have drawback to have too much power under the hood: heat means a way to dissipate it and miniaturisation being what it is it means fan ( probably way too small) which in turn means noise. Do you really want to have something ( probably) noisy located in your listening room? I don't. 😉
Then power consumption ( electricity): no need to consume a lot of current for a dsp which is a relatively low charge duty.
Iow i would size the computer to the duty it needs to perform rather than go with something 'oversized' which will not brings many thing to the table imho. If you need graphic power then it might be interesting to have a powerful computer but otherwise... not really. To give you an idea, i run an 8 chanel in/out dsp dedicated to the same task ( loudspeaker management unit) on an XP based computer running a single 2ghz processor with 4giga ram without issues for years.
As your initial question is related to software there is some you'll need as REW, as well as a soundcard to connect measurement mic which will be mandatory too imho.
I don't know which OS you'll run but be aware they might be issue to run everything into one unit ( hardware might not accept multiple client - software- sharing same ins/outs) and it might be easier to have a laptop to run measurement gear...
I find your question a bit weird or at least formulated in a strange way.
I would rather ask what are your real needs? If you want to implement a kind of loudspeaker management unit ( a stand alone dsp dedicated to loudspeakers) then no need for a power dedicated workstation/server.
It'll have drawback to have too much power under the hood: heat means a way to dissipate it and miniaturisation being what it is it means fan ( probably way too small) which in turn means noise. Do you really want to have something ( probably) noisy located in your listening room? I don't. 😉
Then power consumption ( electricity): no need to consume a lot of current for a dsp which is a relatively low charge duty.
Iow i would size the computer to the duty it needs to perform rather than go with something 'oversized' which will not brings many thing to the table imho. If you need graphic power then it might be interesting to have a powerful computer but otherwise... not really. To give you an idea, i run an 8 chanel in/out dsp dedicated to the same task ( loudspeaker management unit) on an XP based computer running a single 2ghz processor with 4giga ram without issues for years.
As your initial question is related to software there is some you'll need as REW, as well as a soundcard to connect measurement mic which will be mandatory too imho.
I don't know which OS you'll run but be aware they might be issue to run everything into one unit ( hardware might not accept multiple client - software- sharing same ins/outs) and it might be easier to have a laptop to run measurement gear...
Last edited:
At this point I'm not sure lol. I only really needed CamillaDSP, but I thought to myself "...what else could I add?" So I got a much more powerful SBC
Was actually going to see if I could get a custom heat sink for it. Nothing like a vapor chamber, just something basic. It's only 60W TDP which is fairly manageable.
Am definitely going to pick up REW. I'm going to attempt full servo control, hence the processing power. Will have ADCs for the speakers so when I use REW I won't need a mic input (or I could do both. Not sure. Not there yet).
I'm thinking Ubuntu server or at least some sort of Linux distro. Windows would be terrible for this sort of thing (at least in its current iteration. I'd be willing to be bet XP has definitely served you well).
Ok.
I think you should first define your needs and from there see what would suit you the best before investing. Maybe even try on an old discarded computer...
60w is not many for a processor we agree but from the pics of your server boards the fan must be in the 5cm diameter, and this is a recipe for noise.
Better use oversized fan running low speed ( than smaller one running higher speed). If you do your own case with your own heatsink it can be a non issue though.
What do you call a complete 'servo control'?
Another point, a mic input is not an ADC. AD are part of mic input dedicated to be connected to a computer (the last stage of the chain) but without a preamp ( including phantom power) a mic won't be usable.
This is not included into ADC, it can be built though if you really want to, but it'll soon start to make a lot of thing to build imho. Can be part of the fun though.
About OS, windows is not worst than anything else for audio. I don't know where you heard windows is terrible but it's not true. Without going into a debate about it running a system based on Linux with commercially availlable soundcard is way more complicated and lead to instability issue than under a windows OS.
It's not impossible but not as easy. There is a reason Linux is almost non existing into pro and semi pro environnement for music recording and production ( dominated by windows/apple and where stability is the first and foremost parameter needed- hence use of Asio).
Don't take me wrong, i'm not trying to discourage you but be warned of limitations you'll encounters choosing this path.
I think you should first define your needs and from there see what would suit you the best before investing. Maybe even try on an old discarded computer...
60w is not many for a processor we agree but from the pics of your server boards the fan must be in the 5cm diameter, and this is a recipe for noise.
Better use oversized fan running low speed ( than smaller one running higher speed). If you do your own case with your own heatsink it can be a non issue though.
What do you call a complete 'servo control'?
Another point, a mic input is not an ADC. AD are part of mic input dedicated to be connected to a computer (the last stage of the chain) but without a preamp ( including phantom power) a mic won't be usable.
This is not included into ADC, it can be built though if you really want to, but it'll soon start to make a lot of thing to build imho. Can be part of the fun though.
About OS, windows is not worst than anything else for audio. I don't know where you heard windows is terrible but it's not true. Without going into a debate about it running a system based on Linux with commercially availlable soundcard is way more complicated and lead to instability issue than under a windows OS.
It's not impossible but not as easy. There is a reason Linux is almost non existing into pro and semi pro environnement for music recording and production ( dominated by windows/apple and where stability is the first and foremost parameter needed- hence use of Asio).
Don't take me wrong, i'm not trying to discourage you but be warned of limitations you'll encounters choosing this path.
Last edited:
That's the plan 🤓I've been looking around for something with the same hole placement. Worse comes to worse I'll just get the material myself and find a place that can CNC it.
DSP>DAC>Amp/Speakers>ADC>DSP. (seems the audio community likes to call it servo control because of it's similarity to manipulating servos in mechanical systems for more precise movement)
I guess that brings up a good question: if sampling right from the speaker output, do I need one? I suppose through the air measurements definitely couldn't hurt anything.
That's what I'm doing! Lol. A big part of why I picked the board I did was because it has an arduino interface and a good amount of I/O for its size.
From personal experience (and from a little bit of IT experience) windows is a much better OS for general purpose. Biggest issue with it though, and why it would not be a good idea for this build, is all the bloat that come with, as well as all the background tasking. Additionally, I'm not treating this so much as "aduio analysis" as much as "small signal analysis". Music is still a sine wave.
It hasn't been easy so far either lol. Honestly, I actually am having fun with it. It's cool when I can find a hobby where I know a lot about it, but there's so much more that I don't. Makes the journey more exciting I guess.
You want to implement servo into loudspeaker through dsp that's it?
Same kind as the one used by Meyer in their X10 monitors?
https://www.soundonsound.com/reviews/meyer-sound-x10
If that is the case you'll have to implement it by yourself, as far as i know Camilla doesn't give the opportunity to do that ( as any dsp i know of - maybe except for some very specific systems in P.A with amplifier monitoring in real time to 'protect' them against abuse ( Powersoft gear)).
And you'll face issues with drivers as 'sampling right from the speaker output' is not an easy task ( i suppose you think about using speakers electric terminal as you worded things). If you read the linked article about X10 you'll see they used something different than electrical sensing... and for good reason.
Anyway it's an interesting way to apprehend things and can be very effective but it's not an easy path. And not something i know of implemented digitally ( using dsp)...
The X10 is an example, Phillips had loudspeakers like that in the 70's/80's too ( mfb serie), Velodyne did it in the 00's for their subs, Danley used the tech too iirc ( maybe for Velodyne? I can't remember...) and i could link to another successfull diy project using this technology if you want ( but in french), but it's not something easy ( either to implement or even understand from an electronical pov).
May i ask how you understand how dsp works? Your view of the main principle behind them as it seems to me you don't get the limitations of the tech as it exist as for now ( but i might have missed evolution in last years though).
About your view of windows and linux ok. It goes against what i see for 30years into proworld ( we usually 'optimise' our computers to not be bothered by all you listed but here again i'm not a specialist of it ( i'm not a computer engineer, just the end user using it to do my sound engineer duty ).
Same kind as the one used by Meyer in their X10 monitors?
https://www.soundonsound.com/reviews/meyer-sound-x10
If that is the case you'll have to implement it by yourself, as far as i know Camilla doesn't give the opportunity to do that ( as any dsp i know of - maybe except for some very specific systems in P.A with amplifier monitoring in real time to 'protect' them against abuse ( Powersoft gear)).
And you'll face issues with drivers as 'sampling right from the speaker output' is not an easy task ( i suppose you think about using speakers electric terminal as you worded things). If you read the linked article about X10 you'll see they used something different than electrical sensing... and for good reason.
Anyway it's an interesting way to apprehend things and can be very effective but it's not an easy path. And not something i know of implemented digitally ( using dsp)...
The X10 is an example, Phillips had loudspeakers like that in the 70's/80's too ( mfb serie), Velodyne did it in the 00's for their subs, Danley used the tech too iirc ( maybe for Velodyne? I can't remember...) and i could link to another successfull diy project using this technology if you want ( but in french), but it's not something easy ( either to implement or even understand from an electronical pov).
May i ask how you understand how dsp works? Your view of the main principle behind them as it seems to me you don't get the limitations of the tech as it exist as for now ( but i might have missed evolution in last years though).
About your view of windows and linux ok. It goes against what i see for 30years into proworld ( we usually 'optimise' our computers to not be bothered by all you listed but here again i'm not a specialist of it ( i'm not a computer engineer, just the end user using it to do my sound engineer duty ).
Last edited:
Not literally a servo. It has more to do with the technique in mind I want to use (https://www.analog.com/en/technical...ng-a-highspeed-simultaneous-sampling-adc.html) It's funny: I'm not looking at this from an audio point of view. I'm looking at it as a guy who has worked on a lot of different kinds of tech, to include ones that do a lot of wave shaping. As far as the power of compute, yes I do believe this is very doable. It will not be easy. But nothing ever worth doing (for the most part) is easy.
What I meant to say: Windows, for general use, as well as macOS, are just fine for music production. Those programs interact well with the OS because, as you said, stability is first and foremost. Not only that, mac and windows also have a lot of driver support for much more equipment. Linux on the other hand is a far more flexible OS. It really isn't used for music production whatsoever (at least as far as i know). In addition to having so many kinds of it, there's also a lot of versions of it that are better for server workloads like networking, mass storage, AI learning, etc. It's much harder to use windows for that because of how restrictive it is in its architecture. Typically, even windows server isn't used for critical workloads. I only see it as a way to manage things like workplace networks (hypervisor, virtualization, etc) So, no, I would not use Linux for music production. Small signal analysis? Much better choice.
I was actually thinking about implementing MFB into my design. While working on it, it occurred to me that, while a good technique, I'm pretty sure I can get the same desired effect through compute alone. That said, I went with another person's advice and decided to go with PRs instead (can't do MFB with PRs. it's one or the other).
I will be upfront: I don't know all the ins and outs of DSP itself. However, I do know computers. I also know how they can be implemented to do all sorts of things because of their processor architecture. It really all comes down to a matter of "throw enough compute at something" and how you design whatever your working on to work in tandem with it.
Ah ok I apologize. Again, I'm coming from the tech sector, not the music. I may not understand some of the finer points from that side of things.
What I meant to say: Windows, for general use, as well as macOS, are just fine for music production. Those programs interact well with the OS because, as you said, stability is first and foremost. Not only that, mac and windows also have a lot of driver support for much more equipment. Linux on the other hand is a far more flexible OS. It really isn't used for music production whatsoever (at least as far as i know). In addition to having so many kinds of it, there's also a lot of versions of it that are better for server workloads like networking, mass storage, AI learning, etc. It's much harder to use windows for that because of how restrictive it is in its architecture. Typically, even windows server isn't used for critical workloads. I only see it as a way to manage things like workplace networks (hypervisor, virtualization, etc) So, no, I would not use Linux for music production. Small signal analysis? Much better choice.
Hi,
No needs to apologize and i find better to be upfront in general, it helps understanding what peoples want to do and how advanced they are regarding their will and knowledge. It's easier to help this way.
PR for passive radiators? Hmm. It is one option amongst many. It have pro and cons and if i were you i would not choose an option only on theorical background of view of brain: prototype is a very important point in general and even more with loudspeakers. It will give you an idea of what to expect and the drawbacks ( there is always drawbacks... and the point is to know if you can accept them or no in real life imho).
But back to MFB technology for a moment: do you understand the limitations you'll encounter with drivers? Like what piston range is and what membrane breakup is and what it implies from an acoustic pov?
If you want to implement an mfb derivative this are important point to understand ( as overall limitations in general too anyway). The main point to get is in that kind of implementation you talk about a system and parts cannot be seen in isolation: 'treatment' ( either analog - electronic- or dsp), amplifier and loudspeaker is one system and you cannot develop one without taking into account the others. And i would include the room into the equation too ( loudspeaker/room as a couple), but it might be too much for now...
Well i'm sure you see the point.
You'll have to study more than the electronic implementation, software coding, electroacoustic behaviour of loudspeakers, etc,etc,...
One last thing about MFB being mimiced thanks to regular 'treatments' is not really true. You can reach same kind of results from a frequency response pov ( eg search about what a Linkwitz Transform is) but as dsp treatments are not implemented within a closed loop there will be difference regarding distortion results wrt mfb. Every choice is a tradeoff in loudspeaker design and there is no free lunch ( or very few) and what you gain one way you'll loose another. Such is loudspeaker design.
As well some points are more important than others and those are not nescessarely the ones most talked about over forums. The overall 'acoustic design' choice you'll make have much more importance regarding end results that some other technical choices imho. Why prototyping is important to understand the choice you make and if they suits your will...
Ok i will stop here as i don't wan't to give you the feeling i'm patronising on you, this is not my intention at all and i find your way to approach things interesting so don't wan't to bias you either.
I'll keep an eye on your progress as i'm sure you can have great results through your approach!
No needs to apologize and i find better to be upfront in general, it helps understanding what peoples want to do and how advanced they are regarding their will and knowledge. It's easier to help this way.
PR for passive radiators? Hmm. It is one option amongst many. It have pro and cons and if i were you i would not choose an option only on theorical background of view of brain: prototype is a very important point in general and even more with loudspeakers. It will give you an idea of what to expect and the drawbacks ( there is always drawbacks... and the point is to know if you can accept them or no in real life imho).
But back to MFB technology for a moment: do you understand the limitations you'll encounter with drivers? Like what piston range is and what membrane breakup is and what it implies from an acoustic pov?
If you want to implement an mfb derivative this are important point to understand ( as overall limitations in general too anyway). The main point to get is in that kind of implementation you talk about a system and parts cannot be seen in isolation: 'treatment' ( either analog - electronic- or dsp), amplifier and loudspeaker is one system and you cannot develop one without taking into account the others. And i would include the room into the equation too ( loudspeaker/room as a couple), but it might be too much for now...
Well i'm sure you see the point.
You'll have to study more than the electronic implementation, software coding, electroacoustic behaviour of loudspeakers, etc,etc,...
One last thing about MFB being mimiced thanks to regular 'treatments' is not really true. You can reach same kind of results from a frequency response pov ( eg search about what a Linkwitz Transform is) but as dsp treatments are not implemented within a closed loop there will be difference regarding distortion results wrt mfb. Every choice is a tradeoff in loudspeaker design and there is no free lunch ( or very few) and what you gain one way you'll loose another. Such is loudspeaker design.
As well some points are more important than others and those are not nescessarely the ones most talked about over forums. The overall 'acoustic design' choice you'll make have much more importance regarding end results that some other technical choices imho. Why prototyping is important to understand the choice you make and if they suits your will...
Ok i will stop here as i don't wan't to give you the feeling i'm patronising on you, this is not my intention at all and i find your way to approach things interesting so don't wan't to bias you either.
I'll keep an eye on your progress as i'm sure you can have great results through your approach!
Thank you 🙂
Definitely will build a test rig. It's one thing to math it out. It's a complete other for reality to effect it.
Right. The intent however is a closed loop. The plan is to step down the signal from the speaker to a usable level, then put it through the DSP for post processing and then fire it back out the DACs. That being said: the decision to do MFB may be a moot point since I will be using post processing as well as the initial use of DSP. If the results I get from post processing outweigh the results of a MFB speaker, then I'll probably just stick with DSP.
Not at all! Looking forward to giving you good news!