Using within a LMS plugin

[Foxenfurter]

Hi - I am maintaining a plugin for Logitech Media Server that adds DSP via an old c# programme called Inguz. I am thinking of starting work on a new plugin using CamillaDSP, and have configured up a basic audio chain that will work. As far as the pipeline goes there appear to be a few differences and I would be interested in your thoughts on this.

In Inguz the frequency rate (e.g. 44.1k) is maintained from source through the pipeline and if using a a wav file as a FIR filter the filter is resampled to a matching rate. This is done quite bluntly by detecting the sample rate of the stream and then spawning out a sox call to resample the filter and this is used instead of the defined filter.

So my question is whether Camilla

1. Allows sample rates to be passed through from STDIN to STDOUT without being changed
2. Can process FIR filters irrespective of the stream sample rate.

I am pretty confident I can resample everything in the stream to a rate set for each player by the user, so I can live without the above, but I want to be clear about this in my own documentation.

[HEnquist]

1) Unless the resampler is enabled, then CamillaDSP will keep the sample rate of the source all the way through. It just needs to be told what the rate is. That can be done either via the config file or via the override command line parameter.

There is no automatic resampling of the impulse response for FIR filters. What can be done is to keep several versions of the wav, one for each sample rate. If they are named like filter44100.wav, filter48000.wav etc, then CamillaDSP can pick the one that fits. I have thought a little about automatic resampling of the IRs, but haven't decided if I want to implement it or not. Maybe at some point in the future.

[Foxenfurter]

Thanks for the reply. So if I were to save different copies of the filters for each rate is there anyway to detect the inbound-rate and choose the appropriate filter within CamillaDSP or would I need to do that externally?

[Foxenfurter]

Oh full disclosure, if build a plugin I would want to include copies of the binaries in the installer zip, I really want to make the install as easy as possible and this is the conventional approach for LMS plugins. But obviously I don't want to do anything that would bother you in anyway. Also let me know if there is any branding etc that you would like me to include. I am not certain to proceed yet, but want to be above board and transparent about all this.

NB I am not selling a product, just doing this as a hobbyist although I am currently working in the software engineering industry but in finance ( yawn).

[HEnquist]

Thanks for the reply. So if I were to save different copies of the filters for each rate is there anyway to detect the inbound-rate and choose the appropriate filter within CamillaDSP or would I need to do that externally?

The rate should be known before launching the camilladsp process. I have no idea how LMS plugins work, are they informed about the sample rate, sample format etc of the file being played?

[HEnquist]

Oh full disclosure, if build a plugin I would want to include copies of the binaries in the installer zip, I really want to make the install as easy as possible and this is the conventional approach for LMS plugins. But obviously I don't want to do anything that would bother you in anyway. Also let me know if there is any branding etc that you would like me to include. I am not certain to proceed yet, but want to be above board and transparent about all this.

What license would you use for the plugin? If it's open source (and especially GPL) there is no issue. But if it's closed source, then we end up with the question of what is considered derived work. Boooring! Please go for open source :)

[Foxenfurter]

It will be GPL open source, as is the current plugin. In LMS a plugin is really just a perl wrapper for any code that you write with hooks that integrate into the LMS API which is called CLI. It would be much easier (for me) if it was python based, but it is quite old and it works quite well. The plugins themselves just add functionality to the base server.

In this use-case the server (via a bunch of other plugins) handles the streaming side of things and then hands work off to a server side conversion pipeline, which is setup as a template in a configuration file. The template holds a set of transcoding records per player which might, for example, be to read a flac stream pipe it into sox for upsampling and standardisation to 24 bit and then pipe back to flac for the onwards transmission to the player.

My plugin builds these pipeline templates and allows the user to manage the settings for the DSPEngine via a web interface. The LMS CLI interface allows menu options to be added to the original Squeezebox players with touch screens or the software emulators. But this interface is a bit clunky other than for choosing pre-sets, so I prefer to spend time on the web interface.

The clients will be registered with the formats that they accept and then either a 16 bit ore 24 bit template is used based of capability. The server tells the pipeline for example flac stream or ogg stream coming so that the correct initial decoder route is chosen, but it has no idea of the payload within the container.

sox has a switch for reporting the characteristics of a stream, and Inguz has some code that sniffs the first audio block and decides what it has got. If it can't handle it then it just passes the stream on un-adulterated and if it is a different rate to the chosen filter then it will attempt to pick a filter of the same name with the rate prefixed. e.g. 88200_00F12EE86F_Impulses_Cavern4Iloud.wav If this file doesn't exist it will shell out to sox to create one.

I agree with you that it would be relatively simple to pre-generate a range of supported filters, and it would be cool if camillaDSP could select the correct one and then handle appropriately (skip the step with a warning logged?) if it cannot oblige.

[HEnquist]

Ok if it's GPL then there are no issues at all.

CamillaDSP only handles raw data for both input and output. There is no handling of file headers and such. A while ago I made a small prototype wrapper in python. It read the header from stdin, looked at it to determine the format and rate, launched camilladsp with the appropriate settings, and then hooked up its own stdin to stdin of the camilladsp process. Something like that could perhaps work here? This could also be a place to call sox to resample impulse responses as needed.

[Foxenfurter]

Yeah that might work, I think it best to do the sox impulse as a separate process as it adds unnecessary complexity to the pipeline. Anyway I have got some ideas, to play around with.

Also I know that you have a mechanism for poking CamillaDSP to load and apply a new setting immediately, does this only work when the process is running as a service, or would it work if I had a pipeline with multiple standalone instances running. i.e. poke instance 2 because the players config has changed.

[HEnquist]

Also I know that you have a mechanism for poking CamillaDSP to load and apply a new setting immediately, does this only work when the process is running as a service, or would it work if I had a pipeline with multiple standalone instances running. i.e. poke instance 2 because the players config has changed.

Yes, you just need to give each instance a unique port number. I suppose it's easy to connect to a websocket from perl.

[Foxenfurter]

Fantastic, thanks for your help. I think I am done hassling you for now ;) , really appreciate the work you have done.