Gathering requirements for new DSP plugin - please be realistic!

[scala]

(In fact, the whole transcoding chain would badly need a full overhaul in LMS, but I don’t think you are willing to embark also into this...)

[scala]

About automatic calculation of pre-amp. Inguz uses a -12 dB attenuation (if I remember well) before applying filters, to avoid clipping. I use only attenuating IIR filters and from my experimentations with sox, even in this case -3 dB are needed before applying equalization to avoid clipping (too much music is mastered at 0 dB FS these days). My understanding is that even with attenuating equalization (and sox uses standard IIR filters such as described in https://webaudio.github.io/Audio-EQ-...-cookbook.html which are the same as in CamillaDSP and should not have any overshoot) there might be rounding errors of +/- half a bit in the calculation, and that’s equivalent to 3dB (10*Log 2 actually). This is what I think is the minimum numerically needed pre-amp, plus any extra attenuation equivalent to any emphasis in the equalization. I believe this would be the same for CamillaDSP to avoid clipping. Implementing such flexible automatic preamp should work for IIR equalization, however I do not see how to automatically know the pre-amp needed in case one applies FIR impulse equalization: perhaps the author of CamillaDSP may help you here.

[daumar]

I have the need to adapt my players individually in regards to equi . i have few players in an open space (living zone with sub/tops and kitchden zone with jpl one etc. so ability to adjust per player would be wonderful!

[artatgray]

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...

Sorry, but no. Server-side DSP is essential for many of us as most network players don't provide DSP, nor do they the ability to run it since many of them are running closed source operating systems.

If you look carefully at how it's structured now, you'll see that InguzEQ is able to provide an independent DSP profile on a per player basis. As a matter of fact, if one looks in the upper right hand corner of the InguzEQ configuration panel one will notice the MAC address of the player being dealt with at the time.

Ex. I've got profiles assigned to 3 of my players that perform Speaker/Room Correction EQ and Loudness Compensation. However, for my 3 other players Speaker/Room Correction EQ isn't required but Loudness Compensation is. This isn't a problem for InguzEQ since the settings for each profile are stored based upon the MAC address of the player it's assigned to.

All the best.. 😎

[foxesden]

Happy New Year - Just to give an update. I have started work on this and I after a lot of experimentation and discussion with Henrik (the developer of CamillaDSP) I have written a wrapper application around CamillaDSP. This allows me to retain some of the features of Inguz, such as dynamic resampling of the filters and also to ensure that CamillaDSP is configured for the correct sample rate as well as maintaining limited integration with LMS CLI and auto-detecting configuration changes. I haven't done anything in the last 3 weeks, but should be restarting soon.

My first target is to replace Inguz Plugin and I will then add the additional features being discussed. Progress is quite slow as there is a lot of different languages and technology to integrate and it is easy to break everything, so I am constantly testing.

[papaiannis]

It would be really great to have the parametric equalizer and DRC on LMS. Nowadays there is a strong need for that. I use CamillaDSP on a rpi4/picoreplayer and I am happy with it. Unfortunately, CamillaDSP cannot be installed on all my other players.
If of any help, I could make my extensive c language programming experience available to the project.

[Apesbrain]

Happy New Year - Just to give an update.

Great news! Consider allowing EQ "pre-amp" gain to be set on a "per-player" basis. A combination of EQ settings for one player (room) might be fine, while different settings on another player (room) drive that signal into clipping. With InguzEQ having only one gain setting, one must set gain to the lowest value that avoids clipping on any player.

[foxesden]

It would be really great to have the parametric equalizer and DRC on LMS. Nowadays there is a strong need for that. I use CamillaDSP on a rpi4/picoreplayer and I am happy with it. Unfortunately, CamillaDSP cannot be installed on all my other players.
If of any help, I could make my extensive c language programming experience available to the project.

Thanks for the offer! The main technical issue is that the original plugin was trying to do so much and has logic split across Javascript, Perl and C# as well as some Squeezebox CLI stuff thrown in. For example there is code to run a signal generator via the player; run the DSP menu in Jive and to do ambisonics. I am stripping everything back to the bare-bones. I have cracked the majority of the c# code I need for an initial version and am now back working on the perl script and will then move over to Javascript.
Still a lot to do though!

[foxesden]

Great news! Consider allowing EQ "pre-amp" gain to be set on a "per-player" basis. A combination of EQ settings for one player (room) might be fine, while different settings on another player (room) drive that signal into clipping. With InguzEQ having only one gain setting, one must set gain to the lowest value that avoids clipping on any player.

I am including a per player gain in the initial release, although at some stage I will need to add some sort of predictive clipping validation if such a thing exists.

[charleski]

This sounds very interesting. Sorry to add to the load, but one thing that's very important for me is gapless playback (I listen to a lot of opera). I switched to LMS purely because it has robust gapless for aac using faad. Unfortunately my first attempt at doing EQ on the server side using custom_convert.conf ended up breaking gapless playback, probably because it introduces a bit of inter-track latency, so I switched to CamillaDSP on Squeezelite, which works fine. It would be essential for me that any server side solution maintained a seamless transition between tracks with the same samplerate, I don't know hard that will be to implement.

[Zombie]

This sounds very interesting. Sorry to add to the load, but one thing that's very important for me is gapless playback (I listen to a lot of opera). I switched to LMS purely because it has robust gapless for aac using faad. Unfortunately my first attempt at doing EQ on the server side using custom_convert.conf ended up breaking gapless playback, probably because it introduces a bit of inter-track latency, so I switched to CamillaDSP on Squeezelite, which works fine. It would be essential for me that any server side solution maintained a seamless transition between tracks with the same samplerate, I don't know hard that will be to implement.

What would be the advantage of using SOX instead of uploading a convolution file to Inguz?

[foxesden]

This sounds very interesting. Sorry to add to the load, but one thing that's very important for me is gapless playback (I listen to a lot of opera). I switched to LMS purely because it has robust gapless for aac using faad. Unfortunately my first attempt at doing EQ on the server side using custom_convert.conf ended up breaking gapless playback, probably because it introduces a bit of inter-track latency, so I switched to CamillaDSP on Squeezelite, which works fine. It would be essential for me that any server side solution maintained a seamless transition between tracks with the same samplerate, I don't know hard that will be to implement.

Gapless is given as a requirement. Incidentally if you enable cross-fade you will break gapless and crossfade seems to do even more damage when used with a server side DSP processor.

[Update] - My testing vs Gapless streams is currently failing as there is a slight glitch. This is likely to set me back quite a bit.

[foxesden]

What would be the advantage of using SOX instead of uploading a convolution file to Inguz?

SOX has a number of advantages

The binary is usually pre-installed and is small and fast
Most of the DSP filters that you would want are already implemented.

The downside is that it is tricky to manage the configuration so if you have a lot of players or like to tweak it is a pain
The FIR engine is mono by default ( and I have an uneven room response so this doesn't work for me), plus it can be tricky to convert FIR filters to the Raw format used by Sox. I was considering writing a wrapped for sox to address some of these challenges, but decided to use CamillaDSP instead. Just a different set of compromises really,

[foxesden]

Some further updates. I have built a limited functionality solution, which effectively wraps CamillaDSP within a plugin, and have been running this within my LMS test setup.

I have preamp gain, balance, loudness, delay (ms) and basic (peaking) parametric EQ (adjustable frequencies, fain and Q) all working. Processing all works up to 192/24 rates ( I haven't tested higher than this).

I have also had partial success with the convolution filter and with dynamic updates (i.e. updates on the control interface immediately changing settings). However -

1. The convolution filter breaks the gapless stream; as there is a dropout proportionate to the impulse size; and also there is an increase in volume as the impulse sample rate increases. I can probably work around the last problem, but not the gapless issue. Which means I am going to revert to doing the convolution "the old way", as it meets most people's needs.
2. Although dynamic updating works correctly from a technical standpoint, it will not do what people expect. This is because the audio pipeline is processed as rapidly as possible and the output is sent to the player to consume at the correct rate, so although it seems as though processing is done in real-time it is not, this means that a control update would likely happen after the file has been processed, but before the output has been played. Which all means that dynamic updates will not be possible. NB I have asked on the developers forum whether it is possible to "slow down" the pipeline, but this would probably have many downsides.

[boomboxx]

I have preamp gain, balance, loudness, delay (ms) and basic (peaking) parametric EQ (adjustable frequencies, fain and Q) all working. Processing all works up to 192/24 rates ( I haven't tested higher than this).

If just this gets released, I will be 99% happy. Actually 100% because its always amazing people that go out of their way to help the community in a project like this. Really appreciate the work you are doing.