setting hotcues causes dropout

[Owen Williams]

Setting hotcues used to be transparent -- the cue would get set and the track would keep playing, even if they were quantized. Now there is a noticeable dropout when I set a hotcue. It sounds like the track is seeking or pausing momentarily. Happens every time.

(current trunk)

[Owen Williams (ywwg)]

hm actually it's just an underrun. not sure what we're doing that's so intense though.

[Owen Williams (ywwg)]

I see this occasionally even with 20ms latency, which has always been fine before. This shouldn't be causing xruns.

[Ferran Pujol (ferranpujol)]

I can sometime reproduce the xruns, however I have to setup a very low latency and I can't determine what makes them happen, as they don't appear every time I set a hotcue.

[RJ Skerry-Ryan (rryan)]

The only thing I can think of that changed here since 1.11 is that we now lock the CueControl mutex a lot more from the callback (Daniel's cue indicator changes combined with queued seeking).

It was always possible to cause an xrun while taking any hotcue or cue action since hinting the reader happens once per callback (which locks the CueControl mutex). So you always could get unlucky -- it's just more likely now?

[Be (be.ing)]

I cannot reproduce this.

[Launchpad Janitor (janitor)]

[Expired for Mixxx because there has been no activity for 60 days.]

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/7459