How do I know how much Audio Consumed under SDL_Audio API ?
Surely I’m not supposed to keep track of this myself ?
If you’re referring to runtime detection of the play cursor, I
believe SDL always double-buffers audio, so you can probably keep track
of the system time of the last buffer and figure out how long it’s been
since it was sent to figure out the difference. Ugly and hacky, but it
seems to work. (I’m not positive it works in all archs; I don’t know of
any other way, and I’d be interested in knowing if this doesn’t
work on all SDL ports.) Better than OpenAL, where there seems to be
no way to do this at all (which makes it useless to me …)On Fri, Dec 06, 2002 at 01:47:24PM -0500, Mark Whittemore wrote:
How do I know how much Audio Consumed under SDL_Audio API ?
Surely I’m not supposed to keep track of this myself ?
–
Glenn Maynard
Hmm. This isn’t accurate enough; at least with the DSound
implementation, there’s a good deal of variance–the callback isn’t
necessarily called right when the buffers switch. (It’s a lot closer
with the NOTIFY stuff turned on, but that’s glitchy for some reason, and
it’s probably still not accurate enough.)
Sigh. I can’t find any cross-platform sound library that has some way
of accurately syncing audio. OpenAL, SDL, PortAudio–none provide
a mechanism to accurately sync output (though DirectSound does it very
easily). It’s strange, this is rather fundamental …
(Though I’m not certain this is what the person I was originally
replying to wanted, since he never followed up, this is still something
that’s been causing me problems.)On Fri, Dec 06, 2002 at 04:14:28PM -0500, Glenn Maynard wrote:
On Fri, Dec 06, 2002 at 01:47:24PM -0500, Mark Whittemore wrote:
How do I know how much Audio Consumed under SDL_Audio API ?
Surely I’m not supposed to keep track of this myself ?
If you’re referring to runtime detection of the play cursor, I
believe SDL always double-buffers audio, so you can probably keep track
of the system time of the last buffer and figure out how long it’s been
since it was sent to figure out the difference. Ugly and hacky, but it
seems to work. (I’m not positive it works in all archs; I don’t know of
any other way, and I’d be interested in knowing if this doesn’t
work on all SDL ports.) Better than OpenAL, where there seems to be
no way to do this at all (which makes it useless to me …)
–
Glenn Maynard
I extended SDL to give it the ability to detect the delay in
audio in milliseconds. I’ve used this to get pretty good
audio/video sync on linux and windows. www.mpeg4ip.net
Bill
Glenn Maynard wrote:> On Fri, Dec 06, 2002 at 04:14:28PM -0500, Glenn Maynard wrote:
On Fri, Dec 06, 2002 at 01:47:24PM -0500, Mark Whittemore wrote:
How do I know how much Audio Consumed under SDL_Audio API ?
Surely I’m not supposed to keep track of this myself ?
If you’re referring to runtime detection of the play cursor, I
believe SDL always double-buffers audio, so you can probably keep track
of the system time of the last buffer and figure out how long it’s been
since it was sent to figure out the difference. Ugly and hacky, but it
seems to work. (I’m not positive it works in all archs; I don’t know of
any other way, and I’d be interested in knowing if this doesn’t
work on all SDL ports.) Better than OpenAL, where there seems to be
no way to do this at all (which makes it useless to me …)Hmm. This isn’t accurate enough; at least with the DSound
implementation, there’s a good deal of variance–the callback isn’t
necessarily called right when the buffers switch. (It’s a lot closer
with the NOTIFY stuff turned on, but that’s glitchy for some reason, and
it’s probably still not accurate enough.)Sigh. I can’t find any cross-platform sound library that has some way
of accurately syncing audio. OpenAL, SDL, PortAudio–none provide
a mechanism to accurately sync output (though DirectSound does it very
easily). It’s strange, this is rather fundamental …(Though I’m not certain this is what the person I was originally
replying to wanted, since he never followed up, this is still something
that’s been causing me problems.)
The delay is typically the buffer size, at least with the DSound
implementation. However, delay from what? From the time the callback
is called, presumably. However, depending on how SDL is compiled,
there’s a lot of jitter in the callback timing–it’s not (and can’t be)
reliably called at the exact time the buffer is available. The result
is that it’s impossible to get the timing precisely.
The application I’m writing this code for bases scrolling on the current
sound position, and depending on the callback timing resulted in a lot
of visible jitter. Querying the play cursor directly results in
perfectly smooth scrolling (and, just as importantly, very tight timing
between the game and the music position).
Perhaps the difference here is that this application (www.stepmania.com)
needs exact AV sync, not “pretty good” sync. :)On Mon, Dec 09, 2002 at 09:52:56AM -0800, Bill May wrote:
I extended SDL to give it the ability to detect the delay in
audio in milliseconds. I’ve used this to get pretty good
audio/video sync on linux and windows. www.mpeg4ip.net
–
Glenn Maynard
I think you’re missing something… there are some issues with jitter
with the audio callback syncing, but the jitter should be within a few
milliseconds… (If you’re looking at time since the last callback)…
Assuming a CRT video display you certainly don’t need your scroll
position to be more accurate than the video frame rate… That should
not be a problem with the callback sync. Am I missing something?
-LorenOn Mon, 2002-12-09 at 20:28, Glenn Maynard wrote:
On Mon, Dec 09, 2002 at 09:52:56AM -0800, Bill May wrote:
I extended SDL to give it the ability to detect the delay in
audio in milliseconds. I’ve used this to get pretty good
audio/video sync on linux and windows. www.mpeg4ip.netThe delay is typically the buffer size, at least with the DSound
implementation. However, delay from what? From the time the callback
is called, presumably. However, depending on how SDL is compiled,
there’s a lot of jitter in the callback timing–it’s not (and can’t be)
reliably called at the exact time the buffer is available. The result
is that it’s impossible to get the timing precisely.The application I’m writing this code for bases scrolling on the current
sound position, and depending on the callback timing resulted in a lot
of visible jitter. Querying the play cursor directly results in
perfectly smooth scrolling (and, just as importantly, very tight timing
between the game and the music position).Perhaps the difference here is that this application (www.stepmania.com)
needs exact AV sync, not “pretty good” sync.
It does need to be more accurate than that. Rather, it doesn’t need
to be more accurate than the display resolution, but that’s substantially
higher. If it’s not, scrolling (being controlled by the play position)
won’t be smooth.
Game timing is based on this as well. Being off by up to 10 ms (which
is about the variation I was seeing) will make timing that much less
accurate.On Tue, Dec 10, 2002 at 01:32:43AM -0800, Loren Osborn wrote:
I think you’re missing something… there are some issues with jitter
with the audio callback syncing, but the jitter should be within a few
milliseconds… (If you’re looking at time since the last callback)…
Assuming a CRT video display you certainly don’t need your scroll
position to be more accurate than the video frame rate… That should
not be a problem with the callback sync. Am I missing something?
–
Glenn Maynard