I seem to get queries about this every couple of weeks and while I know the status of this in my head maybe this'll help others.
As of the merging of the new sound hardware preferences (last Fall, I think), latency has been restricted to (approx) 40ms. FYI, it's approximate because our latencies work out to be something like (hope this lovely table works):
Sample rate (Hz) | 44100 | 48000 | 96000
Buffer Size (frames) | | |
64 | 1.45 | 1.33 |
128 | 2.90 | 2.67 | 1.33
256 | 5.80 | 5.33 | 2.67
512 | 11.61 | 10.67 | 5.33
1024 | 23.22 | 21.33 | 10.67
2048 | 46.44 | 42.67 | 21.33
4096 | 92.88 | 85.33 | 42.67
8192 | 185.76| 170.67| 85.33
16384 | | | 170.67
And the number of available latencies is controlled by a constant (MAX_LATENCY) in soundmanagerconfig.h. MAX_LATENCY is actually an index -- because latencies are calculated as a formula (they're a product of sample rate and buffer size, which is itself a power of 2), it's easier to identify a latency by index if you want to identify `equivalent' latencies across sample rates. Before my pref rewrite, the MAX_LATENCY value was effectively 8 -- however, it was actually impossible to choose the highest value (185ms at 44.1khz, 170ms at 48khz and 96khz) due to a bug, so the 92ms (for 44.1khz) and 85ms (for 48 khz and 96khz) values were the highest one could choose. As I was working through my code, I noticed that when the engine was asked to generate buffers 8192 samples long (or 16384 at 96khz), it resulted in terrible screeching sounds on seeking and other similarly disturbing behaviour. On extensive testing, I was able to reproduce the same at 4096/8192(96khz) buffer sizes, so I consulted others and it was decided to drop support for those latencies for the time being (so latencies greater than 46ms or 42ms were no longer).
Apparently that's not high enough for some computers or audio interfaces (or combinations), but the problem *isn't* the preferences code, it's a problem lurking somewhere murky in the engine. Even if the terrible screeches are less common at 85ms/92ms than they are at higher latencies/buffer sizes, I'm not going to be ok with increasing that constant because there's a really high probability of someone else, or the same someone, showing up with reports of hideous screeching noises in the middle of their show with mixxx and how it totally ruined the night and how their sponsor/bar owner now hates them. Reputation is everything in DJing, and mixxx is actually starting to make gains -- it should be top priority to make sure regressions of this sort are not made. The drunk are quite fickle; nasty audio disturbances are enough to send them elsewhere, get a DJ sent on, and lose Mixxx a user.
Apparently someone awesome (Owen?) fixed the engine bug that was making for weird audio distortion at large buffer sizes sometime post-1.9. Therefore, the ~80ms latency option has been re-enabled in 1.10 (r2838) and trunk.
Because ~80ms latency implies controlobjects are only synced ~12 times/second, GUI elements depending on engine status data (waveform, VU meters, ...) appear somewhat jerky at higher latencies but that's to be fixed another day.