Gathering requirements for new DSP plugin - please be realistic!

[foxesden]

Hi - I have been keeping Inguz DSP going for the last couple of years, and in doing so learnt a lot about the LMS plugin architecture. I am thinking of writing a new plugin based off CamillaDSP, but want to gauge the appetite before I get in too deep.

Inguz
Features

• 32 bit audio processing engine
• 2 to 31 frequency Equaliser using ISO standard curves
• Retains stream frequency rate through the pipeline and will match bit depth to player (16 bit / 24 bit)
• Channel Delay; Matrix Impulses (Think specialisation); Balance; Filter Limits; and Loudness (perversely called quietness)
• FIR Convolution Engine
• Cross platform using .net Core 6

Downside

• binary size approx 30 MB
• relatively processor intensive e.g. spikes every 10 seconds @ 2 - 25% CPU depending on processor.
• designed to process 2 channel audio only
• Feature locked - I consider it feature locked as I am not considering writing enhancements to the core engine.

I can add usability features to the UI, but the capability of the processing engine are not going to change.

In contrast Camilla DSP

• 64 bit audio processing engine
• Configurable parametric EQ, which could also be setup as 2 to 31 frequency Equaliser using ISO standard curves
• Almost every conceivable filter type and processing is possible
• FIR Convolution Engine
• Cross platform using pre-compiled Rust
• binary size approx 3 MB
• processing is as fast (low cpu usage) as you are going to get
• Has it's own python and web based UI
• multi-channel

Downside

• Would need to be at fixed sample rate across the pipeline
• Almost every conceivable filter type and processing is possible, which may be unmanageable and I haven't checked everything!
• multi-channel

The plugin will
Setup the audio pipeline
install the binaries appropriately
create folders for saving configuration files

For the User Interface
I had considered writing a wrapper for CamillaDSP's own UI for now and then enabling presets based off saved YAML files, but I think the install and maintenance will be a nightmare.
So I will enable the convolution engine initially off saved wav files
Enable equaliser/parametric eq.
Simple features like delay; balance etc
2 channel only
frequency rate to be set on a per player basis.

My thinking is that this will cover 80 to 90 percent of use cases, and for anything more complex the user could import a pregenerated YAML file and use that as a preset.

Any thoughts on the above. Any burning ideas for features?

[Apesbrain]

If available, please include the "Width" function. It would be great to have the ability to easily save/load/edit/re-save "Preset" configurations.

A "CLIPPING+" warning in the UI as well as a "Pre-amp" level adjustment would be useful; maybe with an "Auto" option.

If there are log files, please provide some way of managing their size. Inguz's log can get large if not deleted from time to time.

I'm not clear on what "Would need to be at fixed sample rate across the pipeline" means. Most people, I think, expect a 24/192 file to arrive at their DAC as 24/192 and the same for 16/44. Is that possible? Assume any convolution WAV exists as 32-bit FP or 24-bit.

Thanks for asking.

[Zombie]

I bought the Umik1 and dnloaded REW to correct the frequency response in the room.
I don't know much about DSP (yet) and room correction, but an easy import function for correction parameters would be welcome.

[foxesden]

re importing Impulse, agreed will try and make this easy to do.

REW is a great piece of software, but a bit overwhelming at first. I got great results using Cavern EQ and this was very easy to use, and is also free. I did a write-up here https://www.audiosciencereview.com/f...-how-to.32770/

I have no connection with the Cavern guy, just found it on a wikipedia link.

[Zombie]

Corrections without delay would also be nice.
Adjust a slider and the sound changes almost immediately

Connecting a calibrated microphone activates an analysis and corrects the room after a few clicks. (Unrealistic, I know)

[foxesden]

If available, please include the "Width" function. It would be great to have the ability to easily save/load/edit/re-save "Preset" configurations.

A "CLIPPING+" warning in the UI as well as a "Pre-amp" level adjustment would be useful; maybe with an "Auto" option.

If there are log files, please provide some way of managing their size. Inguz's log can get large if not deleted from time to time.

I'm not clear on what "Would need to be at fixed sample rate across the pipeline" means. Most people, I think, expect a 24/192 file to arrive at their DAC as 24/192 and the same for 16/44. Is that possible? Assume any convolution WAV exists as 32-bit FP or 24-bit.

Thanks for asking.

If available, please include the "Width" function - if it's available it will be included.
It would be great to have the ability to easily save/load/edit/re-save "Preset" configurations - yes that should be core functionality.
If there are log files, please provide some way of managing their size. Inguz's log can get large if not deleted from time to time. - agreed.
A "CLIPPING+" warning in the UI as well as a "Pre-amp" level adjustment would be useful; maybe with an "Auto" option. I think that clipping is logged, but not sure how real-time it is. Initially you would need to check the log and adjust gain manually.

