DSP plugins

[doep]

Lately I haven't had much time to code, but I have had much time to
think. What I've been thinking some about is DPS plugins.
What we want in the end is a DSP plugin interface that is capable of
alot of things:
1. Altering of the output buffer (I guess this is the simple part that
most settle with).
2. Resampling. Like using Secret Rabbit Code (http://www.mega-nerd.com/
SRC/)
3. Channel modification. I.e. altering of stereo to multichannel.
4. etc etc

So, I came up with the following things for a DSP plugin to be able to
change:
1. Samplerate
2. Number of channels
3. Buffersize (length)

So this is probably not that hard. Lets just make a interface for
buffers, like a
class IBuffer{
long SampleRate();
void SetSampleRate(long sampleRate);
int Channels();
void SetChannels(int channels);
float* BufferPtr();
long Samples();
bool SetNOFSamples(long nofSamples);
}

The IDSP interface should have a method like
class IDSP{
bool RunDSP(const IBuffer *inputBuffer, IBuffer *outputBuffer);
}

This way the DSP will be able to change everything it needs to. By
default the outputBuffers settings could be the same as the
inputBuffers so that a simple DSP does only need to access the
BufferPtr.

Thinking about this some more, I realize that the exact same buffer
should be used for the decoders. The only difference is that they will
only use an outputBuffer. And the Output plugins (like waveout plugin)
should also get the same outputBuffer in the end.

Oh well... Just thought I'd share my ideas about the future :)
All comments are welcome.

Best regards
Daniel Önnerby (doep)

[Casey Langen]

I think I like where you're going with this idea. A couple questions/comments:

1. How will this affect decoder code complexity? Do the decoders already treat buffers fairly consistently? I suppose it doesn't really matter, as long as the final step of the decoding process dumps the data into an IBuffer with the correct parameters. 

2. How will this affect the output plugin complexity? What happens if a DSP plugin decides to change the number of channels, or sample rate in the middle of playback?

3. The order of the DSP plugins is important, keep this in mind. Eventually you'll need a UI to configure in which order the data will be tunneled through the plugins. Make sure to plan ahead accordingly!

Casey

[doep]

> 1. How will this affect decoder code complexity? Do the decoders already
> treat buffers fairly consistently? I suppose it doesn't really matter, as
> long as the final step of the decoding process dumps the data into an
> IBuffer with the correct parameters.
>

The decoders are basically doing this already, so there would not be
much change in them.

> 2. How will this affect the output plugin complexity? What happens if a DSP
> plugin decides to change the number of channels, or sample rate in the
> middle of playback?
>

Good question. Not sure how to handle changes like that for the
output. I guess we need to help the output plugin and make some kind
of call each time something in the format (samplerate, channels)
changes.
As the output plugins work at the moment, the format is set initialy
before the first buffer arrives. If we send a IBuffer, it could just
set the format when the first buffer arrives. If the format change and
we notice that it's too messy to fix that in the waveout plugin, we
could treat it like it's a new output, just like we start playing a
new file.

> 3. The order of the DSP plugins is important, keep this in mind. Eventually
> you'll need a UI to configure in which order the data will be tunneled
> through the plugins. Make sure to plan ahead accordingly!

Good point

>
> Casey

>
> On Sat, Nov 8, 2008 at 12:59 PM, doep <onne...@gmail.com> wrote:
>
> > Lately I haven't had much time to code, but I have had much time to
> > think. What I've been thinking some about is DPS plugins.
> > What we want in the end is a DSP plugin interface that is capable of
> > alot of things:
> > 1. Altering of the output buffer (I guess this is the simple part that
> > most settle with).
> > 2. Resampling. Like using Secret Rabbit Code (http://www.mega-nerd.com/

> > SRC/ <http://www.mega-nerd.com/SRC/>)

[doep]

Maybe we need to make a difference between the decoders buffers
anyway.
The decoders should have a buffer where you can be able to set what
kind of format it inputs. Like 8bit, 16bit, 24bit, float.
That way decoders do not need to worry about converting to float (that
is the internal format).
Once the audioengine get a buffer from a decoders it needs to pass it
through a sampleConverter that by default only convert to float (if
necessary), or it can go to a plugin like Secret Rabbit Code so that
it in the end will be a float buffer.
After that, the IBuffer will work as explained.