Creative is known for not following the datasheets. That was basically what I meant by their “design.” 😀

Hope the caps get it restored! I’m fairly certain they will.

Well i checked the TEA2025 datasheet and they did follow the datasheet for the most important part.

Anyway, card is now fixed, but here's the story:

I started by desoldering the 16V 470uf caps, that didn't look too good nor were looking very nice. Rubycon capacitors, so at least Creative didn't cheap out on the caps, at least if those were original, but soon enough i saw the disaster: both caps were leaking and the acid was already corroding one trace badly. Used the multimeter to check for continuity and that confirmed the trace was eaten. Willing to bet that trace was indeed the output trace for the right channel i got some white vinegar and a cotton bud to neutralize and get all that gunk cleaned. So some elbow grease, i exposed the copper on the trace and solder a wire between it and another healthy point. Turns out i didn't have replacement 16V 470uf capacitors only 330uf ones, but i soldered them on anyway. I got the card on the system, fired a game and soon enough all channels are now playing fine. Tried a game with support for stereo OPL2 and i could confirm both channels play and there is stereo separation.

I already ordered some replacement Panasonic FC's with 470uf for piece of mind.

Moral of the story: it doesn't hurt to check your vintage cards.

Thumbs up.

CkRtech wrote:

Creative is known for not following the datasheets. That was basically what I meant by their “design.” 😀

That's not really how it works. Datasheet examples are really just examples how to do it in one example application, not the only right way, and clearly the component values can be altered within limits to make it suitable in another application.

Would you care to say which particular part of their "design" you are referring to?

It was a shortened phrasing as I was replying on my phone at the time. I apologize for any confusion. Creative doesn't always follow datasheet implementations verbatim, and the datasheets by design show a possible implementation & will also go into calculations depending on which components you choose.

I believe we are basically in agreement here, but I'll elaborate a bit for kicks.

Basically a datasheet will recommend a value for a support component - like a capacitor value of say - 1000uf - for an implementation of a particular IC. Creative Labs might build their soundcard and use something like 680uf. Some people might read the datasheet, see the 1000uf component listed, and figure that Creative cheaped out on what component should be used. I think there was a thread on vogons that discussed it a bit for some people that were recapping SB16s and finding what they might consider a discrepancy between datasheet and Creative's implementation. I don't have a link to the thread handy, but that might provide an example of non-verbatim implementation.

Like you said - datasheets provide example implementations. In the case of this particular sound card and the amp that it used, 470uf is mentioned in the Stereo Application schematic. I didn't have an actual card in my hand to check the output caps for the amplifier - the datasheet specified 470uf, but that wasn't necessarily what Creative used in the circuit.

So when carlostex mentioned he went to the datasheet for the capacitor values, I just wanted to point out that Creative may have used something different from the illustrated application circuit possibility. Again, I didn't know which capacitors they used in the circuit as I didn't have a card. The datasheet itself makes note of the low cutoff frequency calculation due to the output capacitor for the amp:

"It might change the sound, but the design wasn't Creative Labs decision" - well, it was Creative's design because they made the card and chose the caps they wanted to use for the circuit. Those caps could have differed from the datasheet, but in this particular case did not - as he pointed out in the next phrase stating that Creative just used the values they recommended.

Well you replied exactly what I would have said if I had made a longer post 😀 So yes, we agree completely.

I also recall that the general mantra that keeps repeating is that they put smaller caps to make cheaper products and I also think it comes from the fact that they really did put smaller caps there (but for a reason) and somebody just looks at the datasheet and says the caps are smaller than what they are supposed to be, which is of course not the case.

So I think the next time this comes up, I think I might ask that person if the installed caps are good enough and if the datasheet values are overkill for the environment the card is being used 😀 I mean, most unpowered 4-ohm desktop speakers are not large enough to produce 80 Hz, and most 8 ohm bookshelf speakers are not large enough to produce 40 Hz, and with 16-ohm headphones you approach the 20 Hz limit of human hearing, so there really is a bit headroom that allows for smaller valued caps.

Jepael wrote:

Well you replied exactly what I would have said if I had made a longer post 😀 So yes, we agree completely.

I also recall that the general mantra that keeps repeating is that they put smaller caps to make cheaper products and I also think it comes from the fact that they really did put smaller caps there (but for a reason) and somebody just looks at the datasheet and says the caps are smaller than what they are supposed to be, which is of course not the case.

