Odd behavior after periodically capturing audio over a long period of time

[gen2brain]

Odd behavior after periodically capturing audio over a long period of time

[gen2brain]

Hi,

If you build with -tags mal_debug you can get more info about the lock. You can also try to force one of WASAPI, DirectSound, WinMM and see what is different.

Also, current mini_al.h is not up to date with upstream, maybe it was a bug with mini_al that is already solved, with more info you can maybe also ask fo help there.

[howdoicomputer]

Yeah, I'm asking upstream here: mackron/miniaudio#43

Also, how do I force a back end? When I try passing in a back end to initContext like so...

backend := []malgo.Backend{malgo.BackendDsound}

I end up getting a device different from my headset and it's still on WASAPI.

[WASAPI] Default Capture Device (Capture)
  Format:      16-bit Signed Integer -> 16-bit Signed Integer
  Channels:    1 -> 2
  Sample Rate: 8000 -> 48000

If I'm forcing a back end do I also have to find the device I want via Context.Devices()?

Thanks, @gen2brain!

[howdoicomputer]

I'm also changing my code so that the allocated context and initialized device stay active until my program exits in the hopes that fixes things.
howdoicomputer/onair#1

[mackron]

I think that diagnostic message is actually a bug in mini_al which I fixed a while ago: mackron/miniaudio@80e0777. I'm pretty sure it actually is using DirectSound.

[gen2brain]

@howdoicomputer mini_al is updated to v0.8.14, update lib/repo and try now.

[howdoicomputer]

@gen2brain Thank you so much! I'm going to see if that between the version update and my code changes if the problem is fixed.

[howdoicomputer]

@gen2brain The problem has gone away. I think it might have been more that I was reinitializing context and the device every five seconds.