Master Sync user offset / Internal clock beat distance not being reset after mouse scratch

Bug #1403232 reported by xorik
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
Medium
Owen Williams

Bug Description

Hi there.
I've just tested mixxx from git and find one issue with master sync.

It is pretty easy to check it:
1) create sin tone in any sound editor (e.g. default 30 sec of 440Hz in audacity)
2) load it into mixxx
3) enable master sync for this deck
4) try to rewind track with mouse and click "master" button (e.g. in deere skin)

You can hear: the tone will be changed a little bit.
If you record this and watch spectrogram, you can see like this:
https://i.imgur.com/IbKmS4t.png
https://i.imgur.com/UCXfBXQ.png

Revision history for this message
xorik (xor29a) wrote :

Here I recorded some demo to listen

RJ Skerry-Ryan (rryan)
Changed in mixxx:
milestone: none → 1.12.0
Revision history for this message
Owen Williams (ywwg) wrote :

There should not be any master buttons in any skins. Explicit master selection is not supported

Revision history for this message
Owen Williams (ywwg) wrote :

this could be because there is no bpm information.

Revision history for this message
xorik (xor29a) wrote :

> this could be because there is no bpm information.
You can try any track to check this bug, e.g. with beats.

If you try to mix with enabled master key, tracks can be random change their pitch and key, without touching anything, just navigate buttons and temporary pitch up/down

Revision history for this message
Owen Williams (ywwg) wrote :

I don't understand, if you click the pitch up and down buttons of course the tone will change. Are you saying the pitch is changing even if you let it play and don't touch anything? Also even if you have keylock on the pitch will change when you move the mouse because keylock sounds really bad at high rates of acceleration. If I could see a video recording of what you're talking about it would help.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

I have managed to reproduce the issue
* Load a 1 K tone to deck A add a beatgrid manually
* enable key lock
* Play a second track as Master
* Sync test tone to the other track
* change speed slider of the master track
* Test tone produces an audible pitch change
* I think the same will happened if the master beat grid is not const.

You can produce the same issue when you just move the speed slider of the
test tone.

Other known issues:

(Waveform) scratching disables key lock in any case.
This is the desired behavior, because the non linear scalers are not working reliable when you do fast tempo changes.
And maybe this is the same issue here.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

@xorik: is that the issue you see?

Revision history for this message
xorik (xor29a) wrote :

I know, scratching changes key tone, I talk about key after scratching. It changes randomly, when master sync is enabled.

@daschuer not sure this is same bug, because I not use 'key lock' and use constant bpm.

I'll try to record video to demonsrate the bug.

Revision history for this message
xorik (xor29a) wrote :

Very strange: when I change audio output from ALSA to jack, bug disappears. So I switch back to ALSA and it can't repeat the bug anymore...

So I can't record video now, and I try to make better testing.
Maybe someone can reproduce it? Just hear the demo and look at images in first posts

Revision history for this message
Daniel Schürmann (daschuer) wrote :

Just noticed your test tone is 4400Hz, is it correct or just a typo for 44100?

Can you add more details to your steps to reproduce and can you match them with the spectographs?

Normally the Audio API should not notice any difference if you scratch or not. It just consumes samples in a constant rate.
There could only be an underflow issue, but that should not happen at a linear pitch.

Did you test on a 64 bit or 32 bit machine?
I have recently re-factored the pitch code a bit and have fixed a rare race condition on 32 bit Os.
So you may check https://github.com/mixxxdj/mixxx/pull/415 if you like.

Revision history for this message
xorik (xor29a) wrote :

@daschuer, no, tone is 440 Hz (https://i.imgur.com/IbKmS4t.png), but it is higher after scratching or pressing master button (listen attach in 1st comment)

Revision history for this message
Owen Williams (ywwg) wrote :

xorik, the recording you posted is not really useful because we can't see when the track is playing back at standard rate and when you're using the mouse

Revision history for this message
Daniel Schürmann (daschuer) wrote :

Maybe we have two issues:
1. Rate is not reset after mouse scratch. Right? How do you reset the error pitch by a play pause cycle?

2. Master sync effects rate by a minor value when it not should.

2. Might be a rounding issue, we may hear a difference between no re-sampling and re sampling by 1.0000001 in the lat part of the sample. What is the sample rate of your test tone? Is your current sample rate again 44100 or was it changed due to the Jack test?

Does your test sound have any beatgrid? Which master button do you press when and what happens with the second track?

Revision history for this message
xorik (xor29a) wrote :

Oh! I found why I cant reproduce bug:
It works only when quantize and master sync both is enabled. I'll make video with demo in few minutes...

Revision history for this message
xorik (xor29a) wrote :

demo: http://youtu.be/1vBctN4maWA (watch with enabled annotations)

Revision history for this message
xorik (xor29a) wrote :

@daschuer
Please watch video. If you replace 440 Hz tone with any music track, issue will still present (no matter what bpm or sample rate has this track)

Revision history for this message
Owen Williams (ywwg) wrote :

oh ok. this is because master sync isn't properly resetting the user tweak after a mouse scratch. sigh.

Owen Williams (ywwg)
Changed in mixxx:
importance: Undecided → Medium
assignee: nobody → Owen Williams (ywwg)
summary: - random key shift when master sinc is enabled
+ Master Sync user offset not being reset after mouse scratch
summary: - Master Sync user offset not being reset after mouse scratch
+ Master Sync user offset / Internal clock beat distance not being reset
+ after mouse scratch
Revision history for this message
Owen Williams (ywwg) wrote :

I pushed a fix to master, let me know if this fixes it. After scratching is complete I sync phase to get the track back in line with the internal clock.

Revision history for this message
xorik (xor29a) wrote :

ywwg: nothing changes :( I think something wrong with playing speed, not phase after scratching and after pressing "master" button

Revision history for this message
Owen Williams (ywwg) wrote :

it is, because if the deck is out of sync the master sync code will change the speed of the deck to push it back in sync.

stop using the deck master button, I already said it's not supported.

Revision history for this message
Owen Williams (ywwg) wrote :

If you can reproduce the bug without using the master button, please let me know -- I'm just not focusing on the explicit deck master mode right now.

Revision history for this message
xorik (xor29a) wrote :

ywwg, bug still presents, when quantize enabled, but now it is harder to reproduce it (I need to do many scratches, before tone changes)

Revision history for this message
Owen Williams (ywwg) wrote :

I'm sorry, I can't reproduce this issue. This is what I'm doing:

1. start a very long track in deck 2, turn on sync and quantize.
2. load a sine wave in deck 1, turn on sync and quantize.
3. press play on deck 1.
4. scratch deck 1, let go

I see the deck snap into position and keep playing at the correct rate, no audible change.

Changed in mixxx:
status: New → Incomplete
Changed in mixxx:
status: Incomplete → Invalid
status: Invalid → Fix Released
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/7735

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.