Quoting David Henningsson <[email protected]>:
[email protected] skrev:
Hello David,
I was looking at that bug that I mentioned before, where FluidSynth gets
stuck in fluid_player_join() when doing fast file render and the
renderer fails to be created (because of invalid format settings for
example). I notice that in fluid_player_join() it waits for
player->status to not be FLUID_PLAYER_PLAYING, in the case of using the
sample timer. This will never happen though, since the player is not in
a separate thread and therefore is not advancing. Shouldn't
fluid_player_join just do nothing in the case of using the sample_timer?
Good question; in the sample timer case it is the audio thread that
processes midi and so it should advance as long as the audio thread is
running.
In the case of fast rendering, where we do not have an audio thread, I
would say that we should not call fluid_player_join at all.
Suggest that we make (adriver != NULL) or at least (!fast_render) a
condition for calling fluid_player_join in fluidsynth.c.
Sounds good. If you see an elegant way to do this, or even
un-elegant, do implement it ;)
- Added new functions fluid_settings_foreach_alpha,
fluid_settings_foreach_option_alpha and fluid_settings_option_count.
Does it make any sense to keep the non-alphabetical versions?
I had thought the same thing. There is additional overhead and memory
allocation that occurs with the alphabetical versions, which is why I
opted to keep them. Another reason is that if we were to not have
separate functions and just make the current ones alphabetically
sorted, then users of those functions might come to expect them to be
alphabetical, and be surprised when a user uses an older version of
FluidSynth. I don't think it would take much to convince me to just
modify the original ones though, especially since those functions
likely wont get used in performance critical code.
Do let me know if you think things should be done differently.
Count on it :-)
// David
Great! Glad to have you around :)
Josh
_______________________________________________
fluid-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/fluid-dev
