View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006096||ardour||bugs||public||2014-12-30 03:31||2020-04-19 20:17|
|Summary||0006096: Random glitches/pops/clicks in exported audio|
|Description||Apologies in advance for a very long bug report!|
This _may_ be a duplicate of bug 0005880, although some of the details
of the symptoms are different. It also may (or may not) be related to
HP Elitebook 8540w
Intel Core i7 M 620 @ 2.67 GHz
CPU frequency scaling disabled, FWIW
8 GiB RAM
Fedora 20 with some CCRMA extensions (standard kernel, which from
what I've read should be fine for editing and exporting; I use an
RT kernel on a different machine for recording)
M-Audio FastTrak Pro (USB)
JACK settings: 44100 frames/s, 256 frames/period, 3 periods/buffer
qjackctl reports latency of 17.4 ms
JACK version 126.96.36.199
Ardour 3.5.403 (from web site)
kernel version 3.15.10-201.fc20.x86_64
My procedure usually goes something like this:
- Record 10 to 60 minutes of audio on 3 or more tracks. (I'm not sure
the number of tracks is important. 1 may be enough -- my recordings
are typically 3 to 8 tracks, so that's what I've tested. The length is
probably not important either, but it should be at least a few minutes.)
- Quit Ardour. (At this point I usually transfer the project from the
recording computer to the lap-top.)
- Start Ardour and open the project.
- Make some changes... For me, this often includes
- locking the positions of all recorded regions
- copying them all (ctrl-left drag) to some later point on the
time line and then on the copies,
- changing region gains to maximize amplitudes
- possibly cutting out some slices of time by splitting regions
and shifting things around
- adding a couple buses
- adding fader automation points on tracks and buses
- possibly adding LV2 plug-ins to one or more tracks and buses
(eg, LinuxDSP BlackEQ, MBC2B on master bus).
Usually nothing too exotic. :)
(I'm not sure that any of this is relevant, but I haven't been
able to reproduce the problem if I just create one track, import
some audio, and export it without any of these things.)
- Create a range (range markers) and export it as wav or FLAC.
To that we add, for testing:
- Rename/move the exported file. (test1)
- Make no changes and export again.
- Rename/move the exported file. (test2)
- Quit Ardour.
- Restart Ardour and reload the project.
- Export and rename again. (test3)
- Rename/move the exported file.
- Export and rename again. (test4)
All the exported files should contain identical audio, and they should
be free from pops/clicks (that aren't in the source, that is ;).
On the rare occasions I've checked, the files exported from the initial
editing session (eg, test1 and test2 above) are essentially identical,
within a sample quantum or two. [Why there's even that variation is
perhaps another topic...] But after quitting and reloading the project
(perhaps a few times), each exported file contains glitches in
apparently random locations. Some are audible, some are very subtle,
largely depending on the surroundings. And after that, multiple exports
from a single session (again without making any changes) also produce
differing output files.
I'll be attaching images (Audacity screenshots) showing waveforms from a
a recent example. After I had finished the first round of editing this
project, I exported it 3 times, shown in the screenshots as test1,
test3, and test4. The files are 16-bit FLAC in this case, but the
format doesn't seem to matter. I believe test1 was from the initial
editing session -- as far as I know, there are no glitches in this file.
test3 and test4 were exported after quitting Ardour and re-starting it.
Between each of the exported files are two difference files, generated
$ sox --combine mix -v 1 test1.flac -v -1 test3.flac diff_1-3.flac
$ sox --combine mix -v 1 test1.flac -v -1 test4.flac diff_1-4.flac
Even zoomed all the way out (first image), one can visually see what
look like glitches in the diff files. One may also notice that they do
not occur in the same times from one export to the next.
If we zoom in on a glitch (second image), we can see that that it's
really a run of differing samples, many of which are zero in either
test3 or test4 but non-zero in test1. In addition, on the leading edge,
the sample values in the glitch area decay over time until reaching
zero, whereas on the trailing edge, there's a one-sample jump from zero
back to the value in test1.
After examining several of these visually, I discovered that the width
of the difference areas was consistently equal to or a few less (it can
be hard to see exactly where the values start to diverge, even when
zooming in vertically) than the frames/period setting for JACK,
initially 256. When I changed JACK to use 512, the width of the
glitches changed correspondingly.
|Additional Information||A bit of background... Since I first started experimenting with using|
Ardour for work on recordings -- starting with A2, but continuing with
A3 -- I've had fairly persistent issues with pops/clicks and dropouts at
seemingly random locations in audio being played or exported. This has
been on multiple computers, running different distros and kernels, and
different audio hardware. In some cases I could correlate glitches with
xruns reported by qjackctl, but most of the time qjackctl would appear
clean (0 xruns, at least while exporting/playing). The pops/clicks
sounded like the usual sort that can be caused by dropped frames --
sometimes very obvious, other times very subtle. On the other hand,
what I'm calling "dropouts" sounded very much like the dropouts we used
to get back in the dark ages with cassette tapes -- which is to say a
momentary volume reduction, I'm guessing perhaps a hundred milliseconds
at the most in length, varying in depth, and without a (perceptible)
click. Because dropouts and clicks sounded so different, I generally
assumed their causes were probably also different -- although both
seemed random, relatively rare (seconds or minutes apart), and neither
came with a reported error by JACK (qjackctl) or Ardour. I don't
actually remember hearing a dropout during the last few months of using
A3 (ie, the latest 2 releases). I'm not saying that they don't happen,
but I've been noticing clicks much more than dropouts these days. Which
is to say that I'm still not sure whether they are related, but I found
the leading-edge decays on these glitches to be very interesting...
Although I've long experienced issues with both exporting and playing,
I've limited this bug report to exporting, mainly because it's easier to
instrument. Also, from what I understand, exporting doesn't involve
real-time interaction with the audio hardware, and it should run fine
with stock kernel -- it runs as fast as the slowest software in the
system, and shouldn't drop frames in any case. (Please correct me if
As a work-around, I've hacked together a program on top of libsndfile
which reads and compares two audio files and writes a new file, with the
gaps in one file filled in with (hopefully valid) samples from the
other. Naturally this requires at least two exports from a project in
order to get a usable output file -- a waste of time and disc space,
especially for long recordings -- and it relies on the glitches not
being aligned in time, so it's rather specific to this application.
I've also made a couple enhancements to sndfile-cmp which have allowed
me to verify that the "repaired" output from my program, given test3 and
test4 above as inputs, effectively (within a couple sample quanta)
matches what's in test1. That's why I'm pretty sure that test1 contains
|Tags||No tags attached.|
In case it isn't clear from the description, I haven't had much success
at isolating the "trigger" for this issue. It seems to be related
(somewhat) to "complexity" -- ie, it's generally more likely as the
number of tracks, buses, plugins, automation points - or just changes -
goes up. Unfortunately I still don't have any better info about that,
but I've done a little more experimenting...
A few days after submitting this bug report I worked on a new recording
session, using the same basic workflow described above. This time when
I finished my initial edits, I exported a range twice, and got two
completely _identical_ files -- that is, cmp(1) reports no differences.
(This is what I would have expected actually, at least with dithering
turned off, but it surprised me based on what I had seen before.) I
quit Ardour and re-started it, opened the same session, and exported
twice. Again the two files were exactly identical (to each other), as
verified by cmp. They were not identical to the two files exported in
the original editing session -- but the audio samples they contained
disagreed by no more than +/- 1 LSB value, which (for now) I consider to
be "matching". I quit and re-started Ardour a third time, and again
exported twice. The new files were again identical to each other _and_
they were also identical to the two files exported in the second run of
A couple days later I opened the session again to work on a different
part of the recording. I added some new markers and ranges, a new bus,
a couple more LinuxDSP plug-ins, and a number of fader automation
points. When I was finished with that round of changes, I exported the
new stuff twice and got files that did *not* match -- the differences
were similar to those reported in the original description (ie, random
So then I went back and exported the first range (which I hadn't changed
in the second round) again, and found that it was different in many
places compared to the earlier exports by +/- 2 LSB values (larger
dithering noise? I believe it was still turned off), and more
importantly, it now also included random "glitch" differences, as
compared to the 3 earlier sets of exports.
So it seems that something I did with the later work triggered this
issue, and it now affects all exports from this project. But in other
sessions, the issue is present from the very first export, even with
In addition, the most recent pair of exports exhibited a variation in
about half the difference areas that I hadn't noticed before: Instead of
decaying to zero samples, the original signal seems to be amplified.
I'll upload another screenshot, showing one of these zoomed in. In this
case I believe the second export ("exp2") is correct, as it agreed with
a later third export (not shown) in this area.
I'm seeing the same issue with a recent nightly build (3.5-4392-gde85bfd, free version). The session I used for testing had exhibited the problem on 3.5.403 - and it has no plugins, which I thought should eliminate some variables.
I'm willing to try debugging this if I can get some tips about possible strategies or areas to look at. (I have past experience with development in C for *NIX and with embedded real-time systems, but I don't know anything of Ardour's internal architecture.)
That's very worrying. I did lots of export tests recently and was not able to reproduce. All are bit accurate (if dithering and normalization disabled) and I diff'ed them with original material (polarity invert). but I only checked wav (not flac, nor ogg). no time-offset, either.
JACK 188.8.131.52 has a few issues regarding freewheeling/export. Can you reproduce the issue with a later version of JACK, or better yet: Export using the Ardour-nightly "Dummy" backend.
What export format settings do you use?
How large is the session? (since this is a session that's always reproducible it would be great, private by email is fine too).
x42: Sorry, I did't notice that you had responded to this; I got an e-mail notification from Mantis only yesterday evening (2015-04-05 19:25:35 -0500). To answer your questions...
For me, the appearance of the issue seems to be influenced in some way by "complexity". With very simple sessions - let's say, a couple tracks with one region each, no plugins, no automation - it's relatively unlikely. As I make changes (eg, splitting regions, shifting them around, adding buses, adding fader automation), it becomes more likely but still not guaranteed. However, many/most of the sessions I do involve a similar work-flow, and over the last 6 months or so I'd say the probability that I'll see the issue some time during work on a session is about 80-90%. Sometimes it's like my initial report, where the first exports from a session are okay (more precisely, no diffs seen in back-to-back exports) but I see the issue after quitting and restarting Ardour, but other times I see it right from the first couple export attempts in my initial editing session. Sometimes there are only a couple/few glitches in (let's say) 20 minutes of audio; other (most) times there are 10's (or more) in that time span. Sometimes the difference periods I see are the decay-to-zero type I initially reported; sometimes the amplitudes diverge (almost always the errant one is lower) but don't decay to zero; occasionally there is some other waveform distortion that I don't recognize. (Only once hace I seen the _increasing_ amplitude case I reported in the first note. Also keep in mind that I don't look at every single diff in detail -- often, there are too many, and/or I don't have time, so I just spot check them.)
So I think it's possibly that one could do many tests with simple scenarios and short time spans and not see the issue. Of course it's also possible (likely) that there's something "special" about my environment or configuration that causes it, which would explain why there have been so few reports of it.
Export settings: It varies, but typically the format is either wav or FLAC. I haven't seen any difference in behavior between the two. Here are some typical ones for me:
- CD (Red Book): WAV, 44.1 kHz, 16-bit, shaped noise or no dithering
- FLAC, 44.1 KHz, 16-bit, shaped noise or no dithering
- FLAC, 44.1 KHz, 24-bit, no dithering
I almost always export a range - by right-clicking a range marker.
Since my last update I've set up a new computer with a faster CPU, more RAM, and a 9-year-old Delta 66 (PCI) sound card instead of the FastTrack Pro (USB). This one is also running Fedora with CCRMA, but it's F21, which comes with JACK 1.9.10 (so no more 184.108.40.206) and an RT-patched kernel: 3.14.29-200.rt26.1.fc21.ccrma.x86_64+rt
On this machine I see pretty much the same thing, except that decay-to-zero differences are much less common than the other types.
I also tried JACK1 on the original machine, with the same result. However I didn't report it because I built it from source and (because it was temporary) I did not follow the very clear and explicit instructions to install it on *top* of the JACK2 (package) installation - I set PATH and LD_LIBRARY_PATH on qjackctl and Ardour to point to my temporary JACK1, and from what I could see they picked up the intended binaries, but I realized the test still might not be valid.
I've tried two nightly builds during the last 3 months, with the same result, but yes I can try another, and the "Dummy" back-end - probably later this week. I'd love to test the "full" version, but so far I've only used the free ones because I can't seem to get PayPal to cooperate for a subscription. (I've donated, but I know that doesn't count.) Been meaning to try building from source, but so far haven't had time...
I came up with a way to compress the test session I mentioned in the previous note down to 230 MB, from 9 GB. Also mentioned here:
I might be able to reduce it even further (probably half or better) by removing regions that are not part of the test case and running clean-up (and verifying that the issue is still reproducible like that). Hoping to work on that later this week as well.
||Don3, please send me a link to the session (email@example.com).|
I managed to reproduce it. The problem is coming from gain-fader automation (disable those and the issue disappears).
There's no fix yet, but we're a step closer to understanding the issue.
The issue can be explained with [fader] automation. A fix for this is now in Ardour 4.0-rc3-22-g96ce9c3
I have tested 3 exports since, and they're all good. Still, there may still be more to it .
It'd be great if you could confirm that Ardour 4.0-rc4 fixes this issue.
PS.  there is more to it, declick on rec-stop for example see git 0ffde76 (but that has no effect during export or playback)
Thanks x42 !! Ah, I see - locking issues - interesting...
Okay, I will try to test as soon as I can. Seems I still cannot get past the subscription issue with PayPal (see https://community.ardour.org/node/2260, p.3 2015-01-28 13:18; I've written to them, but no response yet) to download a nightly build without the fade-outs. Or do the fade-outs not affect exporting? If they do, I'll try installing the deps and see if I can build locally. It may take me a couple days to get to it, unfortunately.
||should be fixed in 4.0-rc4. please test|
I've exported (twice each) 4 regions from 3 different sessions which previously exhibited differences/glitches, ranging in length from about 20 minutes to over an hour. (Long enough that the probability would have been high that at least a few would show up, if they were going to show up at all.) I've seen no differences in output samples so far (ignoring differences due to dither), which is a very good sign!
In one case I exited and restarted A4, and exported a third time, and still no differences. (Previously there were (rare) occastions when exporting from one Ardour instance would produce matching files, but those would not match files produced by a later instance. Usually this only happened early on, like from the first editing session, but I thought I would try it anyway.)
These sessions have between 2 and 6 recorded tracks. I'd like to try one with 8 tracks or more, but it seems I don't have any of those loaded on this machine right now, and the computer that has them is not nearby (and the network connection to it is slow) - so that will probably have to wait until I can get to it physically, which might be a few days. But the results I have now are very promising indeed.
I'm planning to try this version for "production" work in the next week, to see how that goes.
Note: I had numerous issues with JACK2 1.9.10 (current with Fedora 21), including a UI lock-up at the end of exporting, and UI unresponsiveness and a run-away jackd process when trying to restart after that. I built JACK1 0.124.1 from source, and with that I haven't seen a single issue so far. As a (minor) bonus, qjackctl and Ardour now show 100% DSP load during export, whereas JACK2 typically showed 8-10%.
Issue has been closed automatically, by Trigger Close Plugin.
Feel free to re-open with additional information if you think the issue is not resolved.
|2014-12-30 03:31||don3||New Issue|
|2014-12-30 03:31||don3||File Added: scrshot_audacity_1.png|
|2014-12-30 03:31||don3||File Added: scrshot_audacity_2.png|
|2015-01-08 05:15||don3||Note Added: 0016221|
|2015-01-08 05:18||don3||File Added: scrnshot_audacity.3.png|
|2015-01-31 06:17||don3||Note Added: 0016318|
|2015-03-22 16:45||x42||Note Added: 0016465|
|2015-04-06 00:25||x42||Relationship added||has duplicate 0006238|
|2015-04-06 18:21||don3||Note Added: 0016557|
|2015-04-06 23:18||don3||Note Edited: 0016557|
|2015-04-08 07:53||x42||Note Added: 0016573|
|2015-04-13 21:13||x42||Note Added: 0016594|
|2015-04-15 16:48||x42||Note Added: 0016599|
|2015-04-15 19:46||don3||Note Added: 0016602|
|2015-04-15 21:51||x42||Note Added: 0016603|
|2015-04-15 21:51||x42||Status||new => feedback|
|2015-04-16 18:37||x42||Relationship added||related to 0005880|
|2015-04-16 19:39||don3||Note Added: 0016610|
|2015-04-24 09:08||x42||Status||feedback => resolved|
|2015-04-24 09:08||x42||Resolution||open => fixed|
|2015-04-24 09:08||x42||Assigned To||=> x42|
|2020-04-19 20:17||system||Note Added: 0023360|
|2020-04-19 20:17||system||Status||resolved => closed|