I admit I don't get nearly anything from this, but the whole topic of DOS sound programming seems attractive.

I thought that for stereo output sample rate should be doubled, yet debug shows it is quadrupled, how do you explain that?

I don't also get what problems you have with WSS after Allegro shutdown. Don't you think of borrowing some other sound library DMA shutdown code to embed into Allegro?

Forgot to mention that WSS = Windows Sound System. mainly an interface of a soundcard which allows CD-quality sound. Found on different non-creative brands and types of ISA soundcards. A promising thing, but often unnecessarily poorly supported. For example, any game offering the Miles SoundBlaster 16 digital driver can support WSS, but often it requires adding SNDSYS.dig and renaming it SB16.dig (replace that entry) then setting the ports manually (530h etc). Although there is the theory that using SB Pro mode 11kHz Stereo is sufficient for all dos games, I do percieve improvement by pushing it further.

bristlehog wrote:

I admit I don't get nearly anything from this, but the whole topic of DOS sound programming seems attractive.

It is not 100% clear to me either 😜. Just would be nice if allegro, the main open source dos game programming library, would actually have a likable sound blaster driver. Currently the commercial drivers do better. Though I noticed that Duke 3D also gives the problem of 'point 2'.

bristlehog wrote:

I thought that for stereo output sample rate should be doubled, yet debug shows it is quadrupled, how do you explain that?

looking at:
Allegro 3.0 original:
DMA unmasked,starting output, auto 1 block 1023
DMA Transfer:8-bits PCM Stereo Auto-Init freq 22727 rate 90908 size 512.

Allegro 3.0 modded by me:
DMA unmasked,starting output, auto 1 block 2047
DMA Transfer:8-bits PCM Stereo Auto-Init freq 21739 rate 86956 size 1024.

I know the driver definitely wrote (22kHz times 2 =) 44kHz to the SB Pro register here. The rate behind it is the dosbox variable named "sb.dma.rate" which is in direct relation, but i do not know what to think of it. Like do SB Pro compatibles have limits and rules regarding sb.dma.rate?, as they do in regard to freq. Actually I can only find a DMA size variable in the driver, I don't know where the rate is...

bristlehog wrote:

I don't also get what problems you have with WSS after Allegro shutdown. Don't you think of borrowing some other sound library DMA shutdown code to embed into Allegro?

I tried that, but it seems to be the actual main sound transferring code, not the shutdown code. The allegro shutdown hack (use unsupported mode for 150 ms) somehow works for this card, but I cannot recommend it as a fix until I understand what is happening. Note that three other drivers also switch to a different mode briefly, but at startup, using a tiny block size. You can see that in the document I attached before.

I am aware of WSS standard, and even got the card itself: a dusty one with huge caps.

It won't work though (except for OPL3 part), since Miles drivers hang during WSS detect. This happens with any WSS-compatible card I have, including WSS itself, Terratec EWS64XL, Yamaha OPL3SA, Orchid SW32. I am currently switching to another system, maybe it will fix the problem. If not, I will try other WSS-supporting drivers, like SOS or Allegro.

I have never thought of replacing MSS drivers, but this should be a sound idea since they all support standard interface. But I have yet to see a game that is based on an early version of MSS prior to 3.03 where SNDSYS.DIG was first introduced:

Changes from 3.02 to 3.03 (06-18-1995)

Two new drivers, SNDSYS.DIG and ESFM.MDI, provide support for the Microsoft Windows Sound System and ESS Technology ES1688, ES1788, and ES1888 chipsets, respectively.

I know the driver definitely wrote (22kHz times 2 =) 44kHz to the SB Pro register here.

AFAIK SB Pro doesn't accept a direct sample rate value to its register, instead you should convert it using some formula. SB16 accepts sample rate value though.

This is a typical code to set SB Pro sample rate:

1                shl cx,1                ;double sample rate for stereo mode
2
3__set_rate:     mov ax,4240h            ;SB rate = 256 - (1E6 / freq. in Hz.)
4                mov dx,000fh
5                div cx
6                sub ax,256
7                neg ax
8                mov sample_rate,ax

Note that three other drivers also switch to a different mode briefly, but at startup, using a tiny block size.

Well, maybe this will provide some clue:

Changes from 3.03b to 3.03c (11-07-1995)
...
- The standard Sound Blaster digital driver (SBLASTER.DIG) could cause lockups or `Transfer Stack Overflow` messages during detection when running under Windows 95. This was due to the use of an extremely short DMA buffer to check for auto-init DMA capabilities. In this release, the DMA verification buffer in SBLASTER.DIG has been increased in size to avoid problems.

P.S. You are a nice painter.

*** Note: I meant to post a second reply, but unintentionally my original reply was gone. now I retyped it. ***

bristlehog wrote:

I am aware of WSS standard

I noticed, but it is good habit to write such an Abbreviation fully at least once in the topic. For normal people 😉

bristlehog wrote:

and even got the card itself. a dusty one with huge caps.

Wow, 1992, If only they made it a few years earlier things would have been so much easier regarding sound in DOS.

bristlehog wrote:

It won't work though (except for OPL3 part), since Miles drivers hang during WSS detect. This happens with any WSS-compatible card I have, including WSS itself, Terratec EWS64XL, Yamaha OPL3SA, Orchid SW32. I am currently switching to another system, maybe it will fix the problem. If not, I will try other WSS-supporting drivers, like SOS or Allegro.

EWS64XL should work with miles drivers at least, being a CS4236 based card. But the Allegro WSS drivers are poor, they lock up with the CS4232. Maybe one day I will look at it. Don't know SOS?

bristlehog wrote:

AFAIK SB Pro doesn't accept a direct sample rate value to its register, instead you should convert it using some formula. SB16 accepts sample rate value though.

Yes, did it like that already.

bristlehog wrote:

Changes from 3.03b to 3.03c (11-07-1995)
...
- The standard Sound Blaster digital driver (SBLASTER.DIG) could cause lockups or `Transfer Stack Overflow` messages during detection when running under Windows 95. This was due to the use of an extremely short DMA buffer to check for auto-init DMA capabilities. In this release, the DMA verification buffer in SBLASTER.DIG has been increased in size to avoid problems.

Interesting... This week I noticed someone leaked a Rad game tools 6.5 SDK with the sources to all this DOS stuff.

Just noticed Quake seems to have a very rugged Sound Blaster driver. And is open source. Maybe I can learn something from q1source.zip - snd_dos.c.

bristlehog wrote:

P.S. You are a nice painter.

Thanks!

SOS, Sound operating System from HMI. got it now. 😀

The thing that Quake does at sound blaster initialization fixes problem 'no 2' very reliably 😀. I modified my allegro driver (SB.C) to use this procedure at exit. It seems necessary for sound blaster 2.0 and Pro mode:

1static void sb_exit()
2{
3  int i;
4  _sb_voice(0); /* turn off speaker output */
5  if ((sb_dsp_ver >= 0x200) && (sb_dsp_ver < 0x400))
6  {  
7     _sb_reset_dsp(1);
8	  sb_write_dsp(0x14); /* send one byte */
9	  sb_write_dsp(0x0);
10	  sb_write_dsp(0x0);
11	  for (i=0 ; i<0x10000 ; i++) inportb(_sb_port+0xe); /* ack the dsp */
12  }
13  _dma_stop(_sb_dma); 
14  **** etc.... ***

So for the Sound Blaster Pro DOS driver in Allegro it is advised to
1) Lower the Frequencies in SB.C.
2) Add the above code to SB.C to finish all DMA transfers or something.
3) For Allegro v4: base it on this fixed SB.C posted by Ron Novy here.