Mixxx

Playback error when using more than 32 samples

Bug #1779559 reported by Andy Fischer
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
Medium
Daniel Schürmann
Mixxx 2.1.2

Bug Description

As far as I can tell this happens on versions 2.1 and above. Also testet with the latest alpha from the repo which was built on a Raspberry PI. I tested in on Ubuntu, RPI and Mac. Problem does not occur in version 2.0 on a Mac.

As long as there are not more than 32 samples in ypur samplers (for example using skin "Deere (64 Samplers)") the samples play fine.

As soon as the 33rd sample is added the playback of every sample gets corrupted. It doesn't matter which cells of the samplers are populated. the problem occurs in every skin.

Link to video for a better explanation: https://youtu.be/cdrDR42ePlc

Revision history for this message
Dale (dj-kaza) wrote :

Confirmed.

It appears to depend on the L/M/R bus of the crossfader though. Once you have more than 32 Samplers assigns to one of these buses get what sound like some kind of buffer dump/glitch/repeat issue. If you have Samplers assigned to different crossfader buses, so no bus ever has more than 32 sources, this doesn't happen. Main Decks (Channels) being on that Bus doesn't seem to affect the number of Sampler channels that can be. Also doesn't matter if the Sampler is playing or not, it only has to be loaded.

Revision history for this message
Be (be.ing) wrote :

This probably happens because the mixing of <32 channels uses different code than >= 32 channels. I think it is time to remove the overcomplicated and difficult to maintain autogeneration of the ChannelMixer functions from a Python script and just use one loop.

Changed in mixxx:
status: New → Confirmed
importance: Undecided → Critical
importance: Critical → High
importance: High → Medium
Revision history for this message
Daniel Schürmann (daschuer) wrote :

Let's just fix the bug.
The code is there for performance reasons and has worked well originally.

Revision history for this message
Be (be.ing) wrote :

I don't understand how the code autogenerated by the Python script is faster than a simple loop. That may have been the case before postfader effects were implemented and the mixing and volume fader attenuation were coupled in one giant line of code, but I am doubtful that is still true. It would be worth measuring the performance though.

Daniel Schürmann (daschuer)
Changed in mixxx:
assignee: nobody → Daniel Schürmann (daschuer)
milestone: none → 2.1.2
Revision history for this message
Daniel Schürmann (daschuer) wrote :

https://github.com/mixxxdj/mixxx/pull/1736 fixes the issue.

I think a main CPU saver can be: to not process the samplers when not playing.
This would be a major CPU Saver.

Daniel Schürmann (daschuer)
Changed in mixxx:
status: Confirmed → Fix Committed
Daniel Schürmann (daschuer)
Changed in mixxx:
status: Fix Committed → 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/9363

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.
Subscribing...

Other bug subscribers

Remote bug watches

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