Hi Josh and Bernat,
The issue I fixed was for real time rendering, when using the
sequencer. And it was related, not only to standard and simpler
latency caused by the size of the driver buffer, but because of
unexpected behavior from the DSound driver, which, depending on the
target hardware and other unknown reasons, would actually request
buffers in bulk : it would request 16 buffers in a row, thus
multipiying the latency by 16. And this would not be consistent
(sometimes 1 buffer would be asked, sometimes 16). I have logs on
this. This means that audio was in a way running much ahead of real
time.
The result was that the "Sub audio buffer MIDI event processing" issue
that Josh mentions was multiplied by 16, resulting in audible
irregularities in rythms. IIRC, midi playback is also attached to the
system clock, with a timer. So this problem will also happen for midi
file playback, not only for sequencer playback. [as a side note, there
is a redundancy in code, again, IIRC, between the sequencer and the
midifile playback. This could be factored by having for example the
midifile playback use the sequencer to insert midi events in the audio
stream - end of side note]
I fixed this by branching the sequencer on the audio time (how many
samples have elapsed), _and_ by calling the sequencer routine just
before filling each audio buffer.
-> I guess that I did not fix this same issue with midifile playback
then.
-> and also, I reduced the precision to a single buffer length. I did
not address sub-buffer precision.
=> I guess this could really benefit an overall cleanup.
As for the question of where to do the processing of the scheduled
(whether through the sequencer or through the midifile playback) midi
events, I think that the only way to have consistent and reliable
rendering is indeed to do it inside the callback from the audio
driver, especially if the audio runs ahead of real time.
Le 27 janv. 09 à 03:32, Josh Green a écrit :
I probably shouldn't say too much, until I see what Antoine's solution
is.. But..
On Tue, 2009-01-27 at 03:04 +0100, Bernat Arlandis i Mañó wrote:
It makes sense to me to
process the audio based on the audio playback. This would lead to
identical playback between successive renders of a MIDI file,
which is
what we want.
This could be the only advantage I can think of, but it would be only
reproducible in the same hardware, driver and audio buffer size
setup.
If you're thinking on case testing then the only solution is non-RT
rendering.
Indeed, it seems like it is the most useful for non-RT rendering. I
think the issue that Antoine was originally trying to fix was
related to
the Windows DSound driver implementation processing a lot more data
than
just an audio buffer, which really seems like a driver issue to me.
I don't see a problem with this change and I think it
would vastly improve things. There might be a little more
overhead as
far as MIDI event processing, but it would lead to more accurate
timing
as well.
This would worsen latency since the core thread would have to do more
work at the critical point where the sound card is waiting for data.
Hmmm. Not if you are simply using the number of samples played out of
the sound card as a timing source. Or am I still overlooking
something.
It seems to me like using a system timer for MIDI file event timing
(something that has different resolutions depending on the system) is
going to be a lot less reliable than using the sound card time. Again
though, I agree that this probably only benefits MIDI file
playback/rendering.
Besides, I don't think having the MIDI file player depending on the
audio driver is good.
What about just using it as a timing source? I still haven't
thought it
all through, but I could see how this could have its advantages.
And, please, this shouldn't be taken as disrespect to Antoine's work,
I'd still have a look at it to see what he has really accomplished.
I think it's cool having this discussion now, since you're the
maintainer and you'll want to have some control in the future
development, it's logical. I'd like to know how good we work it out
when
we don't agree. :)
Cheers.
Well I'm not particularly attached to how things go, just as long as
we
do the "right thing" (TM) and KIFS (Keep It F...... Simple) ;)
Cheers.
Josh
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev
++ as
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev