playback suddenly stops, Mixxx becomes unresponsive (spinning beach ball)

[m0dB]

Bug Description

This has happened twice now in (very rough estimate) 50 hours (sessions of 3+ hours).

Playback stops, both audio and visual. Application becomes unresponsive with a spinning beach ball. Console shows the following warning:

VisualPlayPosition::calcOffsetAtNextVSync "[Channel2]" no transport (offset > maxOffset)
VisualPlayPosition::calcOffsetAtNextVSync "[Channel1]" no transport (offset > maxOffset)

After force-quit and restart all is back to normal.

This is using a Hercules Inpulse 200 as external audio interface.

Anyway idea what this could be and how to debug it?

Version

2.5

OS

macOS 14

[m0dB]

I was thinking that maybe the USB connection was temporarily lost, but if I unplug the device, I do get the same warnings, but the application stays responsive.

[Swiftb0y]

That just sounds like a plain crash. Doesn't macOS collect logs for this stuff? Otherwise you may try to run mixxx in a debugger during your sessions so you can at least catch a backtrace when it happens. Not sure how to debug this sort of stuff on macos though.

[m0dB]

No, certainly not a crash. Mixxx enters a busy state, probably an infinite while loop. I suppose the warning could be part of the cause or it could be the consequence.

I will start running debug builds in the debugger and hope it occurs again.

[daschuer]

I had similar situations in Linux with very low latencies or after sleep mode. It is like a partial crash or lets say deadlock of the Engine Thread driven by Portaudio.

With the debugger you will find out where it hangs. Maybe we can review the situation be configuring the audio.

This is a long standing bug by the way:
#13801
#5146
#6150

[m0dB]

Interestingly, unplugging doesn't cause the hang. And (un)fortunately, the bug is really extremely sporadic, I have been running for many hours in the debugger yesterday without issue.

But I think we are mixing different issues here: one this bug, the other the feature requests to be able to restart the audio engine and to detect changes in the device list. I am familiar with the Core Audio mechanics, but not with Portaudio.

It certainly would be nice to have these features; having to restart Mixxx can be quite disruptive! But it doesn't help with Mixxx really hangs like this and a force quit is needed anyway.

Edit: Oh, I just realised there is a Query devices button! So the feature request is to automatically detect and act on a device that has disappeared and reappears. Still, doesn't solve the deadlock...

[m0dB]

Do you have any suggestions how I could trigger this deadlock? I have been unplugging and reiniting my sound card like crazy, but it works fine. I could do some programmatic stress test, but I don't really now what to stress...

[daschuer]

In Linux a sleep mode cycle creates the issue. Is this also an issue with macOs?

[m0dB]

No, that works fine.

I tried killing the CoreAudio daemon, and obviously it stops playback (duh) but I can't reproduce a app hanging like this either.