Waveform stops rendering when DVS is CUEed

Bug #1980264 reported by Nicolas MURE
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
New
Undecided
Unassigned

Bug Description

Hello,

Bug appears on Mixxx 2.3.3 (I installed it via flatpak, but I suspect all the other distributions ways are affected).

Steps to reproduce :

- Load a track on a DVS deck.
- Play the track and set multiple hotcues.
- Press the CUE button : the playback stops and the cursor position goes back to the CUE point. All good so far.
- Press any hotcues previously set : the cursor moves to the hotcue, but the waveform is not updated (i.e. the cursor is still displayed on the CUE position due to the lack of waveform rendering update, but the cursor position is actually on the pressed hotcue).
Press play : the waveform is rendered as usual with the cursor position starting from the pressed hotcue (feels like a jump due to the lack of rendering in the previous step).

Mixxx 2.3.2 was fine, I suspect https://github.com/mixxxdj/mixxx/pull/4789 and https://github.com/mixxxdj/mixxx/pull/4791 to be the cause of the issue. Why in these PRs there is no check about `passthrough` mode if the passthrough was the issue (i.e. like https://github.com/mixxxdj/mixxx/pull/4787 has attempted to do) ?

Note : I'm not using the passthrough mode.

Thank you for your help :)

Revision history for this message
Nicolas MURE (nm2107) wrote :

Additionally, when loading a track on a deck where there was already a track (which is stopped), the waveform of the new track is displayed as empty, until the track is played.

Nicolas MURE (nm2107)
description: updated
Revision history for this message
Nicolas MURE (nm2107) wrote :

Just to confirm that commenting the `return` statement in this code block fixes my issue :

https://github.com/mixxxdj/mixxx/blob/2.3.3/src/engine/enginebuffer.cpp#L1260-L1270

However, commenting only the `m_filepos_play == kInitialSamplePosition` part of the condition doesn't fixes the issue.

I understand the `m_trackSampleRateOld == 0` and `m_tempo_ratio_old == 0` checks to prevent division by `0` (operated a few lines later), but why is the `m_filepos_play == kInitialSamplePosition` check for ? And also, why am I entering the condition body ? Only because the DVS signal is quiet (i.e. I am on a CUE point) ? Shouldn't we perform an other check to determine whether we're playing instead of relying on the `tempo_ratio` ?

Revision history for this message
Nicolas MURE (nm2107) wrote :

It seems that the proposed fix (that actually introduced my issue), was attempting to fix an OOM about beat painting in waveform rendering (c.f. https://bugs.launchpad.net/mixxx/+bug/1977662/comments/3 ).

In that case, why the proposed fix has introduced the condition pointed out in my previous comment, instead of dealing with the OOM where it happens ? (i.e. make a check in the waveform beat rendering instead) ?

Revision history for this message
Nicolas MURE (nm2107) wrote :

Do we need this condition https://github.com/mixxxdj/mixxx/blob/2.3.3/src/engine/enginebuffer.cpp#L1260-L1270 if the one right above checks for deck passthrough already ?

Revision history for this message
Nicolas MURE (nm2107) wrote :

Meanwhile I made myself a patch commenting the condition : https://github.com/nm2107/org.mixxx.Mixxx/commit/b5f356d67d436184a4dfd1d1be585f9497ba5ee6

This temporarily fixes my issue, but I need some advice for a proper fix.

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote (last edit ):

The engine code is old with lots of undocumented dependencies and unknown side effects that no one is aware of. Fixing one bug might cause new bugs.

I suppose no one is able to give advice on how to fix this properly. It is pure trial and error while trying to understand the code.

tags: removed: dvs rendering
Revision history for this message
Swiftb0y (swiftb0y) wrote :

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

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.