locking a mutex from the audio thread when reading cues

[daschuer]

Bug Description

This is a regression from #4771
The used mutexes are here:

mixxx/src/track/cue.cpp

Line 141 in 006fc86

const auto lock = lockMutex(&m_mutex);

mixxx/src/track/track.cpp

Line 961 in 006fc86

auto locked = lockMutex(&m_qMutex);

Version

2.4-alpha

OS

all

[Swiftb0y]

If the regression is really from #4771 then it seems like the problem lies in the findCueByType here:

mixxx/src/engine/controls/cuecontrol.cpp

Lines 1270 to 1278 in 7307fc9

	TrackPointer pLoadedTrack = m_pLoadedTrack;
	if (pLoadedTrack) {
	CuePointer pN60dBSound =
	pLoadedTrack->findCueByType(mixxx::CueType::N60dBSound);
	if (pN60dBSound) {
	const mixxx::audio::FramePos frame = pN60dBSound->getPosition();
	appendCueHint(pHintList, frame, Hint::Type::FirstSound);
	}
	}

We could either revert it as a quick fix or put it in somewhere that is not called from the audio thread (CueControl::trackLoaded maybe?). Why is CueControl::hintReader called from the audio thread anyways?

[daschuer]

We "just" need to introduce a control object like for the other cue points.

Why is CueControl::hintReader called from the audio thread anyways?

Sure, there is room for optimization ...

[Swiftb0y]

We "just" need to introduce a control object like for the other cue points.

I highly doubt thats the best solution. What does the current bug look like? Audio buffer underruns because of priority inversion?

[daschuer]

I have not noticed that as a bug, it was a catch during debuging, but this may cause a buffer underrun whenever setting a cue point in a playing track.

I highly doubt thats the best solution.

Yes, It is sufficient to cache the position value in a
ControlValueAtomic<double> m_n60dBSoundStartPosition;

[JoergAtGithub]

@daschuer Can we close this?

[daschuer]

Yes.