1Index: src/hardware/sblaster.cpp
2===================================================================
3--- src/hardware/sblaster.cpp   (revision 3778)
4+++ src/hardware/sblaster.cpp   (working copy)
5@@ -591,6 +591,11 @@
6        sb.mode=MODE_DMA_MASKED;
7        sb.chan->FillUp();
8        sb.dma.left=sb.dma.total;
9+       if(sb.dma.remain_size == 1 && (sb.dma.left&1) == 0) {
10+               //Mixing even and uneven data.
11+               //Resetting uneven handling
12+               sb.dma.remain_size = 0;
13+       }
14        sb.dma.mode=mode;
15        sb.dma.stereo=stereo;
16        sb.irq.pending_8bit=false;

Slightly more protection. Ideally we would be able to test it on real hardware though.

I think an odd/even check is not applicable if the new transfer is mono; you could test for that as well, but it recalls the point I made earlier in this thread that it seems wrong to preserve a leftover sample when starting a new transfer that could be for a completely different sample type.

FWIW, over the past ten months or so I have tested the reset-to-zero modification on every game I've run with my debug build of DOSBox and heard no anomalies. I guess you would call it passive rather than active testing because I wasn't specifically looking for a problem related to modification, but I'm sure I would have noticed if there were any. The only difference I've noted is that games using the Miles SB16 driver do not have inverted stereo channels.

You mean zeroing the remain_size var unconditionally? Somebody poke Harekiet.

Another thought mentioned by Qbix, possibly having come from Harekiet, is to "round off" an uneven stereo transfer. That also sounds like the kind of uninvolved logic that a DSP might use, but the specifics of how to do the rounding off seem more involved than the reset-to-zero approach.

There are a lot of DSP versions unfortunately.
Might make sense to bind it to the emulated soundblaster type.

Are there some DSP versions in which the stereo swap actually occurs, or is it only the DOSBox emulation that suffers from this?

I have read that the earliest SB Pro models had a DSP bug where the first sample into the buffer would be "lost", causing channel swapping; but it was fixed in later SB Pro models.

I understand the purpose of the remain_size when there is an ongoing transfer, but I don't understand why it should affect a new transfer. Is there a known problem case where that behavior is shown to be needed?

This approach targets the Miles SB16 driver issue by zeroing remain_size at the end of a single-cycle 16-bit stereo transfer with a size of 1:

1     if (!sb.dma.left) {
2         PIC_RemoveEvents(END_DMA_Event);
3         if (sb.dma.mode >= DSP_DMA_16) SB_RaiseIRQ(SB_IRQ_16);
4         else SB_RaiseIRQ(SB_IRQ_8);
5         if (!sb.dma.autoinit) {
6             LOG(LOG_SB,LOG_NORMAL)("Single cycle transfer ended");
7+            if (sb.dma.mode == DSP_DMA_16 && sb.dma.stereo && sb.dma.total == 1) sb.dma.remain_size = 0;
8             sb.mode=MODE_NONE;
9             sb.dma.mode=DSP_DMA_NONE;
10         } else {
11             sb.dma.left=sb.dma.total;
12             if (!sb.dma.left) {
13                 LOG(LOG_SB,LOG_NORMAL)("Auto-init transfer with 0 size");
14                 sb.mode=MODE_NONE;
15             }
16         }
17     }

It leaves remain_size to do whatever it was doing before except in the very specific condition.

Yeah I think that makes sense, new transfer most likely always resets that. HAREKIET WAKE UP.

I was just waiting for you to make some test application wd 😀

Nah need some Harekiet-heuristics that should do it!

Made a little test app that plays 8bit stereo with and without a single byte start transfer.

On my sb16 it plays the sound both times on the right side. In dosbox it switches from right to left.
Someone with a real sbpro should test it. I found some documentation that when starting a stereo transfer they recommend always doing a single cycle transfer first with stereo enabled in the mixer. So I'm wonder if the sbpro defaults to playing the right channel first when playing stereo. Then when they made the sb16 they defaulted the first sample played to be on the left side.

As far as i know the whole stereo playing on the sbpro is handled by the mixer and the dsp is pretty much unaware of it so it would make sense that when the mixer is in stereo mode and you play only a single byte it just reverses the channes. But on the sb16 the whole stereo output was moved into the dsp so there it doesn't care about the mixer settings anymore.

Seems the best solution is just to remove all the remain bytes stuff and just default to left/right byte order. Optionally we could add some functionality in the mixer commands that would allow you to swap a specific channel

Sorry to dig up this old message thread, but...

rfnagel wrote:

I wish I could remember exactly which games that they were, but I do remember finding a couple that had that problem.

I recently started playing Epic MegaGames' "Silverball" (and "Silverball Plus 2") again... and I NOW finally remember that being one of the games that has the swapped channel problem. Not only did that game (and it's sequel) exhibit that problem in DOSBox, but it also suffered from the problem on a REAL SBPro (AFAIK, an SBPro 2), an SB16, and an AWE32 sound card.

