OpenAL Device Choices

Try changing GetString.DeviceSpecifier to GetStringList.AllDevicesSpecifier in AudioContext.LoadAvailableDevices. Does it return the correct devices after the change?

Other than that, you can force a specific device using the AudioContext(string device) constructor.

Yep, I missed your edit. How do you use ALC_ENUMERATE_ALL_EXT?

Alc.OpenDevice() is ok, it returns null for the string "SB X-Fi Audio [E800]" but a non-zero pointer for "Generic Software". Alc.GetString is ok aswell.

The different reports by EfxEnumerateWinXX.exe appear to be connected with their x86 framework. But I'm running debug x86 builds from VS2010 here - targeting .Net 2.0 - so I should get all devices the 32-Bit driver knows of?

I had a quick glance at it and as far as I can see the command patterns in Alfw (OpenAL SDK), openal-info and AudioContext are close to identical. It's most likely a driver problem on my end, reinstalling oalinst did not help so far though.

here's an openal-info log from a X-Fi card (eXtremegamer edition IIRC) under windows xp x86, what is really weird is that neither of the 2 logs contains any ALC Extensions. Could it be - because the extensions were promoted to core 1.1 - that they are not in the list anymore? But why does OpenAL Soft list them?

He'll test my example app too, but needs Net Framework installed first and that's not going to happen tonight.

Available playback devices:
    SB X-Fi Audio [CC00]
    Generic Software on Lautsprecher (Creative SB X-Fi)
    Generic Software on SPDIF Out (Creative SB X-Fi)
Available capture devices:
    Microphone (Creative SB X-Fi)
    "What U Hear" (Creative SB X-Fi
    Line-In (Creative SB X-Fi)
    Auxiliary (Creative SB X-Fi)
Default device: SB X-Fi Audio [CC00]
Default capture device: Microphone (Creative SB X-Fi)
ALC version: 1.1
ALC extensions:
    None
OpenAL vendor string: Creative Labs Inc.
OpenAL renderer string: SB X-Fi Audio [CC00]
OpenAL version string: OpenAL version 1.1
OpenAL extensions:
    EAX
EAX1.0
EAX2.0
EAX3.0
EAX4.0
EAX5.0
 
EFX version: 1.0
Max auxiliary sends: 2
Available filters:
    Low-pass
Available effects:
    EAX Reverb
    Reverb
    Chorus
    Distortion
    Echo
    Flanger
    Frequency Shifter
    Vocal Morpher
    Pitch Shifter
    Ring Modulator
    Autowah
    Compressor
    Equalizer

That is correct and because 99.5% of those who use OpenTK.Audio use the software driver, the issues listed above did not show up yet ;)

[Extensions]
It appears the missing extension strings are a driver quirk. Tests like Alc.IsExtensionPresent() will correctly return true/false, but you cannot get a full list from Alc.GetString.

For example, this code will fork correctly to "1". However the extensions string returned by Alc.GetString is 2x null (blank).

 if (Alc.IsExtensionPresent(IntPtr.Zero, "ALC_ENUMERATION_EXT"))
            {
                if (Alc.IsExtensionPresent(IntPtr.Zero, "ALC_ENUMERATE_ALL_EXT"))
                    printDevices(AlcGetStringList.AllDevicesSpecifier, "playback "); // 1
                else
                    printDevices(AlcGetStringList.DeviceSpecifier, "playback ");
                printDevices(AlcGetStringList.CaptureDeviceSpecifier, "capture ");
            }
            else
                Console.WriteLine("No device enumeration available.");

[Device Detection]
I've ported parts of strangesoft's openal-info to OpenTK.Audio, it gives me the following result:

I'm not quite sure yet what the difference to AudioContext is, but this is the desired - correct - result. It uses Alc to create the dummy context - not AudioContext - so the problem is very likely in AudioContext's constructor.

Do you intend to work on this? I'm already working on it, but since you wrote it you know your way around better than me and I'll gladly hand it over ;-)

