OSDev.org

A few months ago I stumbled upon this little gem that show you how to play a WAV file from memory. The only issue is that it only supports conventional memory (segmented memory) so it only can play a few seconds of audio at a time.

Does anyone know how I could take this code and make it work with extended memory? Or, alternately, if someone could point me in the direction of some x86 assembly code that works with extended memory?

Thanks,
-Mike

The Sound Blaster 16 wiki page explains how to play audio from a small buffer in conventional memory, and how to copy data into that buffer after the audio data has been played.

I know, because I put it there.

The trick is to wait for an interrupt from the Soundblaster, which will let you know when to "refill" the buffer. Because you only get one buffer, the best approach is to fill half of the buffer while the Soundblaster is playing the other half.

@SpyderTL: Thanks for the quick reply. However the issue is that my program would be blocked while it is trying to re-fill the buffer. I was hoping to be able to play audio asynchronously.

This program is designed to be run in DOS in 16-bit mode, which means you're going to be limited to how much audio data you can store in memory. You would have to read audio data from the hard drive and fill the audio buffer that way.

The good news is that since you are running in DOS, you can add your own interrupt handler to catch interrupts from the sound card. Essentially, the code you have now will need to be modified to set everything up and "install" your interrupt handler to listen for interrupts from the sound card. The interrupt handler is a function that will be called by the sound card when the buffer needs to be filled. The function will not be called by your application. Your application simply has to wait (sleep) until all of the audio data has been played.

Then you can "uninstall" your interrupt handler, and end your program / return to DOS.

Check out Interrupts for more information.

@SpyderTL: That all sounds good in theory. Do you know where I can find and code examples?

Unfortunately, no. Both the Soundblaster and DOS have been effectively obsolete for about 25 years, so not a lot of information that is still relevant. A Google search for DOS Soundblaster WAV turned up several open source projects that do something similar to what you want, though.

There is enough information on this site to build one yourself. It will probably take you a few weeks, however.

We can answer any specific questions you may have along the way, if that helps.

Let us know how it goes if you decide to tackle it.

@SpyderTL: Understood. Looking over the link to the OSDev Wiki (http://wiki.osdev.org/Sound_Blaster_16) I see that it mentions the 16-bit Interrupt Acknowledge (Register 0x0f). My understanding is this is what you mentioned in a previous post about getting notification from the SoundBlaster that the buffer is empty.

Could you please explain how I can invoke this register so that I can assign an interrupt handler?

That's not quite the way it works.

You have to have a function in memory that will "handle" the interrupt (notification from the sound blaster), which will refill the buffer in system memory, then notify the sound blaster that the buffer was filled. The Soundblaster 0x0F register is used to notify the Soundblaster.

Setting up that function to receive interrupts is a whole different problem. Check out the wiki page on "Interrupts" to see how that works.

It appears that I have banging my head against the wall because I thought there was an issue with my implementation when there is a problem with VirtualBox! When I try to have the soundblaster play the next buffer the sound suddenly "jumps" ahead and then back again. This doesn't happen when playing in DOSBox or Bochs.

I noticed that other people have been experiencing this issue (https://forums.virtualbox.org/viewtopic.php?f=4&t=12425) but it appears that Oracle isn't going to fix it because hobbyist OS aren't supported.

@SpyderTL: OK, I have figured out how to inject my out interrupt handler for IRQ 5 (although I wish this was more generic ) and sends the next chunk of the buffer from the extended memory to conventional memory and play. It works flawlessly in DOSBox and Bochs but VirtualBox is a different story.

Unless I am doing somthing wrong (possible) there appears to be a bug in VirtualBox that is causing the interrupt to fire before the buffer is empty. Any throughts?

Maybe the controller is prefetching the sound data.

I had a response all typed out earlier today, but I decided to just let it go, instead of adding to the confusion...

But since you asked...

The post that you are referring to is 8 years old, and a lot has changed since then. VirtualBox has come a long way in that time.

However, I actually found a SoundBlaster bug a few weeks ago, looking through the source code at VirtualBox.org. It turns out the SoundBlaster code is essentially copied over from the QEMU project, which is also open source. I contacted the developers of both projects, and the issue has now been fixed on both sides. I started a thread about it here: http://forum.osdev.org/viewtopic.php?f=1&t=28934

After that, I found some issues with VMWare's emulation of the Ensoniq AudioPCI 97 device. Read that thread here: http://forum.osdev.org/viewtopic.php?f=13&t=29408

It turns out that both of these emulators essentially do the bare-minimum to get Windows XP to work properly, and not much else. It makes sense that, for performance reasons, you don't add more functionality than Windows will actually use. Anything else will normally be wasted cpu time.

So, to answer your question... I wouldn't assume that the issue that you've discovered is "necessarily" a problem with VirtualBox, but I also wouldn't be surprised if it did turn out to be a bug in VirtualBox. Also, obviously, make sure you are using the latest version (5.0).

If you get some spare time, I would do a little more digging and see if you can get VirtualBox to work. Also, see if you can pinpoint the exact problem (register or interrupt that is broken), and let us know exactly what is going on, and maybe we can help. Alternately, you can post a link to the code and we can take a look for ourselves...

@SpyderTL: I can post the SoundBlaster assembly file, however it has references to other parts of my OS that I would need to pull out in order to keep the code example as small as possible. Also, my code is very "raw" as I am still in the process of writing it. In other words, there is very little comments and tabbing/spacing is inconsistent. However I can post it if it means that VirtualBox will fix this bug.

According to your bug ticket it has been fixed 7 months ago. I would imagine that we would have had the fix by know, but based on readying your bug report, this is the same issue that I am experiencing in my OS. So either it isn't fixed or someone forgot to merge your code with the main trunk?

Also, yes, I am running the latest version of VirtualBox (5.0)

The bug appears to be gone from the code according to the SVN trunk.

Perhaps VirtualBox is not the problem (or at least, not there)?