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. > I don't fear any problem if we have to wait a bit. OTOH, I've already > explained that I'm not comfortable with some bits of your patch, and if I > would change it slightly before applying, in addition to fix the MSVC > compiler problems. Don't worry about that, I'm happy taking care of this > issue. In the meantime I've set up my own branch at https://code.launchpad.net/~diwic/+junk/fluidsynth ...to be able to work with other areas of fluidsynth without getting into problems when generating diffs etc. Btw, if you have a look at rev 146, it should fix the things I recognized causing problems in MSVC, but I'm not sure if all of the other errors were caused by the compiler being confused or if I missed something. >>> 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. > My plan is to replace the Windows timer implementation by the multimedia > timer > in that platform, and add the ALSA timers in Linux. I'm not familiar with ALSA timers; but from what I know of multimedia timers, that won't solve the "drunk drummer problem". Let's assume for simplicity that we have a really fast computer, output to file, sample rate is 44100Hz, and period-size is 4410, that is, 10 periods per second. Then the file audio driver will, ten times per second, make 4410/64 = 69 calls to fluid_synth_one_block without any delay inbetween. It does not matter how fantastic millisecond precision your timing is in the midi player/sequencer - you won't be able to insert anything in between the ten times per second anyway (unless you use the sample timer notification feature). // David _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
