I have found something strange using the Recording function in Renoise:
When I record a sample using the “Pattern” mode function, and after when I Maximize the sample during playback, I can hear cracks during the Maximise operation, or Volume operation…
Even when I Undo the Maximize or Volume operation.
The sample I record is not big, only 4 seconds…
It seems to be like that even when the sample is no playing in the playback.
BUT…
When I record a sample (more than 20 seconds) without the “Pattern” mode, no cracks appears in the playback during the Maximize operation, or during the Undo operation…etc…
It seems that renoise does not give the full priority to the playback, when doing audio operations on samples recorded in “Pattern” mode function using the Audio Recorder.
No problem with the other samples imported with the file browser.
It is very bad in live sessions…
Not tested in Renoise V1.9
I’m on Debian Etch, using Jack, a firewire audio card, tested with 16 ms latency (a lot!!), and no xruns appear in jack.
Not many FX, CPU working only at 10%
When I record a sample using the “PATTERN” function in the Sample Recorder, I always have craks inside the playback during audio operations on this sample; and when I “Undo”, then “Redo” the operations I did on this sample (ex: “Maximise” the sample, then “Undo”, then “Redo”, etc… then “Undo”, then “Redo”…) it gives cracks in the playback->the sample IS NOT in the sequence…and it happens even with short samples (4s)
BUT
When I record a sample WITHOUT the “PATTERN” function in the Sample Recorder, everything seems ok. When I’m using audio operations on this sample, like above, no problem during the playback, even with a long recorded sample (more than 30s).
ALSO
Once, when I was reproducing the bug (after recording a sample in “Pattern” mode), then going fast with the “Undo”-“Redo”-“Undo”-“Redo” etc… on the sample (after a “Maximize” operation - playback was ON, the sample was not in the sequence) changed the wave itself, making a sample full of horrible cracks inside, like a horrible distorded sample! The playback was near to crash, but didn’t! No Xruns were found in Jack!
For sure, everything happens in the Sample Editor!
The song I use is short, not a lot FX, CPU at 10%, Jack at 16ms…nothing hard for my computer…
While recording, I don’t play around with some of the samples by editing them in the sample editor!
the libc6-i686-2.3.6.ds1-13etch5 changed to libc6-i686-2.3.6.ds1-13etch7
Now, the bug seems to be resolved now…
But when I try to reproduce it, I have sometimes a little crack in the playback. (it is much more better than before the update).
It never happens with other samples imported, or recorded without “Pattern” mode function.
I have the impression that “Undo-Redo” operations on samples recorded with “pattern” function are slower than operations on other samples (with same length)…
So you simply get crackles when recording in Pattern modes. Its just that they are more noticeable when maximizing the sample after recording, right?
I’ve carefully tested this here again but can not replicate the problem here. I doubt that this is a priory problem, because the pattern modes do require as much CPU/priority as the other modes. Its just that the recording start and stop is “synced”. Also you would get xruns then.
Does this really happen every time for you? Can you replicate this by starting a new Renoise song, then recording something that you route through the microphone?
Does increasing the latency help? Does using Jack instead of ALSA (or vice versa) help?
Btw, you wont see XRuns when running Renoise with ALSA in the standard output. Only Jack dumps them, we don’t.
No!
I have not crackles inside the recorded sample!
The crackles appear in the playback only when I “Undo” and “Redo” an audio operation on this sample.
The crackles appear at the moment when I press Ctrl-Z or Ctrl-Y. It is not systematic, but 3 times/5, and much if I go quickly with Ctrl-Z / Ctrl-Y.
Ctrl-P/Crtl-Z loop gives only crackles for Ctrl-Z!
Only Ctrl-Z / Ctrl-Y give crackles in the playback.
Example:
I record a sample in “Pattern” mode with sample Recorder. (with 40ms extra latency)
I maximize the sample with Ctrl-P (No crackles in the playback, during the operation).
I “Undo” the maximize operation (crackles appear in the playback during the “Undo” execution)
I “Redo” the maximize operation (crackles appear in the playback during the “Redo” execution)
I “Undo” the maximize operation (crackles appear in the playback during the “Undo” execution)
I “Redo” the maximize operation (crackles appear in the playback during the “Redo” execution)
etc…
No Xruns in Jack, 16ms latency time!
I have noticed that the crackles don’t appear when playback is Stopped.
Also, i can see that “Undo” and “Redo” on samples recorded in “pattern” mode take much more time than on normal recorded samples. (the tracks scope is freezing more, and then crackles appear…)
It is the same with PDC ON or OFF.
As I said before, there is no problem with long samples recorded in normal mode (more than 30s!)
I have tested with a new song, and there is no problems! Just one sample, no effects, no midi tracks…no crackles when I try to reproduce the bug.
Today I had new updates again on my 64studio distrib :
the libc6-i686-2.3.6.ds1-13etch7 changed to libc6-i686-2.3.6.ds1-13etch8
the libc6-2.3.6.ds1-13etch7 changed to libc6-2.3.6.ds1-13etch8
the libc6-amd64-2.3.6.ds1-13etch7 changed to libc6-amd64-2.3.6.ds1-13etch8
the libc6-dev-2.3.6.ds1-13etch7 changed to libc6-dev-2.3.6.ds1-13etch8
I have tested again, before and after the update, rebooting, etc…, but it is the same problem.
Yesterday I was thinking it was better with the first update, but not…sorry.
But with the libc6-i686-2.3.6.ds1-13etch5, much more crackles were in the playback…I know that there was a grave bug in this package, that is why Debian did the update…But I don’t know if it has an impact of what happens right now…It seems that there is less crackles now, but they still exist…
Also, I had this once when I was still under libc6-i686-2.3.6.ds1-13etch5.
I have tested with ALSA, and it seems good! No crackles!
I will recompile jackd with the new updates, then I will tell you…
Here is some infos:
10 midi tracks muted, no VSTi
07 audio tracks (with a total of 12 native and ladspa effects all disabled).
22 samples.
02 send effects tracks muted.
All the effects are disable.
All the tracks are Muted, except one for routing the signal thrue a mix table in the Sample Recorder, and of course the Master track.
The song is 12 Mbytes length.
tested on one pattern → CPU=2.5%
My config:
Debian 64Sudio
Windowmaker compiled
Linux 64studio 2.6.24.7-rt13 #1 SMP PREEMPT RT
JACK Audio Connection Kit - Qt GUI Interface
Version: 0.3.3
jackd 0.109.2
Freebob using Firewire port 0, node -1
Well, I have been active to experiment things on these strange crackles…
I have recompiled jackd -> still the same crackles in the same conditions.
I have recompiled qjackctl -> still the same crackles in the same conditions.
So, I decided to start jackd manually in a console:
/usr/bin/jackd -R -p128 -dfreebob -r48000 -p256 -n4 -D -> (21,3ms latency)
Then I reproduced the same things on the full sample recorded in “Pattern” mode:
-a) Ctrl-P to maximize -> ok
-b ) Ctrl-Z to “undo” -> crackles in the playback (+ long freeze of the tracks scope)
-c) Ctrl-Y to REmaximize -> crackles in the playback (+ long freeze of the tracks scope)
-d) Ctrl-Z to “undo” -> Renoise disconnection from jackd -> message to switch into Alsa. (but jackd still running in the console…)
-e) Switching to Alsa -> ok
-f) switching back to jackd (in Renoise preferences)
-g) Selection of a part of the sample recorded in “Pattern” mode.
-h) Ctrl-P to maximize the selected part-> ok
-i) Ctrl-Z to “undo” the maximized selected part-> ok
-j) Ctrl-Y to REmaximize the selected part-> ok
-k) Ctrl-Del to delete the selected part -> ok
-l) Ctrl-Z to “undo” the deleted selected part-> ok
-m) Ctrl-A to select the full sample -> ok
-n) F10 to adjust volume at -20 db -> ok
-o) Ctrl-P to maximize the selected part-> ok
-p) Ctrl-Z to “undo” -> crackles in the playback (+ long freeze of the tracks scope)
-q) Ctrl-Y to REmaximize -> crackles in the playback (+ long freeze of the tracks scope)
-r) Ctrl-Z to “undo” -> crackles in the playback (+ long freeze of the tracks scope)
-s) Ctrl-Y to REmaximize -> crackles in the playback (+ long freeze of the tracks scope)
-t) Ctrl-Z to “undo” -> Renoise disconnection from jackd -> message to switch into Alsa. (but jackd still running in the console…)
It seems that the bug appears only when the full sample is selected.
It never happens with only a selected part of the sample.
I have tried with Fade in, Fade out, DEL, etc… on a selected part, no problem, no crackles, no jackd disconnection…
Just one time, I had a jackd crash when I was reproducing the bug:
libiec61883 warning: iec61883_cmp_create_p2p_output: Failed to set the oPCR[0] plug for node 1.
Most of the time, just Renoise was disconnected from jackd, asking for switching into Alsa Mode.
Now I finally get it. You are sometimes getting crackles in the !playback! (not recorded samples) when doing large sample operations in the sampleeditor. You could also simply load some large samples instead of recording something. I thought you mean the “pattern” recording mode, not the playback mode…
These are indeed simply playback priority problems. But thats nothing to worry about, really.
Renoise stores/creates undo operations on disk, so theres a lot of file IO happening in the scenarios you’ve mentioned above. Its up to the operating system to decide how to priorize the application threads in such scenarios.
If you really want to do such things in live scenarios, then disable undo in the sample editor (look out for a small button on bottom left in the sample editor).
Also make sure that you are using ALSA & Jack with realtime priority and set the realtime priority in Jack to the highest possible value. Renoise will always choose the highest possible priority with ALSA, which might explain why you can not replicate this so easily with ALSA…
I’m sorry but the answer does not give me satisfaction.
The bug I found is very serious for me.
It happens always on samples recorded with “Pattern” mode function in the Sample Recorder.
The “Undo”-“Redo” operations crash jackd when the full sample is selected. No problem with other operations. (the title of the topic is not adapted…)
It is happen even with little samples (4s), not only with large files.
It is never happen with a selected part of the sample (not 100% of the sample).
Jack is in Realtime priority.
I’m using Freebob with a FA-101 Edirol. (No Alsa)
The song is only 12Mbytes length.
CPU at 2.5%.
The “Undo”-“Redo” operations in the Sample Editor are fundamental in Live sessions. Like recording samples in “Pattern” mode in the Sample Recorder.
It smells like you have some problems with your HDD. You should check HDD speed. If it’s running on IRQ mode, you will get crackles in audio on heavy operations.
This command should do HDD speed testing. Check out what values this gives to you.
Maybe there is conflict with some other device in your system. Do you use jack? Does it get xruns? Check which devices share the IRQ with your sound card if any.
I have no other devices in conflict…everything disabled except the firewire audio card.
I run jack:
jackd -R -P99 -dfreebob -r48000 -p256 -n4 -D
then I reproduce the bug: it is the same…
But Renoise does not disconnect now from jackd with the full priority (P99).
I did many quick “Undo”-“Redo” after Maximize the sample (sample length 4s):
Renoise keeps in buffer the Ctrl-Z-Ctrl-Y, excutes the operations, with crackles in the playback, freezes the scopes, but do not disconnect from Jack… -> No Xruns in Jack.
The laptop’s fan is going up, it seems that the computer become more warm, Renoise CPU at 2.5%, Jack Activity at 10%.
Having gone through your texts. It sure looks like hardware/kernel problem.
2.6.24 was REALLY crappy about stuff like that on some laptop makes. If you can, you may try upgrading to latest kernel or downgrading it to 2.6.22 or something like that. It will probably solve your problem.
I tried with this kernel: 2.6.21-1-multimedia-486 #1 SMP PREEMPT RT
It comes from the 64Studio distribution.
But the problem is still present…
I have tried with Gnome, Windowmaker…always the same problem.
I can say that i never had troubles with this 64Studio distrib, tuned for maximum stability and reactivity in real time.
I never had troubles too with kernel 2.6.24-rt13…
I never had troubles with Ardour, qtracktor, RenoiseV1.9, etc…
The only problem are these recorded samples in “Pattern” mode function in Sample Recorder…Renoise2 Beta5 seems ok to work with, no other troubles with this version…Ladspa ok, midi synchro ok… but I didn’t try everything yet!
But I have reproduced the bug, sampling in Mono, and the problem seems to be resolved, I mean no crackles with Ctrl-Z/Ctrl-Y after recording with “Pattern” mode function.
I have tried with Left channel, then Right channel…no crackles…
Recording more than 12s Mono (Left or Right) in “Pattern” mode function -> OK
Recording 4s Stereo in “Pattern” mode function -> Crackles
Only stereo recording gives crackles using Undo-Redo
I was wrong.
I have tested again, with a selected STEREO part of the sample, and the crackles are still in the playback.
I have tested with a 2.6.26.6-rt11 compiled kernel, and it is the same problem → Crackles
I have removed all midi tracks of my song → still crackles
I have removed all tracks FX and send devices → still crackles
Only MONO recording in “Pattern” mode function does not give crackles using “Undo”-“Redo”.
The “Undo”-“Redo” operations are very fast, no freeze of the tracks scopes, even with large samples. Tested with 3 different kernels ->OK Tested with midi tracks and many FX ->OK
My firewire chipset is a Texas Instrument–>very stable (no shared IRQ with other devices)
My laptop is a HP dv5278 (nothing exotic)
I’ve tweaked the chunk size (the block size renoise reads sample data on undo/redo) now so that stereo samples behave as mono samples before. Hopefully this helps to avoid such problems in future on most setups…