So I think the next time this comes up, I think I might ask that person if the installed caps are good enough and if the datasheet values are overkill for the environment the card is being used 😀 I mean, most unpowered 4-ohm desktop speakers are not large enough to produce 80 Hz, and most 8 ohm bookshelf speakers are not large enough to produce 40 Hz, and with 16-ohm headphones you approach the 20 Hz limit of human hearing, so there really is a bit headroom that allows for smaller valued caps.

Creative's choices may well have been fine. But were they ideal? That's the part I think is in question.

From our point of view, it's not really a question of whether the originals were adequate, but whether some alternate set of values might possibly be more ideal. If those alternate values add another $1-$2 to the parts cost and are just slightly preferable, we'd probably go for that option, even if Creative wouldn't have.
However, lacking certainty on this, using Creative's original values is the safe way to go.

Hello fellow Vogons!

James-F wrote on 2016-10-23, 14:05:

Summary Using this method: SBPro1 CT1330A, lets solve the Reversed Stereo myth! We have concluded that the SBPro1 CT1330A and SB […]
Show full quote

Summary
Using this method: SBPro1 CT1330A, lets solve the Reversed Stereo myth!
We have concluded that the SBPro1 CT1330A and SBPro2 CT1600 behave exactly the same with PCM audio, so everything besides the Dual-OPL2 is exactly the same.
There is NO stereo reverse issue with the original cards, it's a 30 year myth. 😀

I'm sorry to chime in 5 years later, but I disagree with your conclusion.

Harikiet's SBTEST.EXE outputs a tone on the supposedly *RIGHT* channel. I have verifyed this by tracing the data it actually transmits to the card via DMA by adding appropriate debug output in DOSBox.

Next, I tested SBTEST.EXE on a real SB Pro 2 (CT1600 Rev 05 DSP 3.02). It outputs on the *LEFT* channel.
I also wrote my own cleanroom Sound Blaster test code (attached, with source), which tests all stereo output features of the SB Pro (and other Sound Blasters). Mixer channel (Master, Voice (PCM), Midi (OPL3)) all apply to the correct (as documented in "Sound Blaster Series Hardware Programming Guide") stereo channels. The OPL3 also outputs to the correct stereo channels as documented. However, PCM audio is swapped. It is swapped regardless of whether the 1 byte stereo-init transfer is made or not (the 1 byte stereo-init transfer appears to do absolutely nothing on real SB Pro hardware - this is the same conclusion already known from all the tests done in this and related threads).

Now note that my findings actually match what everyone in this thread has reported with real SB Pro (1 or 2) hardware: SBTEST.EXE outputs on the left channel twice.

It appears to me that the wrong conclusion was drawn because maybe someone somewhere assumed that SBTEST.EXE was supposed to output on the left channel. But it does not. It writes data to the right channel. SB Pro cards output that signal on the left channel though, thus PCM stereo is reversed on these cards. On all of them.

The DOSBox behaviour is still wrong of course, as it does not matter on real hardware whether the 1 byte stereo-init is made, while it matters (and swaps if done) the stereo channels in DOSBox. Also without the 1 byte stereo-init, the initial behaviour of DOSBox is to not swap, which also does not match actual hardware.

For what it's worth, PCem v17 when emulating SB Pro 1 or 2 behaves the same as actual SB Pro hardware. It always swaps the stereo channels, independently of whether the 1 byte stereo-init is made.

I do not care particularly much about SB Pro clone cards. The fact that all known original SB Pro cards appear to swap stereo channels implies that clone cards should have done that too. Would all clone cards have done that, I doubt there would be any confusion by now on whether stereo would be swapped on SB Pro cards. Implementors of output drivers would very likely have noticed the consistent swapping and would have always swapped in software on SB Pro and compatible cards. This obviously did not happen, presumably because some clones did not swap (or because some implementors never tested on actual orignal SB Pro hardware (which may be likely for later titles which also support SB16)). Hence the whole confusion. Some games apply the swapping in software and thus output correctly on an original SB Pro, some do not.

There still remains some confusion in 4 areas:

