Heya :)

Attached are required headers for using Open Audio Library (OpenAL) with MASM.
I have also written some OA32 classes which wrap the OpenAL functionality in a more intuitive interface, and a working example using that - if there's interest I can post that too.

Posted on 2010-06-29 02:50:50 by Homer

Started reworking my old audio engine to use OpenAL's interface rather than DirectSound.
At the moment, I'm still using DirectSound as the audio render device, but I can switch to the default system hard/soft device in the next day or two..

So far, I can play static wav files, and I can stream them.
I've used my own WAV loading/parsing code, so there's no ALUT or other support libraries being used (other than my GLADD lib).

Tomorrow I will endeavor to reimplement MP3 streaming, I was wondering if anyone knows about the fate of the ACM api functions on Win7... how do we enumerate / gain access to audio (decompression) codecs? I'm guessing that the waveXXX API are still there... ?? Anyone?

Posted on 2010-06-29 10:40:01 by Homer
Both 32-bit and 64-bit MSACM32.dll are present on Windows 7 and ACM is still fully supported. Although the docs say that the whole Windows Multimedia branch of APIs are "superseded" by DirectX. Can't say if they are planning to drop the support for the whole MMAPI (I doubt it) or they're just pointing the programmers to Xaudio2/XACT.

And, for anyone interested, to demonstrate the current support of openal by creative's cards, the attachment shows all major openal caps of "SB X-Fi Fatality Champion Series". I've heard (but haven't seen) that Realtek's cards support it pretty well, too.
Posted on 2010-06-29 16:43:34 by ti_mo_n
Thanks for that information, I will sleep better tonight :P I use realtek audio and can happily confirm that - I get EAX up to 3.0, and EFX 1.0, and this is a poor onboard chipset.
Posted on 2010-06-29 22:28:26 by Homer

MP3 Streaming in 3D was (re)implemented :)

I have not implemented any Capture code, I won't bother for now.

I've tested the engine with the highest bitrate mp3's I have - 320kb - and tweaked the variables to make it "just" stable when playing files at that rate - this is of course, overkill for files with lesser bitrates, I didn't bother making it scale.

My audio engine is once again useful for game development  :thumbsup:
Posted on 2010-06-30 07:18:41 by Homer
MP3 Streaming is not surviving a switch from fullscreen to windowed mode... works fine the other way.
What seems to happen is the current buffer finishes playing, then any queued buffers will silently fail all at once, be dequeued, fail to be refilled, and thus will not be requeued - I may have to cold-start OpenAL after the switching from fullscreen to windowed mode which is a pity, because I can do a smooth transition from windowed to fullscreen without noticing any glitch in the streamed audio.

Perhaps this is simply related to my using a particular 'named audio driver' (DirectSound) - we KNOW that DirectSound can 'lose' devices, and I am currently unaware of any OpenAL function to find out if that is the case.
In fact, OpenAL seems to OFTEN fail silently, showing "no error". You really have to be on your toes.
Posted on 2010-06-30 21:01:14 by Homer
Switching to/from fullscreen seems to be pretty disruptive. It could be that the video driver is claiming all CPU during the switch, so the audio interrupts cannot be handled in time, and the queue cannot be updated.
Switching has pretty much always caused audio to at least skip, for as long as I can remember. But perhaps OpenAL needs an extra nudge to keep going.
I suppose switching to windowed mode is more expensive than the other way around, since all windows have to be redrawn aswell, which means all applications need to be woken up etc.
Posted on 2010-07-01 04:48:56 by Scali
I managed to fix it by enqueueing enough buffers to ensure that the queue doesn't completely empty during the mode switch.
I also doubled the size of the MP3/PCM Frames - stereo files were overflowing the framebuffers,nobody told we we should use 2*MP3BLOCKSIZE to be on the safe side.. its rare but some MP3 frames produce more PCM data than others, and the size of the PCM buffer we obtained from the ACM is based on the AVERAGE PCM frame output size.

Running out of buffers is especially a problem for high-bitrate mp3 files, but again, I tweaked the engine using 320kbps test files.
It's definitely, and ONLY caused by totally running out of queued buffers... we *DO NOT* "lose the device" :)

If this becomes an ongoing problem (ie shows up again when the app is under genuine load), I will implement a counter to track the number of queued buffers, detect when the queue has been emptied (but the Source is still in Play mode), stop play, refill/requeue buffers, and start play again.

That will cause a momentary gap in the MP3, but it's acceptable during a harsh mode switch, and it's better than losing the audio altogether :P
Posted on 2010-07-01 12:33:57 by Homer