I’m testing various ideas on how to go about a live setup (linux). I thought it would be cool to run two instances of renoise (without jack transport) routed through pure data for crossfading, and then loading instance A while instance B is playing.
This seems to work besides the fact that renoise stutters when loading a song in the stopped instance. Mostly at the “releasing old song” message. Is this a bug in renoise or is there something I could do to improve my setup?
I’m running ubuntu 9.10 w rt-kernel and limits.conf like this:
Sound card is an Edirol FA66 firewore card, @ 128 frames/period (latency = 8ms). Computer is a toshiba laptop, 2G ram, CPU is dual core 2GHz (model name: Intel® Core™2 Duo CPU T7250 @ 2.00GHz)
Is it possible to limit each Renoise instance so that they only use 1 dedicated CPU core each? I wonder how that might work out. I wonder if they would share the resources a bit better then?
<shot_in_the_dark>
Or… perhaps you can tweak things a bit to give background apps slightly higher priority (this can be done in Windows). That way, when you have the next song loading in the foreground, and the current song still playing in the background, the background copy of Renoise should get a bit more love from the OS/CPU and not choke so much.
Well linux works the other way around, giving high priority to software with realtime needs (renoise) and hardware used by it (soundcard, rtc, stuff like that).
I’m wondering if there’s “something” inside renoises audio thread that shouldn’t be there. No loading, mem-freeing or stuff like that going on there??? I’d love to hear a comment from a dev, can you reproduce my experience?
NB: I’ve played with it, and at 32ms latency with standard ubuntu I can load without stutter in the running renoise instance. But 32ms seems a little too much, and I feel I should be able to go much lower…
Ok, I’ve played a bit more with the issue and I’m pretty sure the problem lies with renoise, call it a bug or not.
I patched and installed a realtime kernel, which was the wildest thing I ever saw. 1ms latency with rock steady audio playback in renoise, while I could punish the machine with everything to 3d graphics, compiling a kernel, opening programs, surfing the net, whatever.
The only thing that could make renoise stutter was another instance of renoise loading a song (while having one loaded already). I had to go to 32ms latency for the stutter to go away, which is the same latency I found performed the two-instances-of-renoise-thing without stutter on plain ubuntu kernel.
I’d really appreciate it if the devs would look at this, hopefully it’s just a matter of re-structuring some code. I’m not gonna do your job for you, but (as I mentioned before) it feels like something bad (something to do with “releasing the song”) is happening in the audio thread.
I’d be willing to help in any way I can, just let me know!
Yes, there indeed a lot happening in the audio thread when loading/releasing a song. Usually this is not really a big deal.
I’ll take a look at this and try to optimize this a bit in one of the next releases…
Exactly. Under the (very sane) assumption that the user loads a song, plays it/works with at (expecting glitch free performance), and closes it again. I also never had the slightest trouble before trying this.
But I really think a dual renoise setup is the way to go for a live setup.