1. Why do some games/programs appear to randomly flip stereo around? I have not investigated that yet, however I guess they might transfer incomplete stereo frames (i.e. an odd number of samples) in a single DMA transfer somewhere sometime. I have noticed such behaviour (transfering incomplete stereo frames) at least with Open CubicPlayer in SB16 mode.
2. The whole stereo-reverse issue could still be timing related, i.e. how fast after the initial 1 byte stereo-init does the real DMA transfer start, or how long does it take to restart DMA in single-cycle DMA mode (in auto-initialized DMA mode the latter issue does not exist), and how may a longer pause between DMA transfers interact with transfer of incomplete stereo frames?
   However, given that

   xeoblade wrote on 2017-02-24, 08:23:

   Not sure if I should resurrect this older thread but since I recently picked up a Rev 2 CT1330A I thought I would add my results […]
   Show full quote

   Not sure if I should resurrect this older thread but since I recently picked up a Rev 2 CT1330A I thought I would add my results to the list.
   SBCheck:
   DSP version 3.01
   Sound Blaster Pro 1 Stereo 8-bit board... use SBPro.ADC driver.
   SBTest:
   1. I heard the tone out of the left speaker, and if I turned the volume up I could hear something out of the right.
   2. Heard the same tone/sound from the same speakers in the second part.
   It is currently placed in a 386 dx/40 machine so it has a hard time with "newer" dos games. I have a few other machines I could put it in (486, Pentium) so if you think it would help with the cause I could do that.

   was found on a machine on the slower spectrum from the SB Pro era, I somewhat doubt anything related to timing of the machine itself. It could still be timing dependent on the actual driver code, like, if it goes around and does something else completely, after sending the 1 byte stereo-init.
3. Is there a phase difference of 1 sample between left and right channels due to swapping on original SB Pro (i.e. does it actually swap channels, or does the output "eat" 1 sample from one of the channels without actually outputting it)?
4. Is there always a phase difference of 0.5 samples between left and right channels due to the way original SB Pro mixer "filters" the DSP output signal?

(3.) and (4.) may be hard to even measure, given the abysmal noise floor and stereo separation of the SB Pro.
Also note that (3.) would only be measured properly if the code that does the output is known *precisely*, because it is necessary to know if it swaps stereo, or skips 1 sample of one of the channels, or does neither. In particular, output using any Windows program would depend on the Windows SB Pro driver and would not yield any conclusive result here.

BLASTOR.EXE documentation:

Use at your own risk. It has only been tested in DOSBox, PCem, an AMD K6-3 400/66 (i430HX) + SBPro2 system, and a Pentium 2 + AWE64 Value system.

BLASTOR.EXE requires the contents of csdpmi7b.zip from DJGPP in the same folder, and XMS memory to run.

Also, since this is only the second time ever that I tried DOS hardware programming, it also probably contains bugs.

BLASTOR.EXE detect:
Performs Sound Blaster detection and outputs what it finds in 3 consecutive runs:

1. Only looks at the BLASTER variable.
2. Looks at the BLASTER variable and does additional auto-detection and verification.
3. Does not look at BLASTER variable and probes for Sound Blaster cards.

(3.) may actually crash or lock up a system if other hardware is installed at the addresses the code tries to probe. It also might mis-detect the interrupt if other hardware is in active use and uses that interrupt (traffic on a network card is a likely cause here).
This outputs more data than fits on a 25 line screen, use "| more" or a highres text-mode if you want to see everything.

BLASTOR.EXE showrates:
Displays sample rates actually used by Sound Blaster cards with different rounding modes. Sound Blaster cards before SB16 do not support 11025, 22050 or 44100 exactly, but are actually slightly off by about -25..52cents in the most common cases.

BLASTOR.EXE test-dsp:
Uses detection method (2.) from above.
Outputs PCM audio in various stereo and mono modes supported by the detected card. For each stereo modes, it outputs center, left, right in that order.
Note that it already automatically internally swaps the channels on DSP 3.xx (SB Pro). I.e. with original hardware, the actual output matches what is displayed on screen.

BLASTOR.EXE test-opl:
Uses detection method (2.) from above.
Outputs a simple FM synth sound via the OPL2 (pre SB Pro), the Dual-OPL2 (SB Pro 1), or the OPL3 (SB Pro 2 or later). In case the card is stereo-capable (Dual-OPL2 and OPL3), it also outputs center, left, right in that order.

BLASTOR.EXE test-mixer:
Uses detection method (2.) from above.
Tests the mixer (SB Pro or later) by muting one of the stereo channels. Output should be on the channel as displayed on screen (i.e. the other one is muted).

