I’ve had fairly consistent problems with random glitches/dropouts in audio - without any xruns being reported via qjackctl - while recording, playing, and exporting from Ardour 2 and 3, using multiple computers, Linux distributions (all but one or two were Fedora + CCRMA), JACK versions (1 and 2), and audio interfaces, over several years. As (almost) no one else is reporting these issues from what I can see, I’ve been assuming the cause(s) are my own doing – in some cases I’ve suspected certain SW and/or HW details, such as not using an “RT” kernel, or using a PCI audio interface (Delta 66) with a PCI network card. I currently have issues with two systems:
A laptop running Fedora 20, used with an M-Audio FastTrack Pro (USB) which often produces random glitches when exporting and playing. (I don't typically use it for recording.) I don't usually run an RT kernel on this machine - but as I understand it, that shouldn't matter for exporting, as Ardour, JACK, and all of the software components should just run as fast as they can - as fast as the slowest component, I assume. I've opened bug report 0006096 about this particular case.
A desktop running Fedora 19 with CCRMA RT kernel (3.10.25-200.rt23.1.fc19.ccrma.x86_64.rt), most often used for recording. Originally it had a Delta 66 audio interface, but now I'm using a Focusrite Saffire Pro40 with a PCI Firewire card. Unfortunately I have to use a PCI network card in this machine because its on-board NIC is dead, and although it's only a few years old, it doesn't have PCIe slots. I suspect the (or an) issue here might be related to PCI bus contention or similar, which I had pretty much proven with the Delta 66, where the glitch rate tracked very well with network traffic. With the Pro40, glitches seem to occur much less often, but a large data transfer over the network can lock up the machine if JACK's running. Because of all this, I haven't opened a bug report for it, but...
My main question here is: Should one expect any dropped-audio condition in JACK or Ardour, either in the normal real-time mode or freewheeling, to be detected and reported?
Back when I started experimenting with Ardour, I had assumed that the presence or absence of xruns would reliably indicate whether the system was dropping frames or not, but that hasn’t been my experience – I often get random glitches, most of which look like the result of dropped frames, without any xruns or errors reported by Ardour. Anyone else out there seeing this?
Which version are you using? Many noise problems with region crossfades in playback and exporting have been recently corrected. You should try a nightly build of ardour http://nightly.ardour.org/ and see if the problem persists.
My main question here is: Should one expect any dropped-audio condition in JACK or Ardour, either in the normal real-time mode or freewheeling, to be detected and reported?
No DAW should ever drop samples or create xruns when exporting / rendering audio offline (for Ardour / JACK this would be ‘freewheeling’ )
tartina: Sorry, I know I didn’t include many details with the two examples I gave – I didn’t want to get too far off track from my main question. I’ve experienced glitch/dropout-like symptoms with many versions - I’d guess since about 2006 when I started playing with Ardour 2. (I’m not saying all those symptoms had the same root cause; I hadn’t done much investigating until the last year or so.) When I read the bug report about the clicks at crossfade boundaries (0005953, right?) I was hopeful at first, but IIUC those always occurred at the same locations, whereas mine seem to be very random and not repeatable. There have been a couple others that sounded similar at first – for example, 0005880, but in this one the locations of the glitches are repeatable in exports from the same session, whereas in my case they are not. (Well, in fact I might also have this issue. I look for glitches by “diffing” export files, a more accurate and much less tedious method than trying to find them visually in Audacity or even by listening. Occasionally I get (essentially) identical exports, but it may be that in some cases the output files I’m comparing have the same glitches.)
Anyway, to answer your question, both the examples I gave are with Ardour 3.5.403 and JACK 1.9.9.5. I did try a nightly build - 3.5-4392-gde85bfd (free version) - on the laptop, and I still got the random glitches on export. The particular session I used to test with that version had no plugins, which I thought would eliminate some variables that are out of Ardour’s control. I didn’t try recording with that version because it didn’t seem stable enough to risk it. I’ve also tried JACK 0.124.1 compiled from Git on the laptop, with no change in the result.
linuxdsp: Thanks for confirming… this was my assumption too, from everything I had read. That’s why I focused on exporting in the one bug report I opened – I figured that even if I have some glaringly obvious issues with my hardware or configurations that would account for unreliable real-time operation, it shouldn’t affect exporting.
@don3 Have you confirmed this happens without any plugins on a session at all? My first thought is that while yes dropouts should be detected, an xrun in truth is only when processing does not complete in the time allocated to it, which in freewheeling everything is given as long as it needs to complete.
This makes me wonder if you might have a plugin misbehaving or similar in freewheeling mode. If you can confirm that this happens with only Ardour, no plugins, etc. that would be a great step. If it only happens with plugins, the next step is to add and automate plugins, one at a time, until you can repeat this and discover which plugins cause this, or even a chain of plugins.
@seablade Yes, it happens without plugins as well. Until recently I didn’t have any examples of that, as most of my projects have a plugins (most often LinuxDSP MBC2B, and/or Black EQ) – but as of a few weeks ago I do have one, which I mentioned in a later note on my bug report. I could possibly provide it for analysis, but it has a couple hours of recorded audio, so it isn’t small.
I’ve tried a few times to reproduce this with a brand new session, so that I could write a simple procedure for a bug report, but I’ve yet to have any success. It seems to take some “complexity” to trigger it, such as moving/copying/splitting regions, splicing them together, adding fader automation, and/or adding plugins. No one of these seems to do it, at least when I’ve tried to do a semi-controlled experiment. Sometimes the first few exports from a newly edited project looks “clean” (ie, exporting again produces a matching (ignoring dither) output file, or occasionally, a truly identical file), but then exiting and restarting Ardour starts producing (new) random glitches. Also most of my projects tend to have between 3 and 8 tracks, and 2 or 3 buses - I’m not sure if those are factors either.
If you have a clean session that causes it, it may be that they do need to get that session from you, but I would have to let paul chime in on that one.
@seablade Looks as though the session without plugins is about 9 GB total. Removing the export files should reduce that some, but I’ll see if I can reproduce the earlier results if I replace the interchange audio files with something generated (a constant sine wave or pink noise, say), so that I don’t have to upload them – ie, I could just give a script to create them. (Just now I tried to generate a dummy file using sox’s “synth” effect, but for some reason the output file doesn’t contain the number of samples I gave it. Arrgh.)
@seablade Sorry for the delay coming back to this. Among other things, I’ve been busy setting up a new machine – another desktop, with a recent i7 CPU, plenty of RAM, and the M-Audio Delta 66 (PCI) sound card that was formerly in the other desktop. Like the other two, it’s running Fedora (F21 on this one) + CCRMA with an “RT” kernel. In my limited testing so far (mostly with 3.5.403), it’s been solid – not a single xrun reported by qjackctl so far (while playing or exporting I mean) – but I still do see random glitches in exported audio, similar to the other machines. I say “similar” because (a) so far they seem to occur less often than with my laptop, and (b) most of the ones I’ve looked at don’t decay to zeros like the ones in the first screenshot in my bug report, but instead have a period of reduced amplitude or some other weird-looking distortion in the waveform.
I reproduced the issue with the no-plugins project I mentioned earlier, using nightly build 3.5-4543-gbf1d127 on this new machine. I can’t say whether there were any xruns, because I seem to be unable to get these new Ardour builds to connect to an existing JACK process, and if I let Ardour start JACK for me, qjackctl doesn’t see it. I didn’t see anything bad in Ardour’s log, or on the xterm I launched it from.
So, yes I’d be willing to share this project, if anyone wants to see if they can reproduce this. I have a tar archive that’s about 230 MB, as compared to the original 9 GB, with exports and other transient files removed, and interchange audio files re-coded in Ogg/Vorbis (and a little script to convert back to wavs). Still not small, but hopefully small enough that I could post it somewhere and give instructions for how to unload it, and a procedure I use for exporting and detecting glitches. Looks as though I have enough space for this on copy.com and Google Drive right now, if either of those work for anyone.
This is a long shot but are both machines plugged into the mains using a surge protected mains adapter? Are the machines placed on a statically charged surface such as carpet?
Have you tried removing the old PCI network card and testing to see if it’s that causing issue?
Also without ruling out faulty hardware on both machines you will want to ensure that you are running rtirq on both.
The machine connected to the usb sound card should ideally be using jack configured to use 3 Periods/Buffer. According to the jack man page.
@TW Interesting idea about mains surge protection. The computer that’s mainly used for recording is plugged into a surge-protecting power strip - not sure of its status though - I should check that… It’s physically near a mixer that’s the source for a lot of the recordings, and on the same power circuit (but the computer has its own power strip); FWIW the sound coming from the mixer has been clean. The computer and audio interface are located in a wood cabinet. I suppose the finish on the wood could potentially present electrostatic issues, although the electronics are all inside metal cases that should be properly grounded/earthed, in common with the mixer, and all the cables in and out are shielded.
I remember testing the Delta 66 without the NIC in this computer at some point (and that cleaned things up dramatically), but I’m not sure I ever came back to test the FW interface without it. So good question. I’d really like to replace this machine, but haven’t been able to yet for budgetary reasons.
About rtirq, it’s installed on all the machines I use. It think it may come with one of the base CCRMA packages, or at least it used to, but I can’t say at the moment whether it’s getting run or not – I don’t see it mentioned in a quick check of system logs. This is another thing that I’ve checked in the past - with the D66 I either found that it was getting run somehow (init script or similar), or that running it manually didn’t help - but I need to revisit this too.
Thanks for the tip about 3 periods/buffer for USB. I’ll give that a try next time I use it. Right now it’s set for 4.
I think paul and x42 are making some progress on bug 0006096, now that they’ve been able to reproduce the export issue I have. It will be interesting to see if/how that affects recording and/or playing. If it’s indeed related to gain automation, I kind of doubt it would affect recording at all.
I’ve experienced glitch/dropout-like symptoms with many versions - I’d guess since about 2006 when I started playing with Ardour 2. (I’m not saying all those symptoms had the same root cause; I hadn’t done much investigating until the last year or so.) When I read the bug report about the clicks at crossfade boundaries (0005953, right?) I was hopeful at first, but IIUC those always occurred at the same locations, whereas mine seem to be very random and not repeatable. There have been a couple others that sounded similar at first – for example, 0005880, but in this one the locations of the glitches are repeatable in exports from the same session, whereas in my case they are not. (Well, in fact I might also have this issue. I look for glitches by “diffing” export files, a more accurate and much less tedious method than trying to find them visually in Audacity or even by listening. Occasionally I get (essentially) identical exports, but it may be that in some cases the output files I’m comparing have the same glitches.)