firage wrote:

The results for AWE64 are representative of both CT4380 and CT4520 types? And the non-PnP SB16 represents everything from CT1740 to CT2740, or?

I didn't take down all the model numbers, yet. At this stage I was more concerned about getting the test to work and working out the bugs. The tests are still developing in some areas.

When I re-do the tests with the updated software, I will make sure to take pictures of the cards along with the graphs.

oh that's a pretty nice way to measure things. sloooow samplerate to make it more obvious and maybe also time when an irq occurs.

Harekiet wrote:

oh that's a pretty nice way to measure things. sloooow samplerate to make it more obvious and maybe also time when an irq occurs.

Just added IRQ logging, yes!

Harekiet wrote:

Slightly offtopic but seeing as you're doing sountblaster tests
I've wondered about the amount of processing time and buffering the soundblaster DSP has.
How soon after a sample is read through DMA does it appear on the output. Is there some small fifo in there to allow for a bit more output to cover the time to restart the dsp after an irq.

To answer this question, my test program shows that the FIFO is somewhere between 16 and 20 bytes large. But only if you use the SB16 DSP commands that enable the FIFO. If you use the FIFO-disabled versions, or any pre-SB16 commands, then it only buffers 1 sample.

EDIT: The 2-byte jumps seen in the snapshot are probably an artifact of not recording the DMA counter fast enough.
EDIT: Just ran the program on the old Compaq (ESS688 chipset). Sure enough, the graph shows a 64-byte FIFO load for SB compatible commands and a 256-byte FIFO load for ESS688 extended mode commands.
EDIT: Looking at the 4KHz FIFO on SB16 test, the AWE64 card seems to have a 20-byte FIFO, which it fills to 19 bytes at the start.

firage wrote:

The results for AWE64 are representative of both CT4380 and CT4520 types? And the non-PnP SB16 represents everything from CT1740 to CT2740, or..?

The AWE64 is a CT4500 and the ViBRAC is a CT4180.

Harekiet wrote:

oh that's a pretty nice way to measure things. sloooow samplerate to make it more obvious and maybe also time when an irq occurs.

Actually, I had IRQ logging enabled, but having interrupts enabled means jitter and dropouts in the recording of the DMA counter, so I had to remove it. The test now runs with interrupts disabled for accuracy. Look at the ESS688 graphs in the git repo to see what I mean about interrupts causing dropouts, it's visible in the graph.

I added testing to time DMA counter vs time with 16-bit PCM.

Preliminary testing shows so far:

FIFO fill for 8-bit PCM shows a burst of 20 bytes for 8-bit PCM, and 40 bytes for 16-bit PCM. I wonder if what the DSP is doing is upconverting everything to 16-bit internally anyway, and the FIFO is really just 20 16-bit samples rather than just 20 bytes.

Okay, here's is the first card I am testing with the newest code.

This is a CT4500, which is a "AWE64 PnP Value" according to Creative's web site.

Testing is in progress now.

EDIT: The latest DOSLIB commit contains the full test results.

Found out something about the ADPCM commands on the AWE64.

The maximum sample rate possible is quite a bit higher than the official sample rates published in Creative's official documentation.

You can go up to 25KHz with 2-bit ADPCM playback.

However if you exceed the maximum possible on AWE64 the decoded output sounds jittery, as if the DSP can't keep up decoding.

The 20-byte (8-bit) / 40-byte (16-bit) FIFO load is consistent although it's only in samples, not sample pairs. Stereo 8-bit playback doesn't load 40 bytes and 16-bit stereo playback doesn't load 80 bytes.

There is one graph in the commit that suggests this 40-byte FIFO only loads about as 2x as fast as playback when playing something as high bandwidth as 16-bit stereo PCM at 45454Hz.

This was done with the 16-bit DMA on a 16-bit wide DMA channel. I'll do another test in the future to see if DMA timing changes if I use the same 8-bit DMA channel for both 8 and 16 bit PCM.

EDIT: Yes, apparently 16-bit stereo PCM at 45454Hz is fast enough that when you assign both DMA channels to an 8-bit DMA channel on the ISA bus, the data rate it reads over ISA is hardly faster (about 1.1x) than the data rate needed to play 16-bit PCM at 45454Hz.

I have photos of the ViBRA 16C card (CT4180) and test results complete if anyone here wants to see them.

Very interesting topic. Unfortunately the DSP 4.13 firmware hasn't been reversed and is used as-is within MAME for example. Too pity no other 4.xx firmware dumps are available. These tests also could indirectly reveal which SB clones used clean room reversing and which used directly the DSP firmware.

georgel wrote on 2021-10-21, 20:16:

Very interesting topic. Unfortunately the DSP 4.13 firmware hasn't been reversed and is used as-is within MAME for example. Too pity no other 4.xx firmware dumps are available. These tests also could indirectly reveal which SB clones used clean room reversing and which used directly the DSP firmware.

See this thread:
The Soundblaster DSP project

In this thread, i posted 3.02, 4.04, 4.05, 4.11 and 4.13 firmwares.