BLASTOR.EXE test-all:
Run test-dsp,test-opl,test-mixer after one another.

BLASTOR.EXE test-sbpro:
Uses detection method (2.) from above.
Runs only the PCM tests relevant for determining SB Pro stereo swapping.
Note that it already automatically internally swaps the channels on DSP 3.xx (SB Pro). I.e. with original hardware, the actual output matches what is displayed on screen.

Again, please *NOTE* that BLASTOR.EXE *DOES* swap the PCM channels on SB Pro (and compatible cards) automatically, thus it will actually output to the correct channels on original hardware, i.e. screen output matches sound output on original hardware. If the description on screen does not match the sound output, the behaviour of the clone card or emulator under testing *DOES NOT MATCH* to behaviour of original SB Pro cards.

Regards,
manx / Mercury^OpenMPT^NEVER

There's defnitely an offset between the L and R channels. There is a single 8bit DAC in the mixer chip which output is switched to L and R at half sample rate clock in stereo mode, so one channel precedes other by half stereo sample/full mono sample. I even remember seeing the switching noise on oscilloscope on the outputs (because there are no real sample+hold capcitors), but I didn't take any captures of it.

OPL3 behaves similarly with YAC512, since there is a single DAC in the chip which output is switched, and no emulator I know of tries to emulate it.

Hi. I just wanted to report that I have this card:
Cobra AOPEN AW744L II - Yamaha XG YMF744 YMF724 OPL3 PCI retro sound card

And noticed reverse PCM stereo in games like Doom, Quake, etc.

I tried SBTEST.exe and SBCHECK.exe

SBTEST.exe gave me R->R
SBCHECK.exe reported SBP2 3.01

I just tried manx's BLASTOR.EXE and indeed, this AOPEN "sb pro 2.0" clone does not mimic the PCM reversal, and thus outputs to the wrong channel.
OPL stereo is perfectly fine.

static- wrote on 2021-07-15, 17:45:

I just tried manx's BLASTOR.EXE and indeed, this AOPEN "sb pro 2.0" clone does not mimic the PCM reversal, and thus outputs to the wrong channel.
OPL stereo is perfectly fine.

Great to hear that my tool also works on at least 1 clone card 😉

Interesting topic. I just tested my OPTi 82C930 card in SBPro mode and here's what I got:

• Jazz: correct
• Quake: reversed
• Doom: reversed
• Duke3D: reversed
• Descent: correct
• SBCHECK: DSP version 3.02
• SBTEST: L -> R
• BLASTOR: DSP correct, OPL correct

I don't have TIE Fighter and F22 so I couldn't test those. On a side note, I just realized that this OPTi card has a very nice low pass filter. Not sure how similar it is to the real SBPro filter, but it sounds great in older games which use 11 KHz samples.

manx wrote on 2021-03-06, 17:04:

Hello fellow Vogons! […]
Show full quote

Hello fellow Vogons!

James-F wrote on 2016-10-23, 14:05:

Summary Using this method: SBPro1 CT1330A, lets solve the Reversed Stereo myth! We have concluded that the SBPro1 CT1330A and SB […]
Show full quote

Summary
Using this method: SBPro1 CT1330A, lets solve the Reversed Stereo myth!
We have concluded that the SBPro1 CT1330A and SBPro2 CT1600 behave exactly the same with PCM audio, so everything besides the Dual-OPL2 is exactly the same.
There is NO stereo reverse issue with the original cards, it's a 30 year myth. 😀

I'm sorry to chime in 5 years later, but I disagree with your conclusion.

Harikiet's SBTEST.EXE outputs a tone on the supposedly *RIGHT* channel. I have verifyed this by tracing the data it actually transmits to the card via DMA by adding appropriate debug output in DOSBox.

Next, I tested SBTEST.EXE on a real SB Pro 2 (CT1600 Rev 05 DSP 3.02). It outputs on the *LEFT* channel.
I also wrote my own cleanroom Sound Blaster test code (attached, with source), which tests all stereo output features of the SB Pro (and other Sound Blasters). Mixer channel (Master, Voice (PCM), Midi (OPL3)) all apply to the correct (as documented in "Sound Blaster Series Hardware Programming Guide") stereo channels. The OPL3 also outputs to the correct stereo channels as documented. However, PCM audio is swapped. It is swapped regardless of whether the 1 byte stereo-init transfer is made or not (the 1 byte stereo-init transfer appears to do absolutely nothing on real SB Pro hardware - this is the same conclusion already known from all the tests done in this and related threads).

