[Weird Bug] Pressing a sampler button caused the daemon process to halt

[AlienXAXS]

Version: 1.0.4

I just booted up my computer and found that I had no audio which I thought was weird... So I pressed a sampler button as a quick-fire way to test audio and the sampler light did not light up.

Launching the Go XLR Utility caused the "Please Wait" to be there forever, it seems the deamon process has become stuck.

However I found this in the logs:

11:50:51 [DEBUG] (2) goxlr_daemon::device: Handling Button Down: SamplerTopLeft
11:50:51 [DEBUG] (2) goxlr_daemon::device: Handling Sample Button, clear state: false
11:50:51 [DEBUG] (2) goxlr_daemon::audio: Attempting to Find Device..
11:50:51 [ERROR] thread 'tokio-runtime-worker' panicked at 'assertion failed: is_format_supported(client, default_waveformatex_ptr.0)?': C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\cpal-0.15.2\src\host\wasapi\device.rs:444
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: Tolk_Unload
   9: Tolk_Unload
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <unknown>
  17: <unknown>
  18: <unknown>
  19: <unknown>
  20: <unknown>
  21: <unknown>
  22: <unknown>
  23: <unknown>
  24: <unknown>
  25: <unknown>
  26: <unknown>
  27: <unknown>
  28: <unknown>
  29: <unknown>
  30: <unknown>
  31: <unknown>
  32: <unknown>
  33: BaseThreadInitThunk
  34: RtlUserThreadStart

11:50:51 [WARN] Error sending Callback! Some(SendError { .. })
11:50:51 [DEBUG] (53) goxlr_usb::device::tusb::tusbaudio: Terminator has told us to terminate.
11:50:51 [WARN] Event Thread Terminated
11:50:55 [DEBUG] (2) goxlr_daemon::servers::ipc_server: Disconnected 127.0.0.1:0

Since restarting the application (forcefully in task manager) all is well again. Not too sure what you can do about this, but thought to submit a bug report in case this error event isnt caught and maybe could be caught in the future to ensure the daemon process doesn't stall.

[FrostyCoolSlug]

Thanks for the report, I'm guessing that happened because your audio wasn't working, so it was unable to create the channel to playback causing the panic.

I'll look into adding some extra checks to fail more gracefully.

[FrostyCoolSlug]

Digging deeper into the CPAL code, it looks like the following is happening:

CPAL: Hi Windows, what's your Default audio format? Windows: Use format X CPAL: Windows, do you support format X? Windows: No.

Which unfortunately is a pretty critical break in Windows audio.. I've added some attempts to catch PANICs come from CPAL during device setup and downgrade them to Errs which should hopefully mitigate this (the lack of a trace makes it difficult to know which part of my code is triggering it), but that's all I can really do currently, it's such an odd edge case.

[EnderRNWL]

Digging deeper into the CPAL code, it looks like the following is happening:

CPAL: Hi Windows, what's your Default audio format? Windows: Use format X CPAL: Windows, do you support format X? Windows: No.

Which unfortunately is a pretty critical break in Windows audio.. I've added some attempts to catch PANICs come from CPAL during device setup and downgrade them to Errs which should hopefully mitigate this (the lack of a trace makes it difficult to know which part of my code is triggering it), but that's all I can really do currently, it's such an odd edge case.

I don't see any pushes for this fix. Where can I access the change?

[EnderRNWL]

Digging deeper into the CPAL code, it looks like the following is happening: CPAL: Hi Windows, what's your Default audio format? Windows: Use format X CPAL: Windows, do you support format X? Windows: No. Which unfortunately is a pretty critical break in Windows audio.. I've added some attempts to catch PANICs come from CPAL during device setup and downgrade them to Errs which should hopefully mitigate this (the lack of a trace makes it difficult to know which part of my code is triggering it), but that's all I can really do currently, it's such an odd edge case.

I don't see any pushes for this fix. Where can I access the change?

Update: I got a different issue entirely. I attached the debug-level log below. goxlr-daemon.log

[FrostyCoolSlug]

I don't see any pushes for this fix. Where can I access the change?

The mitigation (specifically not a fix) was added in 7ba9e16 and released with 1.0.6

Update: I got a different issue entirely. I attached the debug-level log below.

Looking at the log, the issue seems to be the same (except occurring with the recording channel), Windows is reporting a default format then isn't able to open that same format.

Your best bet in this scenario is to re-plug your GoXLR and try to reset the driver, as something's gone wrong with the audio handling that cannot be fixed by the Utility.

[FrostyCoolSlug]

Gonna close this as 'cant fix', the utility will attempt a recovery if the audio subsystem goes down, but obviously can't correct the problem with Windows.

[EnderRNWL]

So it just…fixed itself Somehow I think 1.1.1 fixed the issue, idk