[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] New development

From: Josh Green
Subject: Re: [fluid-dev] New development
Date: Mon, 26 Jan 2009 18:32:40 -0800

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

> 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) ;)


reply via email to

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