Realtime Updates to Audio pipeline

[foxesden]

I have started integration testing my new DSP plugin and I am slowly fixing issues as I find them. One thing that I have noticed, is that any updates for example a change in pre-amp settings, happens in semi-realtime when I am running my test harness, but when I am running in the LMS environment the pipeline runs really quickly and will often have processing the song well before the song has finished. This gives the impression that the change made hasn't stuck ( it actually will be used when the next song is played). I assume that the stream is being buffered into a temporary file and handed off to the client from there, hence in most cases it makes sense to process everything as quickly as possible.
I know that many users find this confusing (had comments on InguzDSP, which behaves similarly) as they are seeing the app similarly to a client application, so was wondering whether there are any settings that can be used to process on a more "realtime basis".

[foxesden]

Assuming that the lack of responses means that this is either not doable or a stupid question. So happy to close it.

[bpa]

I think it is possible but best done in your plugin..

LMS uses pipes to buffer usually 32kbytes chunks from source (e.g. files, stream, trasncode outout) to send to output pipe to player.

You should slow the input and/or output side of your plugin to process at playback speed do not read/process all of source at once. You may hvae the side effect of rebuffering if something happens and there is not enugh data for the player

In effect treat the input strream like a input live stream (or make your plugin output look like a live stream) - where only a limited number of bytes are available every seconds.

[foxesden]

Thanks for that, I noticed that when I pipe the output directly to hardware I am getting numerous audio glitches that I don't get when I stream via the LMS Pipeline, so I think I would probably get similar issues if I tried to control the speed of the convolver process. I have been down so many dead ends and rabbit holes lately that I am happy to pass on this one.

[bpa]

Thanks for that, I noticed that when I pipe the output directly to hardware I am getting numerous audio glitches that I don't get when I stream via the LMS Pipeline, so I think I would probably get similar issues if I tried to control the speed of the convolver process. I have been down so many dead ends and rabbit holes lately that I am happy to pass on this one.

I don't know where your main DSP work is happening (e.g. player or LMS) but glitches (as opposed to buffering) are generally a player issue and not an LMS one - I suspect some player settings (e.g. ALSA settings) may be more critical.
Sending data unmanaged into a pipe often ends up with a lumpy stream - some sort of flow control is usually needed.

That said it is generally better to spend as much free time listening rather than developing a "nice" feature that does not affect enjoyment most of the time.

[marcoc1712]

Is the way LMS it works. It sends as many (transcoded) data to the client as it can receive in its buffer, up to the end of the second song in the playlist after the current.

[foxesden]

Is the way LMS it works. It sends as many (transcoded) data to the client as it can receive in its buffer, up to the end of the second song in the playlist after the current.

Thanks for the info. fortunately I realised that my original approach wasn't going to work so I haven't wasted any time on it.

Incidentally I see on your C3P0 plugin that you have managed to bypass all the default transcoding paths for an enabled player, are you rebuilding the command table to do that?