VOGONS


SBPro1 CT1330A, lets solve the Reversed Stereo myth!

Topic actions

Reply 100 of 108, by CkRtech

User metadata
Rank Oldbie
Rank
Oldbie

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.

Displaced Gamers (YouTube) - DOS Gaming Aspect Ratio - 320x200 || The History of 240p || Dithering on the Sega Genesis with Composite Video

Reply 101 of 108, by carlostex

User metadata
Rank l33t
Rank
l33t

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.

Reply 102 of 108, by CkRtech

User metadata
Rank Oldbie
Rank
Oldbie

Thumbs up.

Displaced Gamers (YouTube) - DOS Gaming Aspect Ratio - 320x200 || The History of 240p || Dithering on the Sega Genesis with Composite Video

Reply 103 of 108, by Jepael

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

Reply 104 of 108, by CkRtech

User metadata
Rank Oldbie
Rank
Oldbie

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:

ampoutput.jpg
Filename
ampoutput.jpg
File size
49.59 KiB
Views
273 views
File license
Fair use/fair dealing exception

"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.

Displaced Gamers (YouTube) - DOS Gaming Aspect Ratio - 320x200 || The History of 240p || Dithering on the Sega Genesis with Composite Video

Reply 105 of 108, by Jepael

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 106 of 108, by shamino

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

Reply 107 of 108, by manx

User metadata
Rank Newbie
Rank
Newbie

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

Attachments

  • Filename
    blastor.c
    File size
    89.43 KiB
    Downloads
    6 downloads
    File comment
    source (0.0.5-pre.12.vogons.4)
    File license
    Public domain
  • Filename
    BLASTOR.EXE
    File size
    1.11 MiB
    Downloads
    5 downloads
    File comment
    binary, requires contents of csdpmi7b.zip from DJGPP
    File license
    Public domain

manx / mercury^openmpt^never
asus t2p4c, amd k6-3 450 @400/66mhz, 3dfx voodoo banshee 16mb, sbpro2 + cmi8378 + ews64xl

Reply 108 of 108, by Tiido

User metadata
Rank Oldbie
Rank
Oldbie

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.

T-04YBSC, a new YMF71x based sound card & Official VOGONS thread about it
Newly made 4MB 60ns 30pin SIMMs ~
mida sa loed ? nagunii aru ei saa 😜