Playback error when using more than 32 samples

Bug #1779559 reported by Andy Fischer on 2018-07-01
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mixxx
Medium
Daniel Schürmann

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

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.

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
Daniel Schürmann (daschuer) wrote :

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

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.

Changed in mixxx:
assignee: nobody → Daniel Schürmann (daschuer)
milestone: none → 2.1.2
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.

Changed in mixxx:
status: Confirmed → Fix Committed
Changed in mixxx:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers