i am using Renoise on Crunchbang (#!) Linux, and experience GUI lag. what this means is that the patterns don’t roll as smooth as they should, the waveforms don’t play as smooth as they should, and, most noticeably, when i use my mousewheel to scroll up/down in the Pattern Matrix, the scrolling is jittery and laggy. this does not happen in the Pattern Editor or anywhere else i’ve seen.
now, it is very possible this is a Linux-issue. i’ve read some other threads and there is just a lot of stuff to reckon with when it comes to things like this. the funny thing is i’ve never noticed any GUI lagging on any other GUI-related stuff i’ve done in Linux, so it is Renoise-exclusive. which is why i am making an attempt at asking here, instead of in the Linux forums (plus, they might not be familiar with the software or not have it installed, so it gives them a disadvantage i think)
Did this problem raised from the beginning of trying or did you had Renoise running perfectly on Crunchbang for a while before this issue popped up?
And if the latter, what changes did you made or what system updates did you allowed to automatically install recently?
@vV: not 100% sure if it has always been there. i never had Renoise running smoothly on Crunchbang until a while ago when my audio worked properly after some fiddling with settings (in Jack). since then i’ve stopped booting into Win7 just to use Renoise.
@taktik: running Jack, with realtime switch, Frames/Period set to 4096, Periods/Buffer set to 3. (using these settings after my experiments, as they turned out to give me good results on audio)
i had no idea that the buffer settings could cause GUI lag as well. figured it was just for the audio.
thinking: would this just mean it is one or the other? so a certain buffer works for your audio but gives you some GUI lag?
often with this linux-stuff, i think ‘how does Windows do it?’
or could it maybe be my GPU drivers… i have an ATI-card which is notoriously undersupported. currently using the open-source drivers but i can try the proprietary drivers as well…
That makes up a total latency of 4096*3 samples, 279 ms at 44100 kHz. That’s an enormous amount of latency.
For the GUI only the 4096 is relevant, but that’s still whopping.
^ yeah i figured as much. really had trouble getting Renoise to work without pops and clicks on linux… so it seems like i either have to learn to live with the GUI-lag (which is not that hard to do really), or review my setup (which is a lot harder, i find this stuff damn difficult).
so i’ll just go with your answer that this the whole problem, and leave it at that. clearly not a problem with Renoise but, as i suspected, with my own setup. damn. i hate it that stuff works out-of-the-box in Windows, which is crappy OS, and doesn’t on Linux, which i love for everything else. i hoped to get out of my dual-boot situation eventually, but might just postpone that for a bit…
thanks for the attention anyway man, appreciate it! you too vV.
marking this, well, not solved, but something.
This doesn’t sound like pure latency/lag to me. Is it definitely jittery/jerky movement as you scroll? What about if you use high BPM/LPB and have Pattern Follow enabled? I expect you to see the source note of the sound after you hear it (1/4 second latency) but scrolling should be smooth.
Linux video drivers are something I have had a lot of problems with (and one of the main reasons I keep on coming back to Doze.) Video playback without tearing is something I have generally failed to get. I noticed in Renoise, watching the position cursor as a long sample plays it sometimes appears not to be a single line. I can’t remember what GUI/graphics card options there are in Renose Preferences for Linux but I assume you have had a look at these.
Even using the onboard Realtek HD chipset I would think you can get better than 4096/3 buffers with no xruns on a light/mid project. Some chips run better with 2 sample buffers than 3 sample buffers although 3 does seem to be more popular from all the reading and little bit of playing I have done myself.
not sure if this helps but its worth a shot. last year i was trying to get good audio going with jack without getting xruns, and i kept changing setting in jack but the xruns were always there. i eventually discovered network manager was causing these xruns so simply disabling networking while i worked on audio cured that and allowed me to run with reasonable jack settings. now im not sure if youre using network manager or if the problem still even persists but i figured i would share my experience on that.
thanks for that phooka. by ‘network manager’, i assume you mean the actual application named ‘network manager’ (and not a generic network manager)?
i have configured /etc/network/interfaces directly myself, so NM is not interfering here. but i suppose others looking for solutions here will definitely find this of use.