No API, but there were many sound backends developers could work with to save themselves the hassle of programming individual sound drivers. Miles, HMI, Digpak, DMX, ASS, Varmint, etc.

ibm5155 wrote:

MS-Dos has no thread support, so, the programmers just sended small sound buffers to the sound card btw the game loop?

You don't need threads to send data to the sound card.
The sound card continually plays a buffer. Periodically it sends a hardware interrupt (IRQ), and the application fills the buffer in the interrupt handler. As long as you have data to play, this happens in the background, in a kind of a "thread" (the interrupt handler) that starts, sends some data and finishes once or several times per second.

Similar technique is used when programming for Direct Sound.

But you need data to play. It is better NOT to do any complex task of sound mixing, rendering etc. in the interrupt handler, which should do as few things as possible. This should be done in the game loop.

Hmm I see, are any of those backends that can be used for free?.
And what could be the ideal frontend for me (C please)?

I"m making something like a multiplatform terminal framework, where the user can make a software using the framework, and compile it over ms-dos, Windows and Linux.
All the platforms already has pc speaker support, but with the support of SDL (for a virtual terminal instead of using the native os terminal), I can also play more complex sounds, and I wanted to implemente the same thing with my framework, the áudio api can be ms-dos only, but it shouldn't be too hard. (I don't belive there's gonna be a simple way like playsound(char *name) and voala, everything Works) 🤣

*cough*Allegro*cough*

yup, something like alegro, but way more simple

like......using one piece of allegro.

There's no allegro code over my framework edward...
Also, the point of this thread was only to know what tools people used to use for making sounds on ms-dos, are any of those frontends still being used?

yup, something like alegro, but way more simple

Well, "way more simple" (as in: lightweight, primitive, or low-level, but not necessarily "easy") is reading Sound Blaster specs and coding for it oneself...

I remember writing my own awe32 player. I had used int he past something like mikmod since you can play wav files with it. i think fmod had a dos version, or i remember i got one from firelight (nice to live in same town!)...

there are heaps of music/wav/mod engine code around. you should browse around on an old mirror of x2ftp.oulu.fi or hornet.

A long time ago I was working on some code to play digital sound samples in DOS on a Sound Blaster. I never touched the OPL synthesis stuff though.
As I recall reading, the earliest Sound Blaster cards didn't support DMA and could only play sound samples using PIO. I'm not sure if that information was correct though. I personally did not have a card old enough to have that limitation. Playing sound this way is very CPU intensive and pretty much a joke.

Slightly later cards (but still very early ones) supported DMA but only with single buffering. This meant that the card would autonomously play from a buffer, but you'd only get an interrupt signal once for the entire buffer. As a result, you'd possibly get a "pop" noise every time you refreshed the buffer, because you'd be overwriting the same area of RAM that the card was in the middle of playing.
Most cards (not sure which was the earliest) support double buffered DMA. Your interrupt handler would get a signal every time half of the buffer had been played, so you only had to refresh the other half which was not currently in use. This eliminates pop noises.
I would imagine virtually all games were programmed to work this way. I don't know if any games had compatibility problems with the early cards that supposedly didn't support this mode. You were supposed to detect what model of card the user was using and have alternate code paths to handle this.

As I recall, the largest DMA buffer you could use was 64KB. You'd get an interrupt every time the card had reached a 32KB boundary. When it reached the end it would loop around to the beginning. That's why when a game that uses PCM sound samples locks up, you'll hear a Sound Blaster get stuck repeating about half a second of audio over and over. It's still playing sound but the game isn't updating the buffer anymore.