Hi, for several weeks now I''ve been trying to find a working piece of code that would both compile and successfully write to the sound card on Win2k. Most of the samples I''ve found use getenv() to find out the blaster specs, but as far as I know, Win2k does it some other way (there is no such environment variable as "BLASTER") - the sound card variables are most likely taken from the registry (which I don''t know how to do). Does anyone know of a good tute or code sample that does the abovementioned in Windows 2000 (and thereby most likely in any other Windows)? A listing of all the correct DMA writes would also suffice, I imagine, but the most helpful would probably be a simple WAV player app. The catch here is - no DirectSound or Windows Multimedia calls - I''d like to learn how the real communication with the sound card is done Thanks in advance, Crispy

Unless you go and write a driver you''re stuck. Win2k (and other NT-based OSes) won''t let you write to the hardware like this.

Just learn DirectSound or waveOut. Or use a 3rd party library like FMOD or OpenAL.

Helpful links:
How To Ask Questions The Smart Way | Google can help with your question | Search MSDN for help with standard C or Windows functions

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).

quote: Original post by a person
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.

Linux (and *NIX in general) lets you read/write directly from/to /dev/audio (microphone/speakers). It may be an abstraction, but it's still low-level.

Documents [ GDNet | MSDN | STL | OpenGL | Formats | RTFM | Asking Smart Questions ]
C++ Stuff [ MinGW | Loki | SDL | Boost. | STLport | FLTK | ACCU Recommended Books ]


[edited by - Fruny on May 20, 2002 7:16:07 PM]

Thanks for the feedback! I think I''ll stick with OpenAl. Basically, all that I need to do is write to the sound card in buffers, not pass the entire wav file to a black box function and let it play it for me. I don''t need DirectSound''s extra functionality (effects, etc) because the whole idea of it is to try and implement it myself...

I don''t know much anout *nix''es (because I don''t use any of them), but I have taken a look at Doom for Linux''s source, and that is pretty low-level imo, basically something that I had in mind originally.

Crispy

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.

quote: Original post by a person
i am not saying you should switch, i am just saying your being a bit naive about how dsound works.

What can I say - I''m a naive person. The truth of the fact is, I was kind of replying without the profound knowledge of things actually work - I do know how they should work in theory, though. By bad. Having read a little more about OpenAL, I did discover that it uses DirectX in Windows, which is a bit of a suprise/disappointment because the documentation provided with the SDK clearly states OpenAL is cross-platform. Well, this goes to show I have little possibility of escaping DirectX in any case, which is one of the things I was originally hoping to achieve (don''t ask why - I just wanted to get by without any intermediate APIs or wrappers {sigh}).

Just out of curiosity, can anyone answer this question: let''s take Wolfenstein 3D, the original version (NOT Wolfenstein Castle) which effectively produces sound when run on a Windows platform. Now, if you take a look at Wolf''s source code (see: ftp.idsoftware.com), you can see that it so-to-say directly interacts with the sound card (maybe this isn''t the true case - somebody correct me) and produces sound. This, in turn, is pretty much in conflict with what siaspete and ''a person'' (just to stress that the two words belong together) said. Once again, correct me if I''m wrong!

Regards,
Crispy

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.

If you really want to get at the hardware in W2K, you have to use a dll that interfaces with a driver. Check out WinIo. It comes with source code and it''s fairly easy to use - however you need admin rights to install the driver.