Re: Invert Left/Right Audio Channels Stereo Sound?

Which was to expect 😀

However that is fine now i can test if my hack is proper because i'm not sure, the SB16.DIG gave me some headache before i found out how to reverse stereo without to swap signed / unsigned. The SBPRO was quite easy and it was very obvious where to swap the channels and it worked out immediately.
But after i recognized that i had to do it different for the SB16 i'm not sure anymore because i assume it should be done in exactly the same manner but i can err.

My fault that i didn't searched for a solution but i didn't expect such brutal hacks here.

ripsaw8080,
Do you got an idea why the SB16 driver (or the player when on a sb16 board) opens with an audible click only on the left channel while the SBPRO won't do that?
And maybe one how to fix that?
It's annoying, it's the only strong drawback of DIGPLAY for my use, it is horrible if every little sfx i use in such a batch like shown in my previous post starts with such a click noise.

Also about the offset of DIGPLAY i'm not very happy, i accept it but it's somehow tard because it's DIGPLAY specific and the samples are by roundabout tenth of a second to long for other players which leads to noise at the silent end of the sample if it's an 8bit sample, which results in that the sfx samples are DIGPLAY specific.
Also this leads to the fact that DIGPLAY can't play a sample shorter as roundabout two tenths of a second, respectively if it's shorter it won't play anything because of the offset.
I.e. a recorded "Go!" is shorter as two tenths of a second if you don't add ~15 1/100 to it won't play back "go".