Now note that my findings actually match what everyone in this thread has reported with real SB Pro (1 or 2) hardware: SBTEST.EXE outputs on the left channel twice.

It appears to me that the wrong conclusion was drawn because maybe someone somewhere assumed that SBTEST.EXE was supposed to output on the left channel. But it does not. It writes data to the right channel. SB Pro cards output that signal on the left channel though, thus PCM stereo is reversed on these cards. On all of them.

The DOSBox behaviour is still wrong of course, as it does not matter on real hardware whether the 1 byte stereo-init is made, while it matters (and swaps if done) the stereo channels in DOSBox. Also without the 1 byte stereo-init, the initial behaviour of DOSBox is to not swap, which also does not match actual hardware.

For what it's worth, PCem v17 when emulating SB Pro 1 or 2 behaves the same as actual SB Pro hardware. It always swaps the stereo channels, independently of whether the 1 byte stereo-init is made.

I do not care particularly much about SB Pro clone cards. The fact that all known original SB Pro cards appear to swap stereo channels implies that clone cards should have done that too. Would all clone cards have done that, I doubt there would be any confusion by now on whether stereo would be swapped on SB Pro cards. Implementors of output drivers would very likely have noticed the consistent swapping and would have always swapped in software on SB Pro and compatible cards. This obviously did not happen, presumably because some clones did not swap (or because some implementors never tested on actual orignal SB Pro hardware (which may be likely for later titles which also support SB16)). Hence the whole confusion. Some games apply the swapping in software and thus output correctly on an original SB Pro, some do not.

---

There still remains some confusion in 4 areas:

1. Why do some games/programs appear to randomly flip stereo around? I have not investigated that yet, however I guess they might transfer incomplete stereo frames (i.e. an odd number of samples) in a single DMA transfer somewhere sometime. I have noticed such behaviour (transfering incomplete stereo frames) at least with Open CubicPlayer in SB16 mode.
2. The whole stereo-reverse issue could still be timing related, i.e. how fast after the initial 1 byte stereo-init does the real DMA transfer start, or how long does it take to restart DMA in single-cycle DMA mode (in auto-initialized DMA mode the latter issue does not exist), and how may a longer pause between DMA transfers interact with transfer of incomplete stereo frames?
   However, given that

   xeoblade wrote on 2017-02-24, 08:23:

   Not sure if I should resurrect this older thread but since I recently picked up a Rev 2 CT1330A I thought I would add my results […]
   Show full quote

   Not sure if I should resurrect this older thread but since I recently picked up a Rev 2 CT1330A I thought I would add my results to the list.
   SBCheck:
   DSP version 3.01
   Sound Blaster Pro 1 Stereo 8-bit board... use SBPro.ADC driver.
   SBTest:
   1. I heard the tone out of the left speaker, and if I turned the volume up I could hear something out of the right.
   2. Heard the same tone/sound from the same speakers in the second part.
   It is currently placed in a 386 dx/40 machine so it has a hard time with "newer" dos games. I have a few other machines I could put it in (486, Pentium) so if you think it would help with the cause I could do that.

   was found on a machine on the slower spectrum from the SB Pro era, I somewhat doubt anything related to timing of the machine itself. It could still be timing dependent on the actual driver code, like, if it goes around and does something else completely, after sending the 1 byte stereo-init.
3. Is there a phase difference of 1 sample between left and right channels due to swapping on original SB Pro (i.e. does it actually swap channels, or does the output "eat" 1 sample from one of the channels without actually outputting it)?
4. Is there always a phase difference of 0.5 samples between left and right channels due to the way original SB Pro mixer "filters" the DSP output signal?

(3.) and (4.) may be hard to even measure, given the abysmal noise floor and stereo separation of the SB Pro.
Also note that (3.) would only be measured properly if the code that does the output is known *precisely*, because it is necessary to know if it swaps stereo, or skips 1 sample of one of the channels, or does neither. In particular, output using any Windows program would depend on the Windows SB Pro driver and would not yield any conclusive result here.

---

BLASTOR.EXE documentation:

Use at your own risk. It has only been tested in DOSBox, PCem, an AMD K6-3 400/66 (i430HX) + SBPro2 system, and a Pentium 2 + AWE64 Value system.

BLASTOR.EXE requires the contents of csdpmi7b.zip from DJGPP in the same folder, and XMS memory to run.

Also, since this is only the second time ever that I tried DOS hardware programming, it also probably contains bugs.

BLASTOR.EXE detect:
Performs Sound Blaster detection and outputs what it finds in 3 consecutive runs:

1. Only looks at the BLASTER variable.
2. Looks at the BLASTER variable and does additional auto-detection and verification.
3. Does not look at BLASTER variable and probes for Sound Blaster cards.

(3.) may actually crash or lock up a system if other hardware is installed at the addresses the code tries to probe. It also might mis-detect the interrupt if other hardware is in active use and uses that interrupt (traffic on a network card is a likely cause here).
This outputs more data than fits on a 25 line screen, use "| more" or a highres text-mode if you want to see everything.

BLASTOR.EXE showrates:
Displays sample rates actually used by Sound Blaster cards with different rounding modes. Sound Blaster cards before SB16 do not support 11025, 22050 or 44100 exactly, but are actually slightly off by about -25..52cents in the most common cases.

BLASTOR.EXE test-dsp:
Uses detection method (2.) from above.
Outputs PCM audio in various stereo and mono modes supported by the detected card. For each stereo modes, it outputs center, left, right in that order.
Note that it already automatically internally swaps the channels on DSP 3.xx (SB Pro). I.e. with original hardware, the actual output matches what is displayed on screen.

BLASTOR.EXE test-opl:
Uses detection method (2.) from above.
Outputs a simple FM synth sound via the OPL2 (pre SB Pro), the Dual-OPL2 (SB Pro 1), or the OPL3 (SB Pro 2 or later). In case the card is stereo-capable (Dual-OPL2 and OPL3), it also outputs center, left, right in that order.

BLASTOR.EXE test-mixer:
Uses detection method (2.) from above.
Tests the mixer (SB Pro or later) by muting one of the stereo channels. Output should be on the channel as displayed on screen (i.e. the other one is muted).

BLASTOR.EXE test-all:
Run test-dsp,test-opl,test-mixer after one another.

BLASTOR.EXE test-sbpro:
Uses detection method (2.) from above.
Runs only the PCM tests relevant for determining SB Pro stereo swapping.
Note that it already automatically internally swaps the channels on DSP 3.xx (SB Pro). I.e. with original hardware, the actual output matches what is displayed on screen.

Again, please *NOTE* that BLASTOR.EXE *DOES* swap the PCM channels on SB Pro (and compatible cards) automatically, thus it will actually output to the correct channels on original hardware, i.e. screen output matches sound output on original hardware. If the description on screen does not match the sound output, the behaviour of the clone card or emulator under testing *DOES NOT MATCH* to behaviour of original SB Pro cards.

Regards,
manx / Mercury^OpenMPT^NEVER

Maybe a bit late. Am currently trying to get the stereo support working in my own emulator.
Right now, each DSP command latches the input/output stereo bit and (re)starts input/output on the left channel (up to Pro II emulated). I notice that the left and right channels are swapped, at least with the official test-sbp.exe supplied on the official driver disk). It reports the same DSP version numbers as Dosbox does to the software.

Any idea how the stereo latch works on a real DSP and mixer? I assume for input mode (recording), the DSP itself controls the left/right channel latch, so there's no issue there.
I think maybe the mixer chip itself initializes and keeps track of the left/right channel being output by the DSP (each DMA transfer)?
If the mixer controls the left/right channels entirely, that would mean the DSP is simply dumbly sending mono samples, even in stereo mode.
So how is the mixer 'initializing' the left/right latches state machine? Is it always setting the right sample latch active for writes whenever the stereo bit is toggled from 0 to 1? Or is it taking some other hints from hardware to do this (dumb write to the mixer register by software or some dedicated control lines communicating from the DSP)?

It is the mixer that does all of the LR switching but what is the condition that resets it to a specific state I don't know, I assume it is the act of setting the stereo/mono bit in it but I have never tested it myself.

From DSP standpoint there's no difference between stereo and mono, other than stereo has twice the samples and it is what leads to half the sample rates capability in stereo mode, since the DSP can still only push x amount of samples in y time unit.

Tiido wrote on 2025-08-11, 14:56:

