VOGONS


First post, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

The results may surprise you.

I recently added to DOSLIB a program under hw/sndsb that runs the Sound Blaster card through the time constants and sample rate commands to time how long it actually takes to play.
The idea is to get a sense of how the card actually handles the sample rate, whether it's rounding, and what the minimum and maximum rates actually are.

The results for the Sound Blaster 16 are actually somewhat surprising. Especially for non PnP versions of the SB16 that seem to have some sort of rounding or math error in the DSP firmware at specific sample rates.

Results (2017-10-22):

https://github.com/joncampbell123/doslib/comm … 7b223a7b72131bb

DOSLIB test utility:

https://github.com/joncampbell123/doslib/blob … w/sndsb/ts_ps.c

Another test utility if you would like to spend an hour or two running through all 65536 possible sample rates on the SB16 using DSP command 0x41:

https://github.com/joncampbell123/doslib/blob … sndsb/ts_ps16.c

I will release binaries shortly on Github. If anyone wants to run this test on their Sound Blaster or compatible sound cards, feel free to do so and post your results here.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1 of 31, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

Binary release of DOSLIB:

https://github.com/joncampbell123/doslib/rele … s-ps-2017-10-22

The test utility is in HW/SNDSB under DOS86S or DOS86L. Have fun.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 2 of 31, by Stojke

User metadata
Rank l33t
Rank
l33t

For those unaware of what do the test images mean, what effect does this rounding error have, slight almost unnoticeable sound distortion?

Note | LLSID | "Big boobs are important!"

Reply 3 of 31, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
Stojke wrote:

For those unaware of what do the test images mean, what effect does this rounding error have, slight almost unnoticeable sound distortion?

Sound Blaster cards take a sample rate in the form of an 8-bit "time constant", computed like this:

256 - (1000000 / rate)

Most of the graphs show the time constant byte vs the actual sample rate the card plays at given that time constant.

SB16 tests use DSP command 0x41 which allows you to specify a 16-bit sample rate in the command. The SB16 tests show that 16-bit value vs the actual rate in hardware.

While pre-SB16 cards show a smooth curve, many clones and the SB16 show that there's some rounding of the sample rate. When you look at the SB16 graph (DSP command 0x41) you'll notice that the 16-bit value is rounded down to some multiple of an unknown constant and then used.

One of the graph shows that this rounding is flawed on non-PnP SB16 cards that produces an incorrect sample rate at periodic points along the 16-bit sample rate range.

The graphs are also intended to show the real minimum and maximum sample rates possible on each card.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 4 of 31, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
Stojke wrote:

For those unaware of what do the test images mean, what effect does this rounding error have, slight almost unnoticeable sound distortion?

ESS688 cards have their own sample rate divider system, which is also shown if the card is a ESS688/ESS1868 chipset.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 5 of 31, by Harekiet

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Reply 6 of 31, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
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.

It varies from model to model. Creative's stuff probably has a FIFO, though they don't say how large it is, nor do they mention in what model was it added. So my best guess is that the original DSP 1.x versions probably didn't have a FIFO, DSP 2.x probably added a 8 or 16 byte FIFO, DSP 3.x (Pro) probably kept it the same, and Sound Blaster 16 probably has a 16 or 32 byte FIFO. Again, Creative doesn't document this stuff, so that's all just a guess on my part.

May clones usually have larger FIFOs. Some explicitly state it in the datasheet. ESS688 chipsets state that in Sound Blaster compatible mode there is a 64-byte FIFO in the firmware, unless you're in "extended mode" where it becomes a 256-byte FIFO.

If the ISA bus provides enough timing, it might be possible to start a DMA transfer and time the rate through the DSP block to completion. A sound card starting playback would probably DMA faster than normal for an instant to fill the FIFO before running the DMA at playback speed after that point.

EDIT: Perhaps this FIFO fill could be best detected if the DSP were asked to play at the slowest sample rate possible.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 7 of 31, by Harekiet

User metadata
Rank DOSBox Author
Rank
DOSBox Author

With such a large fifo you'd imagine it would start the IRQ while there's lots of data yet waiting to be played in the fifo. I always thought you'd have more noise from single cycle dma but you don't really notice is that much. Although the dsp will just keep playing the last sample as long as the speaker is on and that might alleviate the noise issue.

Maybe I'll just hook up the scope sometime to the dma and irq and dac output lines and see if I can at least notice the time interval beteen things happening.

Reply 8 of 31, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie

well the DSP just an 8051 MCU with some 4kb rom and tiny amount of ram.

older SB, the 8051 did all the dac/ram/dma, later some of it was offloaded more.

dsp command 0x4x (0x40,41,41,etc) set time constant writes directly to the 8051 timer. your answers probably lie in the 8051 datasheets. this is what triggers interupts to fire

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 9 of 31, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
BloodyCactus wrote:

well the DSP just an 8051 MCU with some 4kb rom and tiny amount of ram.

