simply put, DOS is the only os i know of that allows direct communication with the hardware. linux/win9x/wun2k/winxp and most modern OSes abstract this away to allow better compatibity and hardware support. you may remember back when dos games were big, that they had to write code to support both gus and sound blaster cards. some shareware games only supporte one type of card (ussually the one the author had access to).

in fact, many newer sound card drivers allow access to the sound card by multiple apps when using standard windows wavOut functionality. this allows sound to be played by any app even if another app is playing sound. while dsound apps that get exclusive control disable this feature while they are running because with exclusive control you can write sound data "directly" to the sound card. using directsound is close enough to direct access when you write directly to the primary sound buffer. there is no point in learning the dos method since it wont be applicable to other apps. instead write the software using dsound in exclusive mode. read the wave data yourself and dont use any helper functions. just this will be a burdern for you since you have to ensure you keep the primary buffer full. also limit the size of the buffer to 1 second of so, nothing larger will be needed.

though if you really want to do things old school, install dos. though since you just want to learn how it works, then you should just look at the code and understand it. compiling and playing with it is not nesscary (and again useless since you cant use it on anything except dos).

Fruny, /dev/audio is about as low level as dsound so your point is moot. you still need drivers, thus you are not talking to the hardware directly. as i stated before dos is the only OS i know of that allows this. you can run audio apps in dos with no kernal support (or modules), and no drivers at all. just use the proper interrupts and send the data the card expects (most cards back then were either sb compatible or GUS). you could literally plug the hardware in, set some enviroment varibles (not need by most software since they allowed config with a setup program, they even probed the default ports in the more advanced ones) and you were ready to go.

Crispy, so in reality you just want to send the audio data yourself, and read the wavs yourself. so dsound and windows wavout would allow that just as well as openal (in fcat openal uses dsound on win32 platforms). i dont know what you mean by extra functionality dealing with effects and such, since a basic dsound app simple creates a primary buffer, secondary buffer. sets the primary buffer to loop, and then sets the secondary buffer to loop. finally your app starts writing wav data to the secondary buffer to be played. no effects, no special magic, just your basic "send the audio data to the sound card with no processing". you can implement a complete sound system yourself in dsound, even do the mixing of samples (and buffering of ALL audio data) yourself if you want. i am not saying you should switch, i am just saying your being a bit naive about how dsound works.

that is because wolf3d is a 16bit real mode dos app, and not a windows app thus is allowed direct access under certain circumstances. these being, running win9x which is based on dos thus has some backwards compatibility. under winnt, the app will generally fail with either a crash or not being able to access the hardware (thus in the case of sound, they app thinks sound is playing but nt is routing all the data to limbo, since the os is allowed to use its own handlers for interupts and od what it wants when they occer). under winxp/win2k, it depends on how the app was written (the less "tricks" the more likly it is to work with the dos simulation code). in fact there is a dos sound simulator project that is trying to get dos games to run in nt/2k/xp reliably.

you could get a 16bit compiler, or some other dos mixed mode compiler (the sound code would have to be 16bit). your app would then effectivly become a dos app, thus you cant use opengl, directx, win32 api, dlls, etc. but doing this would be taking the "write the game in dos" advice hinted at earlier.

openal is cross platform, but under windows the only performence sound api that exists is directsound (ie apis like openal, fmod, bass, etc. will use dsound). sdl does the same thing, except using directdraw (since sdl is a 2d bliting type api). its not a big deal, you are not getting a noticable overhead. just figured i would point it out since you said "no DirectSound or Windows Multimedia calls ". dx is not an intermidiate api or wrapper, neither are openal, sdl, opengl. even if openal is using dsound for outputing the sound, its not much of a wrapper (especially if your looking for a cross platform api).

if you truly want to stay away from all apis, you must code for dos, since all other OSs require you to interface with the OS on some level. dos on the other hand, lets you do pretty much whatever you want (even writting data to memory being used by the os, or changing interrupts so you can do things like filter what keystrokes dos sees). though you will quickly find that its much easier (and less error prone) to use apis that are part of the OS (well at least have some OS/kernal level code). you will quickly enjoy having that slight abstraction of hardware.