It is the mixer that does all of the LR switching but what is the condition that resets it to a specific state I don't know, I assume it is the act of setting the stereo/mono bit in it but I have never tested it myself.

From DSP standpoint there's no difference between stereo and mono, other than stereo has twice the samples and it is what leads to half the sample rates capability in stereo mode, since the DSP can still only push x amount of samples in y time unit.

For now I've simply implemented it as follows:
- Setting the stereo bit to 1 enables the stereo functionality (when starting a new streaming command, like 0x14 etc.). Unlike the official documentation I can find, it will start on any input/output command (so even 14h, even though documentation only specifically mentions stereo support on the "high speed" DMA commands (90h/91h/98h/99h commands))). Clearing it disables said functionality in the mixer.
- Flipping the stereo bit from 0 to 1 in the mixer causes it to set the output channel for the next received mono sample to the right channel.
- The DSP simply uses said settings to render to left/right using the flipflop (the output channel) or both channels. If the flipflop is used, it isn't initialized when starting a DMA command (running status). When not used (mono mode), the state is kept the same (but that doesn't matter, as enabling it again causes it to flip to the right channel (set) state).

Oddly enough, the documentation I found (https://pdos.csail.mit.edu/6.828/2005/reading … oundBlaster.pdf) only seems to mention the high speed mode being capable of stereo output? But the diagnostics software (test-sbp.exe) seems to use command 14h instead?

The actual hardware has one single 8bit DAC inside the mixer chip, which output connects to two switches that split it into L and R channels. In mono mode, both switches are closed and DAC output is sent to both L and R outputs but in stereo mode only one switch is closed at a time, and switching appears to be controlled by writes to the DAC input (and I think write to the stereo/mono bit). If you hook up an oscilloscope to the L and R outputs on the mixer you can even see this switching and one channel being one sample offset from the other when stereo mode is enabled. DSP should be fully unaware of the stereo/mono state and it simply writes samples one after other, with mixer doing rest of the magic fully autonomously. As such, all commands should work in stereo.

Tiido wrote on 2025-08-11, 15:27:

The actual hardware has one single 8bit DAC inside the mixer chip, which output connects to two switches that split it into L and R channels. In mono mode, both switches are closed and DAC output is sent to both L and R outputs but in stereo mode only one switch is closed at a time, and switching appears to be controlled by writes to the DAC input (and I think write to the stereo/mono bit). If you hook up an oscilloscope to the L and R outputs on the mixer you can even see this switching and one channel being one sample offset from the other when stereo mode is enabled. DSP should be fully unaware of the stereo/mono state and it simply writes samples one after other, with mixer doing rest of the magic fully autonomously. As such, all commands should work in stereo.

So basically, the stereo works as follows:
- Setting the stereo bit writes mono samples to one of the two channels. The write itself flips the flipflop in stereo mode. The flipflop is ignored in mono mode and writes affect both latches instead.

But it somehow needs to initialize said switches for the right channel when processing the toggling (from 0 to 1) or simply write with value being 1 (from 0 to 1 or from 1 to 1) to close the right switch and open the left switch? What triggers this 'initializing' behaviour? It can't be the DSP, as it has no clue about the mixer doing this at all (it knows nothing about stereo behaviour apparently).

How does the mixer then initialize those switches? Does it set the right switch closed and left switch open each time the mixer's stereo register is written? Or only when the stereo bit goes from cleared to set state (which would make more sense, as you don't want the latches to reinitialize when you change other bits in said register or write the same value into it)?

Right now I have my emulator setup to simply close the right switch and open the left switch (thus next sample into the right switch) whenever it detects that the stereo bit goes from a cleared to a set state (writing a set bit while it was already set has no effect).

It at least seems to work properly with the TEST-SBP.EXE diagnostic software in my emulator right now. Ran the samples multiple times and each time it goes clean from left to right (a water sound moving between the speakers).

Recording mode (w/ speaker off) is always synchronized, due to the DSP itself performing the stereo in that case (commands A0h(mono)/A8h(stereo)).

What then simply happens during the test-sbp.exe stereo part:
- Sends some initialization for playback.
- Sets the stereo bit from 0 to 1, triggering the right channel to become ready for receiving new data.
- Sends a single sample to the right channel. Thus left channel becomes next.
- Sends the remaining samples to play, starting with the left sample (normal DAC playback in documented stereo L,R,L,R.... format)
- Repeating the above as many times as needed.
- Cleans up playback and stops it.
- Clears the stereo bit before returning to the main test menu.

