Playback error when using more than 32 samples

[mixxxbot]

Reported by: andymann
Date: 2018-07-01T14:56:59Z
Status: Fix Released
Importance: Medium
Launchpad Issue: lp1779559

---

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

[mixxxbot]

Commented by: kazakore
Date: 2018-07-02T09:21:59Z

---

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.

[mixxxbot]

Commented by: Be-ing
Date: 2018-07-02T14:59:44Z

---

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.

[mixxxbot]

Commented by: daschuer
Date: 2018-07-02T15:35:16Z

---

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

[mixxxbot]

Commented by: Be-ing
Date: 2018-07-02T15:43:38Z

---

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.

[mixxxbot]

Commented by: daschuer
Date: 2018-07-02T23:03:42Z

---

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

[mixxxbot]

Issue closed with status Fix Released.