🚀 go-pugleaf

This is a bit of a long one.  Basically, with some sound cards & their
respective drivers (in Win2k), the cursor positions in my DirectSound app go
nuts and don't work right, but with other cards and drivers, using the same
app, it all works fine.  Here's the excruciating details:

I'm building a app in VB6 / DX8 that's going to function as "hands-free"
medical dictation software.  The user's got a set of footpedals, one for
playback & one for recording.  User pushes the record pedal, I start
capturing to a directSound capture buffer @ 11Khz 8bit mono, and when they
let off the record pedal I dump what they just recorded into a
secondaryBuffer of the same freq/bit/channel, which they can subsequently
listen to with the playback pedal.  There's a bit of cursor positioning
going on & logistics of emulating the behavior of a tape machine, but those
details aside, it's a fairly straightforward process - a capture buffer, and
a playback buffer.  And the app works ~flawlessly~ on a few of the random
PCs here around the lab running Win2K... until I installed it on this one:

AMD Duron @ 1100~ish MHz
Microstar MS-6340 motherboard (ver. 5)
onboard VIA "AC97"? sound
256Megs PC133 RAM
Win98 se

When running my app, this config crashed & gave me blue screens in an
entirely inconsistent, yet persistent fashion.  It was deemed to be,
clearly, "unstable".  We have 2 of these machines, and they both exhibit
identical behavior with my app.  After checking DX version & dxdiag (which
were fine), I simply replaced the OS with Win2K, since other PCs ran my app
perfectly under 2K, I figured that would be an easy solution =P  Such was
not the case.

Under Win2k, I no longer have blue-screens or blatant instability, but the
app just behaves... funny.  I think cursor positioning has gone wacko.  It
cuts off ends of sentences when user records (unable to determine cause -
either .lWrite cursor in secondaryBuffer "rolling back" when data is copied
into it via the readBuffer method, or, .lWrite cursor rolling back to far
when the .stop method is invoked on the capture buffer).  Assumed this to be
a driver issue with onboard sound device, so disabled onboard sound and
installed OEM Sound Blaster Live! (model CT4760) & latest Win2K drivers from
creative.com.

Behavior becomes increasingly sporadic with the SoundBlaster card.  Unable
to playback sound (regardless of SetCurrentPosition, the secondaryBuffers
.lPlay cursor "jumps" to the end of the buffer when .Play is invoked),
invoking .Start on the ~capture~ buffer also causes the secondaryBuffer
cursor to move significant distances, generally to the end of the buffer.  A
sort of buffer mayhem was certainly going on, and turning down HW
acceleration in multimedia props could calm this down a bit, so that playing
and record could at least be achieved in a sensible manner.  However,
problem with "end of words being cut-off", i.e., .lWrite cursor roll-back,
either in capture or secondaryBuffer, remained a problem.  Turning HW
Acceleration completely off slows the app down to unusable speeds, creates
too much delay when pushing on pedals (however, there appear to be no cursor
problems if you're patient enough to play around with it in a lagged state,
it "works" fine, it's just very slow to respond to start/stop methods).

SB Live model CT4760 is a tad old, so suspecting semi-aged SB Live card,
removed CT4760, purchased new SB PCI 512 card (SB0150, I believe) -
installed latest drivers from creative.com.  Identical results to the
CT4760.  Sporadic, incorrect buffer cursor behavior with HW acceleration
turned up, cuts off ends of sentences with it turned down to minimum, and
works ok yet unusably slow with HW Accel turned off.

Removed SB0150, installed a 3rd card - yet another SB product, this one a
presumably OEM Live! pulled from a Dell, model CT4780.  Installed latest
drivers from creative.com and the result?  App works perfectly!  I can have
HW Accel set to any position that isn't "off" and all cursor positions in
buffers are exactly as they should be in my code, and as such, program works
just fine.  (This one baffles me!).  In summary, it works just fine with an
SB Live CT4780, but is squirrelly with an SB PCI 512, an SB Live CT4760, or
the motherboards on-board sound.  Frustrating!

Apparently the OEM SBLive! CT4780 is a specific OEM card for Dell and not
directly obtainable by consumers, but I would really, really, really like to
FIX what is going on, and save having to replace these 2 boxes.  In fact, I
feel somewhat helpless that DS methods simply aren't being executed properly
by the soundcard... what can I even do about that?

I'm getting very close to replacing 2 workstations simply because I can't
seem to find a (realistically obtainable) hardware/driver combination that
works with my DS8 app :\  I really assumed a brand-new SoundBlaster card
would function properly when given simple DirectSound instructions!  The
only methods I'm using are .stop, .start, .play, .setcurrentposition and
.getcurrentposition.  Using HW acceleration, these methods don't work
properly with 2 out of 3 soundblaster cards I've tried under win2k...

I can't figure this one out...  I can post code, additional system specs,
etc if anyone's got any ideas.