[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [fluid-dev] FluidSynth sequencer test
From: |
Josh Green |
Subject: |
Re: [fluid-dev] FluidSynth sequencer test |
Date: |
Sun, 19 Apr 2009 18:33:53 -0700 |
Hello David,
On Sat, 2009-04-04 at 20:55 +0200, David Henningsson wrote:
> Pedro Lopez-Cabanillas skrev:
> > David Henningsson wrote:
> >> Pedro Lopez-Cabanillas skrev:
>
> > It is something that only Josh can
> > do, and he is not answering mails right now.
>
> That is a problem.
>
By all means, commit your patch :) Let me know if you have any trouble
doing so. It sounds like the right solution to me and we can iron any
issues out as they come up.
> >>> I also would like to test an
> >>> additional approach, overhauling the current wall clock implementation.
> >> Okay, can you elaborate on what changes that would be and if/how they
> >> will work with faster-than-realtime rendering?
> >
> > Faster than realtime has no sense for the sequencer. It has sense, though,
> > if
> > the sequencer is driven by a slave timer, like the one you have
> > implemented.
> > This design is already inside (for instance) the ALSA sequencer, which
> > allows
> > several timer sources: slave timers linked to the PCM streams, and wall
> > clock
> > timers using the RTC, HPET and System devices. There is some documentation
> > about that: http://www.alsa-project.org/~frank/alsa-sequencer/node5.html
> >
> > The user should be able to choose between wall clock and slave timer, the
> > same
> > option for the sequencer and the MIDI player.
>
> As stated earlier, we disagree on this. I can see the use for having
> other timers than the sample timer (especially after having read about
> the ALSA sequencer), but if the wall clock implementation has
> concurrency problems, it's broken. To fix that, it would be better to
> use the sample timer feature in the synth just to get notification at
> the right time, but then try to figure out a better value for the msec
> parameter.
>
Please excuse my lack of knowledge on the current issues. When you
refer to the concurrency issues with the FluidSynth sequencer and synth,
are you referring to an existing multi-threading issue which could cause
a crash or unexpected behavior due to a lack of a mutex or are you
referring to the limitation that MIDI events can only be processed every
FluidSynth buffer size?
Best regards,
Josh