I have the skill to program test applications for you with DirectSound but I lack the experience on how to apply this knowledge to your question.

As far as I'm aware, EAX is exposed by DirectSound and does not require a proprietary API to access its capabilities; so if you can come up with an appropriate scenario then I can put together some tests for you to more closely examine the parameters as you see fit.

I remember older builds of SWG running on my SBLIVE! let me set up to 128sounds in hardware under windows 2000.
I really don't think it was actually using more then 32 tho.

From what I understand it the "soundfont cache" is just your system memory. The SB Live! does not have any onboard memory and has to store the soundfont in reserved system memory.

I don't think the DirectSound mixing buffers has anything to relate to "soundfont cache" though.

It would of been useful if Creative wasn't such a closed door company and they actually supplied reliable datasheets to the crap they make.

DracoNihil wrote:

From what I understand it the "soundfont cache" is just your system memory. The SB Live! does not have any onboard memory and has to store the soundfont in reserved system memory.

Exactly, which is the reason this is even a question. DirectSound can apparently allocate as much memory for software static buffer storage as the system can provide. When talking hardware buffer space though, and since the Live! mostly relies on system memory, I'm unclear as to whether this allocation is managed by DirectSound itself, and therefore extensible to the amount of system memory, or by the Live!, and presumably subject to either the adjustable cache limit, or the 512KB that the SB Live! driver reports to DirectSound as being available .

As far as testing goes, there's a DirectSound function called "GetCaps" that will query a device driver for its capabilities. This information is returned by DXDiag in versions later than the one that I'm currently running (7.0a). Similarly, Aureal's "Minerva" test suite reports similar information, and can perform various tests as well. The problem, however, is that neither DirectSound nor Minerva actually test up to the reported limits, and therefore, I'm unable to determine if the Live! settings mentioned (cache, and maximum simultaneous wave playback) make any difference whatsoever, or if DirectSound is able to just use all resources reported by the driver regardless. I'm thinking the latter is probable, in which case this is all irrelevant.

For the sake of comparison, here is the output that Minerva reports for the installed SB Live! and AWE64 Gold cards installed in my system:

Device Selected: DirectSound (SB Live! Wave Out [DCE0])
DirectSound reports...
1 Primary buffer available
32 Total 2D hardware mixing buffers available
32 Static 2D hardware mixing buffers available
32 Streaming 2D hardware mixing buffers available
32 Total 3D hardware buffers available
32 Static 3D hardware buffers available
32 Streaming 3D hardware buffers available
524288 Total bytes sound card memory static buffer storage
0 KB/sec Data transfer rate to hardware static buffers
100000 KB/sec Max sample rate supported by secondary buffers
100 KB/sec Min sample rate supported by secondary buffers

Device Selected: AWE64G Direct Sound Driver [220]
DirectSound reports...
1 Primary buffer available
25 Total 2D hardware mixing buffers available
25 Static 2D hardware mixing buffers available
0 Streaming 2D hardware mixing buffers available
0 Total 3D hardware buffers available
0 Static 3D hardware buffers available
0 Streaming 3D hardware buffers available
29360128 Total bytes sound card memory static buffer storage
0 KB/sec Data transfer rate to hardware static buffers
100000 KB/sec Max sample rate supported by secondary buffers
100 KB/sec Min sample rate supported by secondary buffers

AlphaWing wrote:

I remember older builds of SWG running on my SBLIVE! let me set up to 128sounds in hardware under windows 2000.
I really don't think it was actually using more then 32 tho.

The SB Live! certainly can't support 128 hardware channels, which is presumably why you never saw it use more than 32. 128 channels would have required software mixing.

Kahenraz wrote:

...so if you can come up with an appropriate scenario then I can put together some tests for you to more closely examine the parameters as you see fit.

A hypothetical scenario would simply involve attempting to use all 32 hardware buffers/channels when a lower value has been specified in the SB Live! drivers, as well as testing beyond the static buffer storage limit reported by DirectSound.

Really though, these aren't the kind-of things that most people care about, and in-depth testing may not be a worthwhile endeavor. I'm certainly fine to continue on with my 32/32 configuration regardless. 😀

Audiowinbench 99 has some nice DirectSound tests.

Thank-you for the suggestion, swaaye. I'll have to check it out.

Sound blaster live can address up to two gigabytes of ram. You should be just fine with what you're doing, so no.

If the Live! has over 2gb of ram available, then it might have problems with soundfont cache (usually only on 64-bit OSs). Sound memory is independent of the Live!'s address space, so soundfont cache and memory address shouldn't affect card performance if system memory is redundant AFAIK. Soundfont cache can have problems of its own with over 2gb of ram available. I also think the Live! can mix 32 sounds even if its wavetable feature is used simultaneously without eax, but I'm not sure otherwise. Unless there's an obscure sound program-engine assembled for the live!, soundfont cache is totally independent of SFX memory.

There's no correlation between soundfont cache memory and SFX memory (directsound, openal, etc); unless you use all your system memory available for soundfont cache there isn't any performance penalty. Benchmarks would certainly be a good way to prove this.

Holering wrote:

Sound blaster live can address up to two gigabytes of ram.

You bring up a good point. The EMU10K1 can only physically address 32 MB, and relies on a later driver to provide address translation and paging above that amount. I imagine there must be some amount of system overhead involved in those operations (not to mention potential audio/dropout issues), so it would certainly seem prudent to keep the SoundFont cache set to 32 MB or less, regardless of anything else.

Cloudschatze wrote:

Holering wrote:

Sound blaster live can address up to two gigabytes of ram.

You bring up a good point. The EMU10K1 can only physically address 32 MB

Sound blaster Live has 31-bit dma access to the PCI bus.

In Linux, I've never had issues with wavetable midi or sfx dropouts with 256mb soundfonts. I've had midi notes drop after a while of using 1.6+ gigabyte soundfonts. But I personally have never had SFX dropouts, crackles or anything like that. I think the biggest problem is resampling sfx to 48khz for the emu10k1; I'm not even sure the emu10k1 clock is exactly 48khz. There's an assembler for emu10k1 in Linux but I haven't looked at it.

Holering wrote:

Cloudschatze wrote:

Holering wrote:

Sound blaster live can address up to two gigabytes of ram.

You bring up a good point. The EMU10K1 can only physically address 32 MB

Sound blaster Live has 31-bit dma access to the PCI bus.

Okay, and...? 😀 The EMU10K1 is documented as only being able to address 32MB of memory at any given time. It wasn't until the release of the EMU10K2 that this limitation was resolved.

The Linux drivers must employ the same type of on-the-fly translation/paging scheme as Creative's Live!Ware 3.0 Windows drivers. This obviously works well enough in most cases, else I can't imagine it would have been offered as a workaround in the first place. That said, anecdotal USENET references do exist suggesting that SoundFont/MIDI playback can be susceptible to dropouts/static when more than 32MB of SoundFont data is loaded. Perhaps that's what you experienced with the dropped MIDI notes, or perhaps not. I don't see this limitation as being applicable to most sound-effect playback though, which I suspect is done primarily with streaming buffers.

There is an epic USENET thread about the the 48kHz re-sampling and digital I/O of the SB Live! in general. I'm not so much bothered by the re-sampling though, given the nature of the card. I'm really quite impressed with the Live!, honestly.