BTW, Ripsaw8080's older compiled DOSBox v0.72 patch worked (sounded) fine with "swapstereo=true" in my "DOSBox.conf" file 😀

Are there any plans of incorporating that feature in a future update of DOSBox?

(Edit) P.S. FWIW, "Silverball" and "Silverball Plus 2" used Epic MegagGames' older/original MASI sound drivers, as did the first incarnation of "Epic Pinball" as well.

That problem was fixed with Epic MegaGames' newer (and higher quality sounding) MASI sound drivers in one of the updates to "Epic Pinball" (although, they ONLY updated "Epic Pinball", not "Silverball" or "Silverball Plus 2").

I think the official addition of a swapstereo config option would be met with universal acclaim.

My only concern is that it shouldn't swap channels for the entire mixer.

P.S. A few files for testing...

Epic MegaGames' "Silverball" playable demo (uses Epic MegaGames' *OLDER* MASI sound drivers):
http://archive.org/details/Silverball_1020
http://archive.org/download/Silverball_1020/silvdemo.zip

Epic Pinball shareware version "Android" pinball table (uses Epic MegaGames' *OLDER* MASI sound drivers):
ftp://ftp.princeton.edu/pub/clk/pc/dos/games/0pinball.zip
http://cd.textfiles.com/ems/emspro20/disk4/GA … ES/0PINBALL.ZIP

Epic Pinball shareware version "Super Android" pinball table (uses Epic MegaGames' *NEWER* MASI sound drivers):
ftp://ftp.nl.freebsd.org/pub/ftp/games/pinbal … re/pinball2.zip
ftp://ftp.fi.netbsd.org/pub/msdos/games/epic/pinball2.zip

Simply start any of the above in DOSBox, begin a game on the first pinball table listed in the games' main menu. Then press the left and right SHIFT keys (left flipper and right flipper).

For the games that use the *OLDER* MASI sound drivers you'll hear the flipper clicks/sound effects in the wrong speaker. For the game that uses the *NEWER* MASI drivers the sound for the flippers will be heard out of the correct speakers.

In Warcraft 2, the sb*.mid files also reverse the stereo channels for music as in the sound for the sb*.dig files. Is it possible to patch a sb*.mid file? I used midi and gus as a reference.

How would MIDI music be reversed in Warcraft 2 on Sound Blaster? It's certain to use OPLx for music and not the DAC.

I would also love to see swap stereo support.

To support my setup with inverted seating for games vs movies I ended up having to physically swap my speakers and then reverse the audio in my media player (i.e. Media Player Classic) the one app that allowed swapping audio channels. I don't understand why audio drivers no longer seem to commonly support it, I remember having a driver option for it in the past but can't remember with what.

You could wrap dosbox into a VST instrument with separate virtual output for each dosbox soundcard. Then run dosbox inside say Reaper, so you can then use the Reaper parametric EQ and various stereo width/invert etc plugins.

This would also get you ASIO support through the VST host (reaper) so you could use DOS synths with low latency.

Bump.

DOSBox has its SBPro Stereo reversed to the real SBPro CT1600 with sbpro1 and sbpro2 settings.
Why would DOSBox emulate the rare and far less common SBPro1 CT1330A stereo configuration?
Doom, which is the most popular DOS game in history is REVERSED in DOSBox with any SBPro settings.

At least give the user some option to change between sbpro1 and sbpro2 stereo behavior, right now dosbox is locked to the reversed sbpro1.
It should affect only the SBpro digital sound not SB16, so the patch posted a few years ago that affects all 8bit sounds is not a good solution.

Harekiet wrote:

Made a little test app that plays 8bit stereo with and without a single byte start transfer.
SBTEST.EXE

On a real SBPro2 CT1600 Rev.06 this plays twice on the LEFT side (SBPro2 DSP v3.02) ---> Creative fixed the bug.
AudioDrive ES1688, twice on LEFT as with the CT1600.
Aztech NX Pro, twice on RIGHT (Reports as SBPro1 DSP v3.01).
YMF719 and Aztech MM Pro 16 (newer), First LEFT then RIGHT (SBPro2 DSP v3.01) ---> This explains the Quake reverse stereo with these cards and DOSBox.
On a real SB16 CT2230 it plays twice in the Center (DSP 4.13).
DOSBox, first RIGHT then LEFT.

Looking at the chart it is obvious that Quake and Little Big Adventure sends an extra byte to flip the stereo at start like SBTEST.EXE does, but all other software leave that choice to their setup utilities.
But in DOSBox Quake is not reversed although it should be.... I wonder what is the reason for that.
Latest revisions of the SBPro2 CT1600 don't care if an extra byte is sent, it will always play from the first sample of the new PCM data stream.

I attached a small soft SBCHECK which tells what card it is and what DSP.

EDIT: actually CT1330A is no different to the CT1600, rad next post...