I can run the DSP test as many times as I like, each time I get the correct stereo sounds on the correct speakers.

Unfortunately I can't run some of the mentioned test software, due to requiring FPU support (Duke Nukem 3D) I think? Or can it run on a 486SX (actually more like Pentium II w/o FPU or MMX instructions in it's current implementation)?
And my CPU emulation has some V86 mode bugs it seems, so EMM386 won't load correctly right now on current commits (busy on fixing that issue right now). So also can't test on Wolfenstein 3D either right now (it simply hangs when starting with 'please wait' at the bottom (or whatever it's saying when loading, but permanently)).

It isn't so much that there is specific writing of samples to the left or right output but that sample goes to one singular DAC always, and it is the output of the DAC (which changes the instant of every sample write by DSP), the actual analog signal, that is selectively connected to L or R outputs. The stereo output itself is all analog domain, and only digital part is the logic that controls how the switches are going on or off.

The only thing that makes sense for resetting of that channel select flip flop is the actual stereo/mono bit write in the mixer. I imagine that during a write the FF is made to go to a default state (and if the write is mono mode, then output switches are always on and FF output plays no role, although the FF probably still flips every sample write since it takes less logic to do it that way).

Perhaps if the stereo/mono bit is set at a wrong time, there could be glitches that cause a runt pulse that ends up clocking the FF and make channel order reverse ? I am not sure why some things suffer from swapped channels and others do not... I have never actually tried to see what games themselves do with the hardware, since that is not so easy to orchestrate with just an oscilloscope 🤣. I now do have a logic analyzer capable of giving me anything I want from ISA bus or the sound card itself, but the focus of my efforts has been completely elsewere for a while since I last actually looked at what the mixer chip is doing on a SB Pro2... But maybe there is something in software that gets in the way. As far as Duke3D goes, you can use its Setup program even on a 386. It is only the main game that wants 486 and only because of BSWAP instruction. FPU is not necessary for main game but anything with slopes in-game runs really slow without the FPU.

This is where my knowledge ends, I hope you can run some of those other things and see what they do. Maybe there's a pattern to the problem.

Tiido wrote on 2025-08-11, 20:39:

It isn't so much that there is specific writing of samples to the left or right output but that sample goes to one singular DAC […]
Show full quote

It isn't so much that there is specific writing of samples to the left or right output but that sample goes to one singular DAC always, and it is the output of the DAC (which changes the instant of every sample write by DSP), the actual analog signal, that is selectively connected to L or R outputs. The stereo output itself is all analog domain, and only digital part is the logic that controls how the switches are going on or off.

The only thing that makes sense for resetting of that channel select flip flop is the actual stereo/mono bit write in the mixer. I imagine that during a write the FF is made to go to a default state (and if the write is mono mode, then output switches are always on and FF output plays no role, although the FF probably still flips every sample write since it takes less logic to do it that way).

Perhaps if the stereo/mono bit is set at a wrong time, there could be glitches that cause a runt pulse that ends up clocking the FF and make channel order reverse ? I am not sure why some things suffer from swapped channels and others do not... I have never actually tried to see what games themselves do with the hardware, since that is not so easy to orchestrate with just an oscilloscope 🤣. I now do have a logic analyzer capable of giving me anything I want from ISA bus or the sound card itself, but the focus of my efforts has been completely elsewere for a while since I last actually looked at what the mixer chip is doing on a SB Pro2... But maybe there is something in software that gets in the way. As far as Duke3D goes, you can use its Setup program even on a 386. It is only the main game that wants 486 and only because of BSWAP instruction. FPU is not necessary for main game but anything with slopes in-game runs really slow without the FPU.

This is where my knowledge ends, I hope you can run some of those other things and see what they do. Maybe there's a pattern to the problem.

Why would it even use the BSWAP instructions? It's mostly used for endianness changes, isn't it? And only 32-bit ones at that (16-bit BSWAP is undefined (non-swapping, basically just a clearing behaviour, due to being a 32-bit BSWAP truncated to 16-bits(actually zero extend to 32-bits, 32-bit BSWAP and store the low 16 bits back (being zeroes from the sign extension))) behaviour, if it does anything at all).