older SB, the 8051 did all the dac/ram/dma, later some of it was offloaded more.

dsp command 0x4x (0x40,41,41,etc) set time constant writes directly to the 8051 timer. your answers probably lie in the 8051 datasheets. this is what triggers interupts to fire

For the original Sound Blaster and Sound Blaster Pro that's pretty obvious from the Time Constant command, sure. One of the graphs posted is taken from a Sound Blaster Pro. The graph is completely smooth through the test.

I'm not so sure the Sound Blaster 16 uses the same processor. Notice from the graph that whether you use DSP command 0x40 or DSP command 0x41, the sample rate is rounded to a nearest value on a linear scale. This seems to be true on all SB16 from the first non-PnP all the way up through the AWE64. Also audible during the test is that the SB16 DSP is using some sort of oversampling or lowpass filtering at low sample rates where prior versions either did not filter (SB 2.0 and earlier), or provided a fixed lowpass filter that you could switch on/off (SB Pro).

I think Creative used a completely different design in the SB16 that isn't a countdown timer at all but probably some kind of fixed point hardware interpolation that renders out at a fixed sample rate to the DAC. That might also explain why SB16 cards have that constant DSP "busy cycle" whether the card is in use or not, where prior cards only had a "busy cycle" when the DSP was playing/recording audio.

