[SDL] Glenn, I did read your responses RE: Audio consumed.

[Glenn Maynard]

On Thu, Dec 12, 2002 at 01:01:33PM -0600, Bob Pendleton wrote:
> It still seems like you are trying to use the wrong thing as your time
> base. The sound hardware has very precise timing, even though you can
> see it. And, the video timing is also fixed and precise even though you
> may not be able to see it. But, the system clock is both precise and
> visible. As long as you can get a good estimate of when the music

It can give a reasonable estimate, but it's not nearly as precise as
querying the hardware.

Asking the hardware where the play cursor is is a very basic operation--any
hardware that does DMA streaming of sounds (everything) can do it, so I
don't see any reason it shouldn't be exposed by audio APIs.  It seems
like you're saying "the portable libraries can't do it, so you're doing
something wrong".  I say that this is the most robust and accurate method,
and that the portable libraries are at fault; the system libraries expose
it, and so should the libraries that layer on top of them.  (I was fairly 
disappointed in open source when I discovered that neither STL, PortAudio
nor OpenAL did this.)

(It might be a bit harder to do this when outputting via /dev/dsp; but
on one hand, that's completely obsolete; and on another, it could--and
might, I don't know--expose the number of bytes played via an ioctl.)

> started playing you can use the current time to generate frames and to
> tell when something happens in the music. At least is seems that way to
> me.

We don't need to know when something happens; we need to know the
current position, since we're scrolling arrows with the music.  We're
not timing against specific events.

> Can people actually *do* anything so precisely that 1.5 milliseconds
> matters? 

(Do you mean 10ms?  That's the difference, here.)  No; it's just another
accumulation of error, between the sound being off, system scheduling,
not handling input until the next frame, and so on.

-- 
Glenn Maynard