fluid-dev
[Top][All Lists]
Advanced

[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






reply via email to

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