[SDL] Trying to display a colored surface

Carlos citrouille at wanadoo.fr
Sun Jul 14 15:39:01 PDT 2002


--- Sam Lantinga <slouken at devolution.com> wrote:
> > On Sun, 30/06/2002 12:12:12 , Loren Osborn
> <linux_dr at yahoo.com> wrote:
> > [...]
> > >Hmm... I Just though of something that might
> greatly
> > >improve latency (if it's doable).  The program
> > >generally knows when it needs to add a new sound
> to
> > >the mix.  If at this time, would it be possible
> for
> > >the program to signal SDL of this, so that SDL
> could
> > >EXPIRE the REMAINDER of the current buffer (minus
> a
> > >few micro-seconds to allow time for the remix). 
> That
> > >way the sound mix callback (or possibly a new
> special
> > >purpose callback) would be re-called to mix the
> new
> > >sound into the sound buffer with practically zero
> > >latency.  (Sound is not my forte, so this might
> not be
> > >possible, but I it seems like a perfectly
> reasonable
> > >idea.)
> 
> > This is pretty much how "shared memory zero
> latency mixing" works, although there are more
> efficient ways to do it than to entirely ditch and
> rerender the "future" part of the buffer. (That can
> become *very* expensive...)
> 
> This is almost mutually exclusive with the current
> callback semantics
> of the SDL audio API.  It will be considered for the
> next generation SDL
> API, but won't go into the current stable code.

I'm certainly not pushing for this in the 1.2 tree,
but I see no reason for this to be mutually-exclusive
with the current callback system:

1) This is only relevant when a new sound is added to
the mix (so the rest of the time the callback system
will work fine).

2) when a new sound *IS* added to the mix, the
callback has already been called, and mixed one or
more buffers already.

3) If there was a hook in SDL to get the currently
queued sound buffers, and the current position in that
buffer-queue, all the user would have to do is
determine if there is enough time to do a remix before
the buffer-queue empties, lock the sound mutex (so the
sound callback doesn't get executed while remixing),
remix the buffer after it's current position, then
unlock the buffer...

I don't see how this is mutually exclusive with the
callback.  (Also, I think except for a few hooks, the
changes to SDL would be minimal... SDL_mixer OTOH
would probably want to change to accomidate this)

Like I said, I'm not pressing the issue.  I'm fighting
fires in the blitter code right now, so this isn't
something I consider "on my plate" so to speak... Just
an idea that I thought was cool...

Best regards,

-Loren


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com




More information about the SDL mailing list