Re: [fluid-dev] FluidSynth sequencer test

[David Henningsson]

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