Yes, those limits are high enough to support most projects. You want to load your samples into memory for reference, then when you play them, copy it to the mix buffer. You then monitor this, either in the main thread or from a background worker thread (or simply from a timer event) to update channels, clear played sounds, decode the next chuck of streaming music etc.

The latest (in PGSDK) supports more music formats, more optimized, now operates in a safe timer event rather than a thread. Supports music streaming from an archive and more. It's now an ECOM object so can easily be extended on the client side to add new features. For example, if you derive a new audio class that adds support for fading in/out music, to make it work with the rest of the SDK you would do this:

[pascal]Pyro.Audio := TMyAudio.Create;[/pascal]

The old Audio instance will be destroyed and replaced with the new version and everything will continue to work throughout the SDK as normal. In fact all the singleton objects in the Pyro application instance can be upgraded in this way (DisplayDevice, RenderDevice, Input etc). Since memory is shared between the client and the DLL the DLL will destroy the Audio object as it normally would do and all will be fine.

As you develop your audio engine, think in terms of abstraction layers, this way you can add new audio playback formats as needed. In fact as you develop your projects in general think in terms of expansion and code in such a way that if you have to rewrite a section you can minimize having to rip out large portions of code or having to start all over. Often times it become easier to rewrite the whole thing than to maintain it. This is usually a sign of poor design up front. As it's impossible to know all the possible scenarios that you may encounter during development, we have to start to apply some agile methodologies to help make software development more manageable. I was going to say less complex, but the fact of the matter is that software design/coding is a complex beast.

So, grab a coke, beer or what ever your beverage of choice and begin think about what you want to accomplish with your audio engine. Resist the temptation to try and code it in your mind (at this point) as your working out the design, just consider all that you want it to accomplish. Now, break this down in to smaller and smaller (manageable) parts that you can code (and finish) and see the results. It's important that we see some results to give the brain the feedback it needs else we get bored and loose interest. Keep going until you have something that meets your goals. Note, as you do this, always keep in mind of how can an end-user (or yourself) expand up this to add new functionality without having to recode it. As we start to retrain ourself to work within these agile concepts the overall development process (should) becomes more efficient. I wish you success and keep us posted on your progress.