[Portaudio] PA latency; StepMania use

[Glenn Maynard]

On Mon, Nov 18, 2002 at 03:39:43PM +1100, Ross Bencina wrote:
> the only API on thre Win32 platform that supports the concept of multiple
> hardware channels, as far as I know none of the MacOS APIs support hardware
> channels - I'm not sure about Linux. In general, modern audio hardware is
> just a DAC and some glue logic, with perhaps a proprietary DSP most audio
> APIs pretend the DSP isn't there.

I think they're a lot more intelligent since the advent of hardware 3d
sound.  I'd guess SB Live is by far the most common card on current
cheap consumer machines, and they handle hardware mixing.

> Can you give me an idea of what your latency requirements are?

I want minimal perceptible latency between pressing a button and hearing a
sound effect.  I don't know how fast it actually needs to be.

> If that's the lowest buffer size you can get, then that's the lowest latency
> you will have. 

No, that's not true.  My current PA implementation uses a 40960-frame
buffer (huge) and sounds start with almost zero perceptible latency.

The key is that, using multiple hardware buffers, the corrolation
between buffer size and startup latency is detached; I can use a
60-second buffer, if I want, and not affect latency for starting a
new sound at all.

If the hardware can't do this, then the alternative is lowering the buffer
size and hoping it can go low enough.  One possibility is to lower the
sample rate, but this is a music game; that's worst-case.  The other is
that some hardware, drivers and OSs can probably handle smaller buffers,
which might make plain, old-fashioned software mixing acceptable.

> Personally I can easily run 256 sample buffers with ASIO on
> my system.

It would be a lot simpler if I could get acceptably low latency with
regular mixing.  I've heard of ASIO but don't know much about it.  The
link in portaudio_v19/docs/pa_tut_asio.html is broken; where can I get
the SDK?  I can't find anything at www.steinberg.net.

> 404 not found.

(see my other post)

> Are you sure our license is GPL compatible? Someone else recently claimed
> that it isn't and we have no plans to change it.

Huh?  I've read it, and it seems BSD-ish; completely permissive with no
restrictions except to keep the copyright and credit intact.

It says:

"Any person wishing to distribute modifications to the Software is
requested to send the modifications to the original developer so that
they can be incorporated into the canonical version."

If that said "... MUST send the modifications ..." then it would be
GPL-incompatible (as well as OSI/DFSG-unfree), but it doesn't; it's
only a request.

-- 
Glenn Maynard