The worst thing i can imagine is to use a different player such as "PLANY" and to playback only mono samples, nah not the worst but it would be sad.
On the other hand a TSR (plany isn't) could be handy because the batch will proceed while the sfx is played, it's obvious every such TSR plays back only mono, 11kHz, 8bit samples to preserve memory.
Overall using a TSR should be prevented if not really needed even if we don't have to care for DOSBox as much as for a real DOS machine.
Already use of the GUS "Playmidi" as TSR can be problematic, how to terminate the TSR in a batch? there is no "-q(uit)" switch to terminate the TSR and they chose a stupid
key press which can't be virtualized, "left shift + right shift" to terminate the TSR.
I have to use a program to mark the TSR and then release it from memory if i need this i.e. to playback a midi while a GIF animation is running but the music has to end with the animation no matter if it ends naturally or if you quit the anim with a key press.
This brutal termination leads to a still open GUS port which plays the last note endless until you silent this with another call of "playmidi" by playing back an empty midi or a sysex.mid (in my case, i have them ready for several purposes mainly to program the MT-32 to GM).

Due to small differences some TSR produce wrong results in DOSBox, i.e. for FE2 exists a "FFE blacksky" TSR

This TSR often fails while playing and it became useless in DOSBox (my last real doze was a siemens laptop there it worked proper).

Gernot66 wrote on 2020-02-16, 12:01:

Do you got an idea why the SB16 driver (or the player when on a sb16 board) opens with an audible click only on the left channel while the SBPRO won't do that?
And maybe one how to fix that?

My fix program didn't bother with the click/pop because it only happens when the SB16.DIG driver is initialized, and in the typical game that only happens once at startup, but I can see how it'd get annoying in your use case.

The way I fixed the swapped channels is to change the initialization transfer to use 2 samples instead of 1 -- it is a stereo transfer, after all, and the odd transfer size is what triggers the swap. Using my 2-sample approach, the pop can be eliminated by changing the samples used in the initialization transfer. For example, you'll find code like this in SB16.DIG, though the addresses may vary between different versions of the driver:

1MOV [05BD],80
2MOV [05BE],80
3MOV [05BF],80
4MOV [05C0],80

Those would be good signed samples for "center" *IF* the transfer was 8-bit. However, it's a 16-bit transfer, and center is 0x8000 not 0x8080. So, the pop is eliminated by changing to this:

1MOV [05BD],00
2MOV [05BE],80
3MOV [05BF],00
4MOV [05C0],80

Well, I can say it works in my use case, which is games, but I haven't tried it in your use case. 😉

hey thanks ripsaw for the prompt reply.

Yes they do differ a bit, this i can tell from far.
the SB16 driver i hacked looks like this:

1MOV [0479],80
2MOV [0487],00
3MOV [0495],00
4MOV [04A3],00

by looking at you suggestion i can see now why it appears only on the left channel.
I was suspecting something is wrong because the value won't repeat and a single difference out of four makes no sense it has to be a pair.
Strange-wisely this driver should be the latest release of the AIL3 drivers (should).
It isn't hacked, the first version of DIGPLAY i downloaded from an open source project for a revamp of an old dos game.
But i have also downloaded once a pack of drivers plus the two players from a different source in which different versions of the AIL3 drivers are present and this is marked as "newest". Both drivers are identical, but of course many games use them and of course the releases will differ.
If i get this right one can take the "default" drivers which was done mostly or build specific ones from the source (at least this was the case for john miles ail2).
What caused the small difference and what the initial purpose was if it's not just an error i don't know.
Because even the value at the address before (sorry after) isn't the same for all four even here the first differs from the rest.

100 00 00 11 2B 22 56 44 AC 80 00 00 40 00 00 00 
200 11 2B 22 56 44 AC 00 02 00 40 01 00 00 00 11 
32B 22 56 44 AC 00 02 00 40 00 00 00 00 11 2B 22 
456 44 AC 00 02 00 40 01 00 00 00 00 00 00 00 00 

However, thx again for your work because with this at hand i should be able to solve the tiny problems i have.

Gernot66 wrote on 2020-02-16, 13:59:

[…]
Show full quote

Copy code to clipboard

1MOV [0479],80
2MOV [0487],00
3MOV [0495],00
4MOV [04A3],00

That looks even worse than original for 16-byte samples, because it's 0x0080 not 0x8000. Remember that PCs are little-endian for most things. 😀

Edit: oh, those addresses aren't sequential, so I'm not even sure what I'm looking at. 😒

(caugh) your patch didn't warns if the driver has different addressing?
If i patch this specific version of the SB16 driver nothing happens except that the date of last change is updated, the driver itself stays unaltered.
No problem so far i just liked to compare them i still can do this with a different release.
So far to your request for different releases of the driver this seems to be one.

triple caugh 😀
Dunno but if apply your patch to the driver which was shipped with "Albion" it alters a single value at a complete different address.
It does the trick no question using this patched driver stereo is proper l/r.
Probably i misunderstood something because i assumed the patch alters the stereo similar as i hacked it.
That it is probably not the best way or can cause troubles i expected.
"There is more then one street which leads to rome" (of course and we are on the broadest way to decadence)

Like i stated my first hack was on the SBPRO driver, here i found solution very quick based on this i altered the SB16 driver.

I guess it's safer to use your patch as my hack.
an update will follow soon, just for those who like to use DIGPLAY as standalone sample player.

To your last post; well, i'm not responsible for this 😀
This specific version of the SB16 driver is to find i.e. in "zork" (which i downloaded only for a comparison because i noticed it includes not only the drivers but also the player)
But i assume in other games of the same period to.
Part of the "miles sounddriver" pack i downloaded and marked as "newest", even part of the named open source project. ("A Tool to Help the Creation of Warcraft III Map")

I'm not sure (as usual) but something is very obvious, the version i found in "Albion" (patch able) leaks of the "RAD Game Tools ..." string there is only gibberish to read, while the "unusual" (patch unable) version includes the copyright string. It won't tell much except that the version leaking of the copyright string was probably shipped with RAD Game Tools (RAD won't have to state the copyright holder) while the ones including the copyright string are compiled from source (anyone who compiles it from source has to state the copyright holder in any case).

Most probably it's vice versa? it seems the ones i downloaded are the original MSS release 6.1A, looks like - still the drivers could be re-compiled.

Since you "aren't sure what you are looking at" the rel6.1A driver for a comparison:

Gernot66 wrote on 2020-02-16, 15:19:

(caugh) your patch didn't warns if the driver has different addressing?

It looks for a specific code sequence, and it changes nothing and displays "File unrecognized" if the sequence is not found. The addresses we're discussing here have no bearing on how the program works because, as I mentioned before, it does not try to do anything about the samples used for the initialization transfer.

If you do have a version of SB16.DIG which is not recognized by the patch program then I would be interested in taking a look at it.

Check my last post i attached this specific driver.

I'm a bit slow in posting (i have to read my posts three times).
Perhaps, but only perhaps this was a change for win98?
Because what "actboy168" offers for his project is mostly win related and the DOS drivers and binaries are just present because they are part of mss rel6.1a.
On the other hand it isn't an uncommon version, i guess i will find it in a couple of games on my machine.

Besides like i stated your patch recognizes the driver and didn't warns but didn't does anything to it thus the stereo is still swapped.
I assume if i alter the value similar as your patch does for the "working" version it will do the trick.

However you can check this out for yourself where the devil resides in this driver.
I'm by myself will avoid it and use the patched one, this will be the safest way.

Gernot66 wrote on 2020-02-16, 13:59:

the SB16 driver i hacked looks like this: […]
Show full quote

the SB16 driver i hacked looks like this:

Copy code to clipboard

1MOV [0479],80
2MOV [0487],00
3MOV [0495],00
4MOV [04A3],00

Eh, those instructions don't exist in either of the driver files in your attachment. However, the MOV instructions that put 4 0x80 bytes into sequential memory as samples DO exist in both driver files, so you appear to be looking at something entirely different. In any case, my patch program does work with both of those drivers.

pause

for a while i'm off line again, i have no own web access thus i'm always off for a couple of days.
Just if you guess why i won't reply anymore - next week.

ripsaw8080 thx nonetheless, i didn't managed it to get rid of the pop thus i decided to use "plany" and 8bit mono samples.
It's designed for this purpose, less stressing, works with any blaster setting, doesn't hinders the batch, is more flexible, allows to control replay frequency which is i nice thing if you randomize it.
The only thing it perhaps leaks of is a return of an errorlevel this is always handy in a batch, but no sample player so far has this and for the MIDI players i found only "MegaMID" returns an errorlevel, nor that i see a use for this for a sample player, but the use i will find if i have it.
Perhaps due to my decision for 11kHz 8bit mono i will use even one of the TSR programs i found, but i haven't yet tried one of them, i avoid them if possible.
Because once you started to use them you will probably use this and that to and i think that isn't a good thing.
It's enough that a keyboard stuffer lurks around and that i use sometimes the TSR option of the GUS Playmidi if i like to run an animation and music together.
I don't have to tell you that it could be problematic.
If nothing else is a problem it's still problematic to terminate one if you loaded another one.