[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] One output per channel

From: Josh Green
Subject: Re: [fluid-dev] One output per channel
Date: Wed, 28 Jan 2009 22:43:36 -0800

On Wed, 2009-01-28 at 22:37 +0100, Bernat Arlandis i Mañó wrote:
> What do you think about fixing ticket #21 for 1.09? Without this, 
> multi-channel output cannot be enabled from QSynth.

I'm looking at this now.  I must admit, I've never quite figured out why
there are 2 sets of drivers (driver and driver2 from here on), except
for allowing for the possibility of an audio callback function so that
other applications can intercept the audio.  It looks like it allows for
audio input ports as well, which are fed to this callback.

Looking at the two Jack new() functions though, it seems like they
should be merged (or at least have as much of the same functionality
that makes sense).  Its a bit confusing to me still since I see the

driver uses synth.audio-channels while driver2 uses
audio.output-channels to set the number of output channels

driver seems to create 2 * synth.audio-channels Jack ports, whereas
driver2 just creates the requested number of audio.output-channels

driver2 allows for input Jack ports (who uses these?  I don't think
FluidSynth does).

FX ports are used with driver but not with driver2.  I'm not even sure
what these are actually, can anyone enlighten me?

driver supports LASH, driver2 does not.

It looks like a pain to make sense of this stuff.  I don't really use
these features myself, so I'm a little at a loss to figure out how to do
it right.  I think the whole driver system needs a good overhaul for

Rather than try to do it right for 1.0.9, seems like we should just get
things working for QSynth and multi-channel audio.  Does it work if you
set audio.output-channels instead?

> Also, I've fixed the reverb and chorus effects in multichannel mode so 
> they're applied to every channel, instead of mixing the effects separately.


> I'm thinking about starting the new branch and commit these changes 
> there so you can review them in case you consider merging them to the trunk.

Seems like a good candidate for the branch.  I don't want to break 1.0.9
by putting in stuff that should get more testing before inclusion.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]