[email protected] wrote:
Quoting David Henningsson <[email protected]>:
If someone is playing along with the midi track, they can't have high
latency. On the other hand, I think it is only between songs there is a
problem, the rest should not be very time-consuming.
True, hadn't really thought of that scenario. Something to attend to at
a later time.
Certainly.
Yes it will work. As far as I know, all values which can be queried
should now work, as far as appearing immediately. For all
parameters, except presets and polyphony, the value is set and
accessed atomically by all threads.
If this includes the audio thread, don't we have a problem? If the
value is being read by the audio thread after being atomically set by
the MIDI thread(s), but before the corresponding event has arrived in
the queue, things will be incosistent?
(Perhaps this is not such a big issue for the pitch bend, but there
could be another events where this problem could hurt more?)
I don't think there is an issue with this. Since the new value isn't
actually passed through the queue, the queued event is essentially just
an update request. The latest value will always be the value assigned
to the variable and the update event will ensure that the synthesis
thread uses the latest value. Events are processed at whatever interval
the fluid_synth_one_block() function is called in relation to the MIDI
events. If more than one pitch bend event occurs within a given
interval, the latest value will get used.
I can think of issues, but perhaps it is only in theory they can happen.
Imagine that we have a note sounding and a channel volume of 1, so the
note is barely audible. Then we have a volume change to 2, then a
note-off (and instant release time), then a volume change to 127. Given
a certain timing, it could happen that the volume change to 2 is never
read and 127 is read instead, so the note will sound at volume 127
instead of 2 for a very short period of time.
Well it isn't just for garbage collection now. Its also being used
to handle program changes, which should happen ASAP.
Eh? I had a look at that code and it seems to screw up fast-render and
embedded cases pretty bad, unless I'm missing something...?
Yeah, now that I think about it, it would. In the case of fast render,
program changes need to occur synchronously as part of the synthesis
process, but in the case of realtime playback it needs to happen outside
the synthesis thread. Seems to fall under the single versus multi
thread enable/disable.
We have so many use cases it is easy to fix one and break another. I
started to write something at
http://fluidsynth.resonance.org/trac/wiki/UseCases earlier today but I'm
not sure if it will be helpful; at least it is not so complete yet.
Yeah, I think something like that could be good, rather than trying
to auto detect it. A simple API function like:
void fluid_synth_multi_thread_enable(fluid_synth_t *synth, int enable);
We have two kinds of multi-threading, a) we have an audio thread or we
don't, and b) we have either one, or more than one, thread accessing
the state machine. I think we should separate those cases if we made
such an API.
I don't understand the difference between the two or what distinction
should be made. Can you clarify this a little and what this might look
like as far as API? It seems to me like there are really only 2
distinctions that we care about, single threaded (audio synthesis and
MIDI events occur synchronously and from the same thread) and
multi-threaded where MIDI events may occur in the audio thread or in
other threads.
In the wiki page I quoted above, there are three properties and some
short explanations, does it clarify things? I'm not sure how (and which
of them) we should configure via the API though.
In the case of multi-threads I wonder if there would be any use
scenarios where synthesis would be running faster than realtime.
I can't think of one currently.
Sounds good to me. So we can add an API function to set the mode. I
guess the default should be multi-threaded? That should probably be the
case to remain as backwards compatible as possible with older software
which don't yet know about the new API.
Yes.
// David
_______________________________________________
fluid-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/fluid-dev