btw. X-Ram works fine, it reports 66MB total RAM although it should be 64MB (free RAM reports 64MB), but I think this has something to do with all X-Fi cards having 2MB onboard RAM, probably for streaming the mixed output or something like that. No reason for concern imho.

Good luck with that, but I hope you will review changes because I'm getting creative here ...

• Refactored AvailableDevices property into AvailablePlaybackDevices.
• Added AvailableRecordingDevices property.
• Added a public readonly-property GetDeviceName. (Good for Apps which allow the user to select a device from a list, or apps which simply request the default device, but would like to know afterwards what it's called)
• Added a public readonly-property GetAlcError. (Alc.GetError takes an IntPtr as parameter, which is bad for the wrapper's design)

[branch]
k, but the changes are really minor (besides the refactoring of AvailableDevices).

[get]
How would you name GetAlcError? AlcError is the name of an already used enum. It does internally call Alc.GetError, so maybe simply "Error" or "FirstError"?

[capture]
IIRC the OpenAL spec likes to call playback "render" and recording "capture".
Recording does not use a context, you can only open/close the device, start/stop recording and capture the samples. No AL commands and only few Alc commands work with the recording device, i.e. you need a playback device first to query available recording devices.
I can wrap the associated commands up, but I don't think it would be a good design to include any form of threads/mainloop into the class.

It might look like this in the end:

RecordingDevice rec = new RecordingDevice(); // open
rec.StartCapture();
Thread.Sleep(500);
rec.StopCapture();
byte[] samples = rec.CaptureSamples( rec.SampleCount );
rec.Dispose(); // close

[error checking]
The system is the same as for GL, pretty much any function can generate InvalidOperation/-Enum/OutOfMemory etc.
The "automatic GL.GetError" for debug builds could be applied to AL in the same way, assuming the functions have some internal import and a public interface where to place the geterror calls.

There are also some special cases that require handling by the application, for example the user may intentionally or accidentially unplug the microphone or put it on mute. At least I do prefer testing for this condition manually rather than creating a huge try{} to encase all code where some AudioDeviceUnpluggedException could be thrown.

[capture]
There is no need for an AudioContext instance in order to use the capture extension, but AudioContext's static constructor must be called to create the dummy device/context and query available devices from the driver. This may have not been clear in the recording-example application I posted a couple of weeks ago, since it uses an AudioContext for playback anyway. But in theory (I cannot think of any good usage example for it) you could write an application that only captures microphone input but has no AudioContext to play anything back.

How about the name "AudioRecorder" instead of "RecordingDevice"? Then we'd have AudioContext for playback and AudioRecorder for recording. Maybe even refactor AudioContext to AudioPlayback?

[error checking]
How about some bool ThrowOnError? I'd prefer that over forcing exceptions to be default behaviour.

[unplugged]
IIRC Alc.CaptureStart will generate an Alc Error if no microphone is connected, but opening the device worked. Haven't tried unplug it during capturing and currently the mic is not working (did I already say that installing the card is a bitch and that I miss the the days where you had to RTFM, jumper the card's IRQ and it worked after that, instead of Plug&Pray?)

[enumeration]
From the isolation-perspective that would certainly be the best choice, but from an efficiency-perspective it is horrible: 2 dummy contexts would be created and destroyed, devices must be protected from both static constructors accessing the device at the same time and also only a fraction of OpenTK applications do use Audio, even less will use the recording capabilities.

I'd rather add a get-property to the AudioRecorder that pulls the information from AudioContext's properties. Like I said before I cannot think of any good usage example that would want to use recording capabilities but no playback.

AudioCapture it is.

[enumeration]
I've created a branch like you suggested, stripped off all GL/CL/Input/Platform stuff so it builds fast ;) I forgot to add in the description that it's based on 0.9.9 though, but I believe this is not a problem since not much happend to OpenTK.Audio in previous releases.

Don't bother read it yet though, it's quite a mess. Just wanted to back it up before moving the device detection into the new class. I'll take your advice and move the static stuff into AudioDeviceEnumerator class.

[error checking]
Agreed, it is absolutely necessary to throw for errors at device initialization. But during "normal" program operation no AL or Alc Error should occur (or potential exceptions requiring try/catch), it's the programmers responsibility to query device capabilities at initialization time and chose an appropriate codepath that will execute error-free (just like for GL).

Btw. is it ok if I use AudioDeviceException for AudioCapture too? Or rather create new ones?

[DeviceUnplugged]
This would be quite interesting to have, I will take a look where exactly the alc error occurs when unplugging the mic (once it works). Since the user will regularly use the AvailableSamples property and the GetSamples method (and I think that's where Alc errors related to unplugged devices will occur) it should be doable to use an event. Detecting when a device is plugged in again will be trickier but should be doable aswell.

[hardware]
It's an PCI card, all PCIe slots are covered by the graphics card and no card would possibly fit in there without a saw, hammer and alot of brute force. The compatibility problems appear to be related to the mainboard's chipset (according to creative labs forums), but the drivers also have alot more tweaking options than the onboard sound ones, so I'm positive it will work perfectly after some patient experimentation.
Mind the card has more input/output connectors than I can count (it has a 5.25" front panel too), it may be as simple as disabling some input/output channels for everything to work as intended.

What's the purpose of bool openal_supported? Merely track whether the dll is present? or should it also include whether device detection failed/succeeded?

[AudioDeviceException]
I'm only using it for errors related to OpenDevice-alike functions.

[hardware]
Only the more-recent X-Fi Titanium has PCIe, I've got the older X-Fi Platinum series. The sound quality is truely an upgrade compared to onboard sound. In Doom3, I found myself running back a couple of rooms that were already cleared, because I heard a zombie that I had overlooked in the dark. That were about 30-40m distance with walls inbetween, but I knew exactly where to find it. When realizing that I was like: O.o
Reverb and Headphones certainly make a difference.

Motherboard designs are probably like that to fit as many slots as possible on as little space as possible. I do agree that it might be the better design not to squeeze all PCIe slots next to each other since graphic card's cooling starts to get ridiculously huge. I've no idea how I'd fit some SLI/Crossfire in there.

[RSS]
I've bookmarked the url, but I rather do a few clicks to get information than getting it when I don't want&|care . The very first thing I disable after installing vista is the sidebar.

[MacOS/Linux]
I take it the only way to test whether the changes I made run on other platforms are me installing the OS? I'm afraid of Unices.

When using the word "afraid" I did not mean "scared". Rather "concerned" that Linux has the same effect on me like a shot of heroine for an ex-junkie who has lived happily with methadon before. ;)

Thanks for the crashcourse, I will at least confirm that the changes work as intended on Linux. But I won't buy MacOS - which I don't need - just to go through the horrors of driver installation a 3rd time.

VS 2010 is also a good way to stay in shape, since they somehow broke IntelliSense (compared to VC# 2005 EE). Often you need to type letters first before intellisense will accept confirmation of the choice by the enter key, but using the mouse you can select and confirm at all times. With VC# 2005 the only times I use the mouse is with forms or moving c&p, so VS2010 does actually slow me down :|

Ok, ran this on Ubuntu 9.04 amd64 (OpenAL Soft 1.4).

Two things seem to fail:

AL lib: alSource.c:2291: alcDestroyContext(): 200 Source(s) NOT deleted
AL lib: alsa.c:564: set access failed: Invalid argument
 
Unhandled Exception: OpenTK.Audio.AudioDeviceException: The handle returned by Alc.CaptureOpenDevice is null. Alc Error: NoError
Device Name: ALSA Capture on default
Frequency: 16000
Buffer format: Mono16
Buffer Size: 32000
  at OpenTK.Audio.AudioCapture..ctor (System.String devicename, UInt32 frequency, ALFormat bufferformat, Int32 buffersize) [0x00000] 
  at OpenTK.Audio.AudioCapture..ctor (System.String devicename, Int32 frequency, ALFormat bufferformat, Int32 buffersize) [0x00000] 
  at Audio_info.Program.Main (System.String[] args) [0x00000]

(Use wordpad to open the file)

Yep, alsa is something like directsound and no, I forgot to plug my microphone.