re-enable waveform generation on analysis by default #1006
Conversation
This allows users to run at lower latencies without risk of xruns when loading a track.
Be-ing
changed the title
|
Given that this option causes Mixxx to use a non-negligible amount of disk space for a moderately-sized library (and has the potential to fill up a user's disk,) it should not be enabled without their express consent. Rather than changing the default, it would be better to place descriptive text near the option such as ("Pre-generating waveforms may improve Mixxx's performance") and mention the same in the manual and wiki. |
|
What about asking for their express consent when Mixxx first starts? Or on the first batch analysis?
These are good concerns, but I think Mixxx should prioritize minimizing the risk of audible glitches. |
|
On first batch analysis would be acceptable. (As opposed to peppering new users with questions on first start.) Give an estimate of the space taken as well. (2.5GiB/4000 ~= 700kB per track. You could say "roughly 1MB per track" to allow for differences.) Better still, have Mixxx multiply the number of tracks to be analyzed by that figure and check that the disk holding the library has at least that much space available. An additional warning should be shown before running the analyze if less than 10% of disk space would remain after the operation. |
|
I reopen this just to not loose the discussion. A low latency without a drop-out should be the highest prio. I wonder why are dropouts happen? Is it a race condition with disc access? Maybe the read ahead manager fails to cache the important playing samples because it is filled with the analysis samples .... I think it is worth to investigate that. @Be-ing: do you have audio glitches at low latency if the waveform caching is disabled? We have the disk space issue anyway, given that the user might want to listen the track at least once before he plays it live. I have currently ~ 2 GB waveform data without waveform storing during analysis. I really do not want to delete it but I do not want to waste disk space for old tracks . Deleting seams to be only a band aid for my use case . I just don't want to care about it like the cache of Firefox and It would be nice if at least the waveforms from my prepare session are still there during the gig. Here, a disk space limit would help. Once we have this limit, default = true would be just right. |
|
Good point: there really shouldn't be any latency differences regardless of whether analysis is going on or not. Indeed we should examine that issue first (but this PR isn't the place. Let's move that discussion to mixxx-devel.) And/or a bug. |
It's difficult to reliably make it glitch either way, but the DSP load meter does reliably go higher when a waveform is generated versus loaded from cache. Also, the GUI reliably stutters when starting to analyze a waveform. I think a configurable space limit with the option to use unlimited space would be a good solution. |
|
I'm trying to clean up old PRs to get our open count down. Let's move the discussion / future solution to this bug: |
I have about 4000 tracks in my library and all my waveform data takes 2.5 GB. I used to run Mixxx with a 23.2 ms audio buffer because the load would spike when I loaded tracks from the waveform generation. Now I can now run Mixxx with a 1.45 ms buffer with Soundtouch. Using Rubberband I can use a 2.9 ms buffer with an occasional xrun or 5.8 ms without xruns. This is with a Core i5 2410M running Linux with the realtime patch set. I'm kinda surprised we haven't gotten more complaints about audible dropouts on track load since 2.0 was released.
IMO trading off a bit of disk space for lower latency and better reliability of the audio is well worth it. I think turning this option off only makes sense for storage constrained systems with powerful processors, which I don't think is a very common situation. Storage is cheap, so I think CPUs are more often the bottleneck.