This rounding is most visible in the SB16 non-PnP DSP command 0x41 test (that took 2 hours to run BTW) where among the "jumps" caused by a DSP bug there is a visible linear stair-step all the way across the sample rate scale. It seems to be rounding to a multiple of about 188 to 200 (haven't checked yet).

The funny thing is that while SB16 cards round the sample rate like that, the Sound Blaster Live! emulation of the SB16 appears to neither round the sample rate nor limit it to traditional sample rate limits (though you can "hang" the emulated DSP if you specify too high a sample rate in high-speed DMA playback command).

I expect Sound Blaster clones to round the sample rate in some way because clones don't necessarily run at the same clock rate and they have to convert Creative's sense of time to their own. Some do it better than others. The Gallant SC-6600 clone I tested is pretty bizarre in it's own way, especially in the flawed way it caps the time constant to SB compatible rates (highspeed vs normal).

NOTE:

The "busy cycle" is when bit 7 of port 22Ch cycles on and off on it's own whether or not your program is writing anything to the DSP. This cycle is always running on the SB16. I found during DOSBox-X development and testing that "Crystal Dream" relies on this busy cycle to detect whether the DSP is still playing audio, and fires off another DSP command 0x14 or 0x91 to keep playback going if it sees the cycle stop. Since SB16 cards never stop, Crystal Dream fails to keep audio playback going on SB16 cards and goes silent.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 10 of 31, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie
TheGreatCodeholio wrote:

I'm not so sure the Sound Blaster 16 uses the same processor.

....

I think Creative used a completely different design in the SB16 that isn't a countdown timer at all but probably some kind of fixed point hardware interpolation that renders out at a fixed sample rate to the DAC.

no its still 8051, what they did was, pre sb16, the 8051 timer was programmed directly from the x86, with sb16, now when you program timer with 0x40 etc, you dont hit the 8051 directly, you hit the rom code which interprets, then programs the 8051 for you.

sb16 just has rom code in front of the timer you have to go through.

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 11 of 31, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
BloodyCactus wrote:
TheGreatCodeholio wrote:

I'm not so sure the Sound Blaster 16 uses the same processor.

....

I think Creative used a completely different design in the SB16 that isn't a countdown timer at all but probably some kind of fixed point hardware interpolation that renders out at a fixed sample rate to the DAC.

no its still 8051, what they did was, pre sb16, the 8051 timer was programmed directly from the x86, with sb16, now when you program timer with 0x40 etc, you dont hit the 8051 directly, you hit the rom code which interprets, then programs the 8051 for you.

sb16 just has rom code in front of the timer you have to go through.

Well that code obviously has some mistakes in the initial release of the card then 😀

If it was still an 8051 timer, it would show the sample rate with non-linear quanitization errors that could only come from calculating 1/x (clock rate divide by x). I'm seeing quanitization on a linear scale, like the sample rate (either directly or converted from the time constant by the DSP) is reduced in precision internally and then used as part of a linear interpolation routine within the DSP.

It's the difference between:

countdown = clock rate / time constant

and interpolation (something like):

interpolation_step = sample rate / 200;
interpolation_max = 45454 / 200;
/* interpolation code */

The only thing the SB16 and earlier seem to have in common is the maximum sample rate of 45454Hz (1000000 / 22).

EDIT: Actually, what the DSP might be doing, is upconverting everything to 45454Hz and then using the 8051 timer to drive the DAC at 45454Hz with the upconverted output.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 12 of 31, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

I thought about it a bit more. Asking a 8051 to do filtering, interpolation and resampling while responding to commands might be a bit much.

What is probably more likely is the 8051 microcode upconverts to 45454Hz internally by just repeating samples to the DAC by fixed point math of some kind (or, it could just count by fixed point math and leave the prior sample there in the latch to "repeat" it), and then after the DAC is a variable DSP-controlled lowpass filter that is set according to a percentage of the sample rate. It's done well enough that it sounds more pleasant than the unfiltered metallic DAC output of the prior cards. That might be how the SB16 DSP works. As far as I know doing it that way would be cheaper and more cost effective than full interpolation and resampling in the DSP itself.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 13 of 31, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie

sounds plausible to me. prior to sb16, you will see it just a raw mcs8051 with either intel or harris fab marks (I dont know if they used siemens 8051 chips or not). but when sb16 came, they fabbed a mask rom asic of their own. no more second sourcing chips (which also stopped the clones for the most part) from intel or harris.

MESS has a sb16 rom... you could disassemble it and see.... (sb16.zip)

http://bda.retroroms.info/downloads/mess/Mess.V0161/BIOS/

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 14 of 31, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

Wow! Thanks for the link. I'll take a look as soon as I can.

Do they have the ROM for the CSP/ASP chip as well?

DOSLIB at this time only has limited support for poking at the CSP's registers and talking to the 2KB of RAM in the chip. I have an old SB16 with the CSP on it that I've been meaning to poke at more.

EDIT: The links are password protected, though.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 15 of 31, by elianda

User metadata
Rank l33t
Rank
l33t
TheGreatCodeholio wrote:

NOTE:

The "busy cycle" is when bit 7 of port 22Ch cycles on and off on it's own whether or not your program is writing anything to the DSP. This cycle is always running on the SB16. I found during DOSBox-X development and testing that "Crystal Dream" relies on this busy cycle to detect whether the DSP is still playing audio, and fires off another DSP command 0x14 or 0x91 to keep playback going if it sees the cycle stop. Since SB16 cards never stop, Crystal Dream fails to keep audio playback going on SB16 cards and goes silent.

That possibly explains why Crystal Dream runs on some third party cards also with 44.1 kHz in SB Pro mode with correct output.

Retronn.de - Vintage Hardware Gallery, Drivers, Guides, Videos. Now with file search
Youtube Channel
FTP Server - Driver Archive and more
DVI2PCIe alignment and 2D image quality measurement tool

Reply 16 of 31, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie

you can find the csp/asp microcode firmware in android/linux github.

https://github.com/rushup/Kitra710-kernel/tre … r/firmware/sb16

these are ihex for the firmware.

here is the sb16, CT1741 DSP 4.13 rom from mame

https://archive.org/download/MAME_0.185_ROMS_ … s%29%2Fsb16.zip

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 17 of 31, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
elianda wrote:
TheGreatCodeholio wrote:

NOTE:

The "busy cycle" is when bit 7 of port 22Ch cycles on and off on it's own whether or not your program is writing anything to the DSP. This cycle is always running on the SB16. I found during DOSBox-X development and testing that "Crystal Dream" relies on this busy cycle to detect whether the DSP is still playing audio, and fires off another DSP command 0x14 or 0x91 to keep playback going if it sees the cycle stop. Since SB16 cards never stop, Crystal Dream fails to keep audio playback going on SB16 cards and goes silent.

That possibly explains why Crystal Dream runs on some third party cards also with 44.1 kHz in SB Pro mode with correct output.

Correct. I had no problems running Crystal Dream on an old Gallant SC-6600 sound card back in the day (rebadged as a "Reveal SC-400"). It was one of those CS4231-based "Windows Sound System" type sound cards with very good Sound Blaster Pro emulation with a CD-ROM interface thrown in for good measure. Many DOS games were played on that card.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 18 of 31, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

Okay, I just tested traditional SB time constant and playback commands on a SB16 card.

I just finished a TS_PD.EXE test program that plays a sample on SB hardware and records the DMA position vs time to a file.

The SB16 has a FIFO but the backwards compatible SB 1.x playback commands seem to act as if the FIFO is only 1 byte large.

When I have more time I'll see how some other cards respond to this, and whether this applies to the high-speed DMA and SB16 playback commands.

I fully expect the ESS688 chip to show it's documented 64-byte FIFO in these tests, I'll see if that holds up.

EDIT: Well, actually the graph might mean it has a 2-byte FIFO in this mode. It appears to rapidly DMA 2 bytes and then DMA single bytes at the sample rate afterwards.

Creative Sound Blaster 16 AWE 64 PnP - SB 1.x DMA single cycle DSP test, 4000Hz, 4000 bytes.start.png
Filename
Creative Sound Blaster 16 AWE 64 PnP - SB 1.x DMA single cycle DSP test, 4000Hz, 4000 bytes.start.png
File size
19.11 KiB
Views
2068 views
File license
Fair use/fair dealing exception

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 19 of 31, by firage

User metadata
Rank Oldbie
Rank
Oldbie

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

My big-red-switch 486