The problem unfortunately isn’t on/off, but incremental.
I switched back to jack2, and with the xrns I linked to and latency of 17.4 I don’t get xruns when looping pattern 11, but with pattern 23 I do. It’s like renoise is spending more time figuring out how to handle the auto seek samples, the more of those that are triggered before the playback point. Even if there have been triggered new samples on the columns where the first ones appear, in which case it should simply not care about the first ones, as they have been “replaced”.
I know that jack support in a closed source app can be tricky, since there tends to be a mud-throwing contest going on. The jack devs might say “it a problem in your code, but we can’t help you because it’s closed”, and the closed app devs might say “it’s jack’s fault”. This is very unfortunate, since this hinders closed source apps on linux.
However from a users (mine) point of view, I just can’t live with stuff like this. Ardour handles long-file playback (although from disk, but that should be even more tricky) fluently, renoise works very well, uses very little CPU, and is in general very, very bug free. There might be technical challenges with long files, autoseek could be seen as a “nice bonus, don’t use it if it doesn’t work for you”, but I really need it. Technical problems should be fixed or at least looked at by the devs. Taktik replied once to the old thread 2 years ago! I’d really appreciate if he would look at this thread and my discription of the problem again or at least comment…
It’s expected that Autoseek generates small CPU spikes, cause it has to crawl large parts of the song in realtime in order to find out where and how (at which volume, panning, pitch and so on) a sample exactly continues playing. With very small audio buffer sizes, and lots of autoseeked samples, those small CPU spikes may then cause XRUNS. The larger the buffer size, the more likely it is that the CPU spikes can be “catched up” again.
This can be avoided by only using autoseek when really necessary (don’t enabled it on every sample) or increasing the buffer sizes.
Another easy way to help avoiding this lookup overhead, is to explicitly place note-offs into the patterns, even when the autoseeked sample already finished playing without a note-off. Autoseek lookups do stop at note-offs, so you can easily shorten the lookups this way.
It should be possible to either cache those informations or spread the calculations over time. At least for the most common cases.
Say I have a loop set up in the pattern sequencer. There’s plenty of time for renoise to calculate the sample offset to be used for autoseek samples at the loop point. Same when I’m pressing start, renoise could prepare for that.
If the sample offsets of all autoseek samples were cached for the 0th lines of all patterns, the most common cases would be covered.
Alternatively, I’d like a more straight ahead way of handling long samples. I only use if to trigger long “play back as recorded” samples, vocals, stuff like that. I don’t use sample effect, envelopes, I don’t even pitch them up or down. I just play them back exactly as recorded. A tick next to autoseek that disabled all the fancy stuff that hogs renoise when handling them, for use in cases like mine would be fine too…
Or (re)freeze the track on any specific sample application change (pitch, volume,etc) . This would consume more memory but allows a lot less routines to be required to run realtime but the sample specific effects still get applied anyway.
Any faster solution would be to start looking for a quadcore or faster cpu machine. In the near future Duo Core will turn museum material. My current quad core is already museum material, but it still works fine. As soon as i need more power, i will upgrade though and not only for Renoise.
You may have a reasonable point, but there comes a day where you are going to ask something like you want to run a DX11 game just as smooth and shiny on a Dx9 compatible gfx board and in that case:you know for sure that will never work or it won’t ever run with top-notch graphics enabled.
At least i’m already worried what your problems would be when Direct From Disk would enter the scene, but that requires a complete rewrite of the engine, so perhaps in that case, the autoseek would perform perhaps also a lot better.
My system performs very well, thanks you very much. I recently mixed a demo for band in ardour, not sure about the number of tracks, but some where above 20 + effects, 0 xruns, no glitch.
If I slice refer from using autoseek, i can tax my renoise projects with as many tracks and dsp i like, no problems.
It’s only when autoseek comes into play i get hickups, which is why i insist it’s a bug…
fwiw i have this issue on a brand-new ivy bridge core i5 system, so i would say that system newness or system specs doesn’t really play a part here.
the track, when it plays, uses a healthy 60% of the CPUs (according to renoise).
