I’m experience this issue that’s driving me crazy. Though I get no xruns at all, whenever I do region editing with splits and/or resizing I experience audio clips and pops whenever the transport passes the regions bounds/splits. They are audible also in exported audio. My card is an Edirol UA-25 usb, works flawlessly in everything else, also used to work flawlessly in Ardour before I noticed this issue. It makes all of my work useless!
I’m on Ubuntu 10.04 with rt kernel jack and limits ect. all configured. Is it and Ardour bug? Can anybody help?
@vervelover: what you are reporting is a pretty serious bug. It needs to be opened on http://tracker.ardour.org/ and we’ll continue the interaction there.
Not sure if I have the same issue as you, but what I do is I make sure that the crossing between regions is as smooth as possible.
When you edit, make sure you have a crossfade between the splits. Try changing its length and position. Alternately try turning off snap and making sure the two regions are very close but do not overlap. Then make sure the waveform is cut at a zero crossing, or you fade it out. These edits are very tedious but can be made to work. I am even editing live drums this way.
You may already know this next trick, but here comes anyway; If you have multiple tracks (like on the drum kit), make sure you group them together (create an edit group and assign all the related tracks to that group. That way you only have to edit everything once.
Hope this helps.
Cheers,
Vik
@Paul: is Ardour supposed to make smooth edits “magically”?
Actually most of what you described is done automatically in Ardour IIRC.
Going off memory, all region bounds have a short (5mS) fade in and out to ensure that no pop from a non-zero crossing point happens, unless it is disabled somehow(Not sure if that one can be or not).
Obviously the default when two regions overlap is to automatically create a non-destructive crossfade between those regions. One of the cooler aspects of Ardour is the ability to edit that fade curve individually as well, really useful for putting in a replacement sample.
I think we might need Paul’s wisdom here, but it seems that most of the time when I edit my 15 drum tracks as a group, I do not get a fully smooth transition. In particular, I think it’s the crossfades to blame (I use short crossfades). With cymbal sizzle bleeding through to all the mics, it would be enough to get a single one wrong to get a click or a pop, so it is not easy, but if it could be done, I’m definitely interested. It would dramatically shorten the time I spend on drum editing. For now, I have to manually go through most of them.
There is another thing, which is most likely a bug. My machine (laptop with 2GB RAM) is also pushed fairly hard now as I’ve got a session with about two-three hours worth of drums recorded on 15 tracks, and when I started to chop those to tiny bits, things really began to slow down. I’ve even had to increase the max open files setting from 1024 and out of desperation I had to consolidate the completed songs to be able to keep going. Initially I attributed the following to my disks not being fast enough, but it even happened once when I was consolidating audio:
When there is an edit across the 15 tracks with an overlap and a short crossfade, and the first region is higher than the second region, sometimes the second region does not play – it is skipped. There is silence and the playback resumes at the next region. Like I said, I even got this kind of gap after I consolidated a song. I presume this is a bug If it’s merely a symptom of a struggling system, then it’s still tremendously annoying (you are running the risk of re-ordering regions with subsequent edits and mangle a previously working crossfade). Can anyone reproduce this behaviour?
Which of my gripes should I open a ticket in Mantis?
Cheers,
VIk
My system, for reference:
Dell Latitude D820 with 2GB of RAM, Debian unstable 64 bit, with jackd 1.9.5 and ardour 2.8.6 (same as vervelover) built by me from sources.
@efti: this is not a complete answer, but you should probably try going into Preferences and setting the size of the undo history (particularly the in-memory version) to a much smaller value. In Ardour 2.X, doing lots and lots of region slicing causes a huge amount of memory to be consumed by the undo history (this has all been fixed in 3.0).
The “second region does not play” issue has been reported before, but I (and a few others) have been unable to replicate it. If you can find a 100% repeatable recipe that causes it, there is some chance of progress on that issue.
Sorry for not replying sooner, I figured out that the pops only happened in regions that I strechted/shrinked, I did not notice that in the beginning because that particular project I’m working on has lots of shrinks/stretches on some regions. I know that a streched region might not match with the region that comes after, but what I hear sounds more like a pop/clip than simple unmatching audio waves, if you know what I mean (don’t know how to explain this better). I’ll update the bug report and do some further investigations and will let you know asap. It looks like that automated fading that seablade explained in his reply is somehow not happening with stretched regions.
@Paul – thanks for explaining. Here’s one more reason to await 3.0 (as if the MIDI stuff wasn’t enough by itself ). I didn’t touch the in-memory undo, but I did reduce the undo history for saves because I got to the point where it took several minutes to save the project after a few changes (of course my swap partition is on the same disk I’m trying to save the session to ).
I do not feel comfortable with reducing the number of undos, I think I’ll just add RAM instead, I hope this will help.
One more thing that is slow in my setup: zooming out in my long session. It sometimes takes Ardour several seconds to catch up. I presume it’s trying to read all the .peak files… Am I right? Will extra RAM help with this, or is it entirely up to disk speed?
I noted that in the comments to Vervelover’s bug ( http://tracker.ardour.org/view.php?id=3114 ) you recommended changing the options for denormal handling. I’ll try that and see if it will help. I will try to come up with some test cases or steps that work reliably.
BTW, I think that some of these topics could go into the FAQ or perhaps a “performance tuning” page. There is a lot that can be said about helping your hardware cope, from freezing tracks with lots of plugins to save CPU time, to consolidating regions to reduce disk use, etc. Not sure if I’ll have the time to write something like that in the near future (ie this month) but I’ll try.
denormal handling will have zero impact on anything you’re reported
zooming is something that will be addressed in Ardour 3.1 or 3.2. RAM will not help (much). Our current design is optimal only when your zoom level is within a fairly limited range.
Adding RAM will help a little with the in-memory undo list, but the effect with region splits is somewhat exponential
I think we have a winner with the “region does not play” bug! I created a new session, imported a stereo track, splitting it into two mono tracks (not sure if this part matters, probably not, you just need some audio to play with).
If I make two splits on one of the tracks (I made them about half a beat apart), I’ll have three regions, which I’ll call Left, Center and Right for simplicity. I set the grid to Beats/32 (again, this setting probably does not matter), and drag the Left and Right region so they just cover the Center region from both sides. Now when I go back and play this section starting somewhere in the Left region, the Center region will not play. Can you reproduce this?
I tried the denormal handling options (and indeed ended up on this thread) because I kept getting glitches where I made my edits. The DenormalsAreZero setting seemed to help – it appears that now the crossfades will no longer ‘pop’. Your post on denormals here: http://ardour.org/node/139 is really good for explaining what the issue is. Am I right to summarise that this problem occurs on some CPUs, when you got certain plugins enabled and then use crossfades? And the pop is caused by the CPU missing some cycles while handling the denormal (switching modes, etc)?
@paul: Thanks for that! This does appear to fix the problem. I compiled the source from svn and reopened my test session. The problem did not occur any more. I then created new splits as per the procedure above, and it still did not occur.
If it’s merely a symptom of a struggling system, then it’s still tremendously annoying (you are running the risk of re-ordering regions with subsequent edits and mangle a previously working crossfade). Can anyone reproduce this behaviour?