OpenAL Device Choices

Thank you very much, I take it you plugged in a microphone now? It would also be very useful if you could run it under ubuntu again, with a microphone plugged in (I don't need another log from that, if the exception is gone with a mic).

I don't want to steal your time, but it is important to know whether Windows and Ubuntu react differently to that condition.

Something that I find a bit curious is that Ubuntu seems to thread my foreach() loops for the Dictionaries, while windows does not. The lists are alphabetical, but your ubuntu log is unsorted as if multiple threads work on an iteration each. (Autowah should be the 1st Efx Effect, Bandpass the 1st Filter, etc.) I have not spawned any threads in the app. Weird.

I plugged in a microphone, verified it works, but received the same error on Ubuntu. I don't know whether this is a configuration error on my part or an OpenAL Soft issue.

I will try to compile the newest version 1.8 and test again.

Edit: Ah regarding Dictionary, there are no ordering guarantees. You'd have to use a SortedDictionary for that.

Dictionary: the order of the elements is not guaranteed. The order is an implementation detail and (probably) depends on the order of insertions - it is allowed to change between different runtimes or even different runtime versions (3.5 to 3.5SP1). Bottom line: don't depend on it. Use a SortedDictionary or SortedList if you need a specific order! :)

This time it's a debug x86 build, so it's a little more verbose. Could you please run it under Ubuntu and attach logs? (perfect would be 1 log with mic plugged in, and one without)

I believe to have found the AL Error regarding "200 sources not deleted" (and a second one related to Efx), apparently for some drivers it's an error to call AL.Delete***( 0 ) or Efx.Delete***( 0 ), i.e. it only accepts deletion of sources that were previously successfully generated by AL commands. The X-Fi hardware driver handles it gracefully, but the software drivers don't.

I can also provide source code if that helps with testing (just trying to save you time building it since I do that anyways).

Edit: attached log

Thanks alot :)

"This application is currently running as x64"
I think this is a bug related to VS2010 beta, I have previously built (other apps) for x64 and IntPtr.Size was 4. The diagnosis app v2 is built for x86 (not AnyCPU), but IntPtr.Size is not 4 -.-

The AL and Efx errors are gone, which is satisfactory. I've taken a look at alsa.c (OpenAL Soft 1.4.272) and the related lines of code are:

if(!(ok(psnd_pcm_hw_params_any(data->pcmHandle, p), "any") &&
         /* set interleaved access */
         ok(psnd_pcm_hw_params_set_access(data->pcmHandle, p, SND_PCM_ACCESS_MMAP_INTERLEAVED), "set access") &&
         /* set format (implicitly sets sample bits) */
         ok(psnd_pcm_hw_params_set_format(data->pcmHandle, p, alsaFormat), "set format") &&
         /* set channels (implicitly sets frame bits) */
         ok(psnd_pcm_hw_params_set_channels(data->pcmHandle, p, aluChannelsFromFormat(pDevice->Format)), "set channels") &&
         /* set rate (implicitly constrains period/buffer parameters) */
         ok(psnd_pcm_hw_params_set_rate(data->pcmHandle, p, frequency, 0), "set rate") &&
         /* set buffer size in frame units (implicitly sets period size/bytes/time and buffer time/bytes) */
         ok(psnd_pcm_hw_params_set_buffer_size_min(data->pcmHandle, p, &bufferSizeInFrames), "set buffer size min") &&
         /* install and prepare hardware configuration */
         ok(psnd_pcm_hw_params(data->pcmHandle, p), "set params")))
    {
        AL_PRINT("%s failed: %s\n", err, psnd_strerror(i)); // [b]this is line 564[/b]
        ....etc

...so the problem is related to the parameters passed into Alc.CaptureOpenDevice. It would be good to know whether this is a bug and has been fixed with v1.8 of the driver, the win x86 build from their website works flawless (but it most likely never calls anything in alsa.c).

I'll see if I can cook up a more meaningful test application for this.