Last point, and sorry about the long answer...
I am talking with Henrik the CamillaDSP developer about how the convolution engine handles streams with different sample rates vs the impulse wav files that are stored. For example if you stream a flac file it may be 44.1k 16 bit or 192k 24 bit or may even contain a DSD or MQA file. The point being that the file get's unpacked and passed onto the next process in the stream. If this next process does not know how to handle a different rate then we will need to fix the rate say to 96k 24 bit and use that throughout. Go too high and you may break some players, go too low and people will lose resolution that they have paid for. It is relatively easy to lock the rate as I have described, and add a resample option to the UI, but I am asking Henrik if it is possible to choose an impulse file based off the incoming rate, and maybe passthrough with a warning logged if it can't handle it.

Hope that makes sense!

[foxesden]

Corrections without delay would also be nice.
Adjust a slider and the sound changes almost immediately

Connecting a calibrated microphone activates an analysis and corrects the room after a few clicks. (Unrealistic, I know)

I would like to get corrections changed without delay, but Camilla uses a different mechanism for reacting to a change in config so it won't be in the early releases.

Filter generation, although related, is a different use-case. Interestingly Inguz has all the sound generators built in and the original developer had plans to add in the DSP filter generation, but dropped it before then. To be honest the biggest faff when doing the measuring is getting quiet time to do the measuring. If you have a fanless laptop and a bluetooth connection to your amp plus a USB enabled microphone it is about as good as you can get. I suggest playing around with the workflow - but at low volume, to familiarise yourself with the process and then give it a go. I have tried about 6 different measuring systems and for me Cavern was the easiest, and gave good results. (You can import the measurements into REW too and tweak away!)

[Zombie]

Another function: separate adjustment for left and right channel

[foxesden]

Another function: separate adjustment for left and right channel

Just to be clear are you talking about EQ for separate channels or for FIR filters to work separately. Both are possible, in fact the underlying engine is multi-channel with each channel having its own definition.

But, I was planning on doing EQ with a single setting and FIR filters with separate left/right mappings (you could use the same filter for both if you want of course)

[Zombie]

I have not much knowledge about digital audio techniques, I'll have to do a "for dummies>" readup on the most important concepts for my room correction attempts.
I have correction files from REW (I think) separated for left and right, but don't know how to apply them. I read a simple explanation in a forum this year, but forgot where. That was the beginning of my interest in implementing it with LMS.

Another function would be to make the correction player-based, instead of server-based. It's logical since the LMS is a multi-room system. If it isn't already, that is...

[foxesden]

I have not much knowledge about digital audio techniques, I'll have to do a "for dummies>" readup on the most important concepts for my room correction attempts.
I have correction files from REW (I think) separated for left and right, but don't know how to apply them. I read a simple explanation in a forum this year, but forgot where. That was the beginning of my interest in implementing it with LMS.

Another function would be to make the correction player-based, instead of server-based. It's logical since the LMS is a multi-room system. If it isn't already, that is...

Well the design of LMS is that you control players centrally via the server and any controller app that you use actually talks to the server. So in order to be consistent it makes sense for any DSP to be done on the server. This way you only have one installation and one User interface to learn. Obviously theory and practice are very different, some clients (players) will be easy to add and use a equalisation tool, for others it can't be done.

I have been using Inguz DSP for a couple of years now (and I know I am potentially biased), and I also have Equalizer APO on my PC. But I only use Inguz for listening to music and switchng between headphone and speaker EQ because I don't need to leave the the User Interface. I had a flurry of activity initially when I was setting up the EQ Settings, and restarting a track to hear the effect was a slight inconvenience, but in daily use it is a non-issue.

That said, CamillaDSP does have a mechanism to trigger a settings refresh and it should be near instantaneous there is some technicalities that would be needed, and I would have to confirm that multiple quick setting changes does not cause audio glitches as this would be seriously annoying. So I will at least try to enable this feature.

NB I have no idea how long it is going to take me to get this up and running, which is why I was trying to stabilise the Inguz installer first.

[foxesden]

I have not much knowledge about digital audio techniques, I'll have to do a "for dummies>" readup on the most important concepts for my room correction attempts.
I have correction files from REW (I think) separated for left and right, but don't know how to apply them. I read a simple explanation in a forum this year, but forgot where. That was the beginning of my interest in implementing it with LMS.

