gamedevlists-general

RE: [GD-General] Audio latency

[Lewin, G. <gl...@ea...>]

Not sure exactly what you are doing, but I would have the latency a
fixed value, and play the music that much sooner.

I'm thinking DDR here (Yes, I dance, in my living room, with a
computer.) there is no latency in the sense that it's one stream of
music and done.

If you want to play an effect each time a button is pressed, on a pc, I
think you will find you are pretty much screwed, but I hope you find
otherwise :)=20


_________________________________________
Gareth Lewin - http://www.garethlewin.com

"Facts are useless. You can use facts to prove anything that's even
remotely true. Facts shmacts!" -- Homer Jay Simpson.
-----Original Message-----
From: Brian Hook [mailto:ho...@bo...]=20
Sent: Tuesday, June 29, 2004 12:33 PM
To: gam...@li...
Subject: [GD-General] Audio latency

I'm curious, how much latency do you guys accept from your audio
subsystems?  With the amount of layering that occurs, e.g. software
application mixing which in turn might go into an API mixing system
which in turn goes to a hardware mixer, I can see latencies going up to
the hundreds of milliseconds.

With my old audio stuff I could crank my buffer up to 500ms, and that
was very...bad...feeling.

For a beat matching game it would seem that you'd need extremely low
latency, right up there with that of professional audio software (8-16ms
or less).=20

Thoughts?




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital
self defense, top technical experts, no vendor pitches, unmatched
networking opportunities. Visit www.blackhat.com
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7

Re: [GD-General] Audio latency

[Ivan-Assen I. <iva...@gm...>]

> For a beat matching game it would seem that you'd need extremely low
> latency, right up there with that of professional audio software (8-16ms
> or less).

Professional audio guys scoff at anything above 3-4 ms, and
professional audio software achieve this by using professional grade
audio APIs like ASIO - which the drivers for consumer audio cards
don't support (or lie about supporting them - yes, I'm talking about
you, NVIDIA!).

Even for something like DDR, I would guess you could live with
something on the order of 20-30 ms, though. You can play the piano
with latencies in that range - although it gets on your nerves - but
with the inherent latency in something like moving your foot to the
adjacent foot pad, I guess DDR would be much, much more forgiving.

Re: [GD-General] Audio latency

[Brian H. <ho...@bo...>]

> Professional audio guys scoff at anything above 3-4 ms

Well, maybe TODAY they do, but I remember not too long ago that if you 
could get down to 15ms that you were considered doing great.  In fact, 
even today "zero-latency monitoring" is considered a must have.

But I digress.

> professional audio software achieve this by using professional
> grade audio APIs like ASIO - which the drivers for consumer audio
> cards don't support (or lie about supporting them - yes, I'm
> talking about you, NVIDIA!).

Right, there are up to three layers depending on the platform:

- the application:
   1.  Delay between input and dispatching sound
   2.  Delay between dispatching sound and delivering to API

- the API
   1.  Delay between receiving sound and sending to hardware

- the hardware
   1.  Delay between receiving buffer and generating output

Let's say you have a steady 60Hz application.  On average the latency 
to _detect_ a key press is about 8 ms.  So that's your floor, on 
average.

If you're doing software mixing you might be looking at an average of 
5-50ms of latency depending on how much buffering you need/want (which 
in turn depends on the underlying system's hardware).  Let's call it a 
10ms buffer with an audio worker thread that sleeps at 5ms intervals.

So now we're at 18ms on average if we're doing our own mixing.

Then the API receives an updated buffer, and that in turn probably 
gets run through a software mixer before heading out to the hardware.  
Then the hardware gets a shot at it, etc.

In the theoretical best case you've got samples and you're mixing 
straight into the hardware's DMA output buffer, but I don't believe 
that's reliable in a cross-platform manner (one reason I use software 
mixing and audio servicing threads -- I just flat out don't trust 
drivers or APIs anymore after seeing the most trivial things break, 
e.g. DSound notifications).

So call it 25ms latency if you're doing well, and significantly worse 
if not.

I'm not sure if that's acceptable for a rhythm oriented game, which is 
probably most closely analogous to fighting games.

Feh.

Brian

RE: [GD-General] Audio latency

[Brian H. <ho...@bo...>]

> I'm thinking DDR here (Yes, I dance, in my living room, with a
> computer.) there is no latency in the sense that it's one stream of
> music and done.

Right, the idea I had was beat matching but where you actually play a 
sound on the beat instead of just matching the music that's there.  
I'm concerned that real latency issues are going to prevent that from 
being possible, except with a very hand coded, single platform 
implementation.

Brian

Re: [GD-General] Audio latency

[Thatcher U. <tu...@tu...>]

On Jun 30, 2004 at 12:44 -0400, Brian Hook wrote:
> > I'm thinking DDR here (Yes, I dance, in my living room, with a
> > computer.) there is no latency in the sense that it's one stream of
> > music and done.
> 
> Right, the idea I had was beat matching but where you actually play a
> sound on the beat instead of just matching the music that's there.
> I'm concerned that real latency issues are going to prevent that from
> being possible, except with a very hand coded, single platform
> implementation.

I think you should definitely be able to work around a reasonable
amount of latency using some game/audio design.  For example, let's
say you want to play a special drum sound when the user hits the
button at the right time.  But due to output audio latency and input
processing latency, you may not find out about the button-press until
after you need to start playing the drum sound.  So one trick would be
to design your game so that there is always a "null beat" sound that
plays when the user doesn't press the button.  Now, design the null
beat and the real beat so that the first 50ms, say, sound exactly the
same.  Then you're golden, you have enough time to substitute the rest
of either the null beat or the real beat right after the initial
attack.  Maybe this makes the real beat less satisfying to the player,
maybe not; that would have to be tested.

Or maybe a longish constant latency isn't actually so bad.
E.g. electric guitarists sometimes stand pretty far from their amps.
Sound travels about 1 foot per millisecond, so 20 feet ~= 20 ms.  I
don't know any drummers that stand 20 feet from their drums though.

It would be interesting to make a latency-adjustable virtual drum kit
and see how it feels.

-- 
Thatcher Ulrich
http://tulrich.com