Another function would be to make the correction player-based, instead of server-based. It's logical since the LMS is a multi-room system. If it isn't already, that is...

Well the design of LMS is that you control players centrally via the server and any controller app that you use actually talks to the server. So in order to be consistent it makes sense for any DSP to be done on the server. This way you only have one installation and one User interface to learn. Obviously theory and practice are very different, some clients (players) will be easy to add and use a equalisation tool, for others it can't be done.

I have been using Inguz DSP for a couple of years now (and I know I am potentially biased), and I also have Equalizer APO on my PC. But I only use Inguz for listening to music and switchng between headphone and speaker EQ because I don't need to leave the the User Interface. I had a flurry of activity initially when I was setting up the EQ Settings, and restarting a track to hear the effect was a slight inconvenience, but in daily use it is a non-issue.

That said, CamillaDSP does have a mechanism to trigger a settings refresh and it should be near instantaneous there is some technicalities that would be needed, and I would have to confirm that multiple quick setting changes does not cause audio glitches as this would be seriously annoying. So I will at least try to enable this feature.

NB I have no idea how long it is going to take me to get this up and running, which is why I was trying to stabilise the Inguz installer first.

[Gobuleberbu]

Gathering requirements for new DSP plugin - please be realistic!

Hi!

I’ve had a go recently with CamillaDSP. It seems like a really powerful piece of software. I stopped using it mainly because I couldn’t configure it to keep my different radios synced... which was a major downside for me.

Also, during my quest for sound correction/room correction, I have found multiple ways to do it, along with ressources for code that could be borrowed ! I hope it can help!

IMHO The best implementation could be one that mixes the different solutions, a mix of server side / client, depending on the capabilities of the clients.

Server side:
• Inguz
• BruteFIR-DRC
• SoX through a custom-convert rule https://forums.slimdevices.com/showt...ric-EQ-options
• C3PO (only certain file types..)
• CamillaDSP as you propose

Player side:
• With a hardware DSP (ie hifiberry’s DSP card)
• AlsaEqual (which can be configured as a parametric EQ - hifiberryoS has a beautiful UI for adjusting EQ - software DSP is possible but disabled by default https://github.com/hifiberry/hifiber...doc/alsa-eq.md)
It was tested by a forum member in PcP https://forums.slimdevices.com/showt...ing-ladspa_dsp
• SoX - it was discussed that SoX could be used as a parametric EQ, there is even pcp-sox.tcz available on PcP -although I wouldn’t know what to do to integrate it with squeezelite. It seems like some rewriting of squeezelite would be necessary as Squeezelite uses SoXr to resample.https://forums.slimdevices.com/showt...rtefacts/page3
• CamillaDSP in an audio loop- it looses sync with other players.

CamillaDSPs strength are undeniable: adaptative loudness would be very interesting, upsampling, dithering, remote configuration and the possibility to mix different outputs: high pass through the sound card to the speakers, low pass to the sub through earphone jack... it will bring LogitechMedia Server to a whole new level. Especially if we can modify the settings with hardware controls.


Envoyé de mon iPad en utilisant Tapatalk
edit: added some server side options

[boomboxx]

Hopefully this is going to be a thing. I have a huge interest in this as there is not an easy way to use dsp yet for piCorePlayer. I would love to be able to just set some basic filters (like gain, Q, frequency and to which channel) to apply to my picoreplayer. Any sort of REW integration would be amazing. I think there would be a huge interest in this if this is completed. The work done on camilladsp was great, its just a shame i cant get it to work on my picoreplayer. But with that said, if it could work like Roon does it, where I can set it in LMS and it apply to my picoreplayer, that would be incredible, though I know that could be very tricky. Even a GUI like they developed for camilladsp that would work with picoreplayer would be awesome as long as it has a repeatable easy to follow guide. Anyways, i really hope you do pursue this as I would be extremely grateful of a solution since they are very limited right now.

[scala]

First and foremost I’d like to congratulate you for reviving Inguz! And for your initiative of implementing CamillaDSP. The LMS ecosystem badly needs a solid and user-friendly tone control / equalizer / room correction system. Think of how neat equalization in Roon is, for example.
+1 for all the features already mentioned.
Another useful feature would be to allow seeking in mp3 files. Lame is used in the LMS transcoding pipe for mp3, but Lame does not allow seeking. One has to install ffmpeg which is not standard in LMS, and add special custom-convert.conf rules for ffmpeg to pipe mp3 into sox or Inguz or whatever. It would be great if you could include ffmpeg binaries (or some other adequate lame replacement) together with Camilla DSP. And corresponding transcoding rules, of course!