Random glitches during recording when tracks are enabled or disabled

don3 · January 5, 2016, 11:57pm

Hi - I recently discovered some sessions that I had recorded in the last few months have glitches (clicks/pops) in one or more tracks near in time to the enabling or disabling of another track.
For example, I might be recording several tracks overall, but a couple of them are used only sporadically, so I enable/disable them on the fly, to avoid wasting disc space. I’ve found that, apparently, switching a track’s record button on or off can induce a glitch in one or more of the other (enabled) tracks. Neither Ardour nor qjackctl show any xruns. I’ve gone back to look at several sessions, and so far I’m only seeing this in those that were recorded using a Focusrite Saffire Pro 40 through FFADO. I haven’t found it (yet) in sessions that were recorded from a Soundcraft Si Performer over USB, but I’ve only checked a couple of those. It appears that, in order for the glitch to be audible, either or both of the track being switched on/off, and the track(s) being affected, need to be recording some sound (ie, not just silence), and of course the sound they’re recording needs to be “friendly” to audible detection of clicks. Even so, which track(s) are affected by a given transition seems to be somewhat random. Sometimes it’s very obvious in the mix, but other times I only discover it by PFL’ing each potentially affected track in turn.

The sessions I’ve looked at so far were recorded with either 4.0.0 or 4.4.0 64-bit (not sure which version was used in some cases) from ardour.org, JACK 1.9.9.5, FFADO 2.2.1 (compiled from source), on Fedora 19 with CCRMA extensions, kernel 3.10.25-200.rt23.1.fc19.ccrma.x86_64.rt.

I can open a bug report on this, but at the moment I’m not sure how reproducible it is. I wanted to ask here first to see if anyone else has seen this, and in case the devs might be aware of any changes since 4.0.0 (or in JACK or FFADO) that could relate to this. (ie, if it’s a known issue that’s already been fixed, I won’t bother.)

paul · January 6, 2016, 11:28pm

Enabling and disabling tracks would change aspects of the runtime graph, and is not intended to be free of clicks. I’ve never believed that this is a reasonable expectation (which is also why JACK 1 can click when changing connections).

bdp · January 8, 2016, 11:35am

don3, I assume you mean record enable/disable, rather than enabling or disabling the track itself?

Disabling the track is actually not possible when recording (as this would definitely cause clicks as Paul mentioned)

I also occasionally use the record enable button to start recording some tracks whilst other tracks are already recording. I’ve never noticed any issues with clicks myself. What sort of sounds are “friendly” to detection of clicks? I’m interested to try this before I mess up some great take.

don3 · January 8, 2016, 5:43pm

@paul, @bdp - So sorry for the confusion! Indeed I meant record enable/disable on a track, not track enable/disable. (Believe it or not, I really do try to proof-read my posts…)

@paul - Ah, I guess it’s been a long time since I last read about the differences between JACK1 and JACK2 (eg, https://github.com/jackaudio/jackaudio.github.com/wiki/Q_difference_jack1_jack2). I’d completely forgotten that one of those was that only JACK2 claims to support connecting/disconnecting apps without “disrupting” audio. So (OT, sorry) presumably JACK2 would be the better choice for live use, if there’s any chance that connections may change on the fly.

I’ve experienced clicks in the past with other applications when they connect or disconnect, but I don’t remember now whether that was with JACK1 or JACK2, or both. It always puzzled/annoyed me that VLC, for example, made new connections for each individual track it played, rather than just maintaining a persistent one (or maybe I just didn’t see the option to make it do that). I’ve used VLC to play some background tracks “live” several times recently on the same machine (so JACK2), and haven’t noticed any clicks. I’ll have to try some more deliberate experiments with that…

So I have a couple follow-up questions…

Unlike my VLC example, Ardour seems to make connections to its tracks which persist when disabling record (or disabling the track for that matter; just tested that) - or so it appears with qjackctl's connections window. Does your comment about changing aspects of the runtime graph apply when enabling/disabling record on tracks also? If so, could you please elaborate a little about what's changing in the graph in those cases? (Or is there something I should read?)
I know you're not necessarily up on the details of JACK2, but since I'm using that (1.9.9.5) in this case, does it seem unusual that I should get clicks in this situation?

@bdp - I don’t always get (audible) clicks when enabling/disabling record on tracks. Actually I think I’ve had them in the past but never noticed the correlation to record starts/stops on other tracks. Also, even on sessions where I’ve had them, they don’t occur consistently. For example, I noticed a click in a recent session in the audio for one side (only) of a stereo pair of microphones, when there was a record on/off transition on another track. Also I haven’t found an example yet from a recording made with the Soundcraft USB interface on the same machine. But I don’t have very many of those yet, so I’m not saying it doesn’t happen.

For me, I’d say “click-detection friendly” sound might include most moderate-level sounds from voices and (most) instruments. Examples of things that don’t work (well) include silence, and naturally “impulsy” or “clicky” kinds of things like applause and some percussion, in which clicks can more easily “hide”. Of course it depends on timing and the nature of the glitch, so these are just illustrative examples. Besides occurring randomly, glitches can be inaudible, so it’s unwise to base any conclusions on a small sample set.

paul · January 8, 2016, 6:31pm

Ardour does not change connections when enabling/disabling record, but it can change monitoring state which can cause a click in the output. There’s almost no way around this, so if you want to avoid it, you need to disable auto-input in Session > Properties > Monitoring, which will leave the monitoring state alone at all times.

don3 · January 8, 2016, 8:24pm

Okay thanks @paul - I’ll give that a try next time I do some recording, and see if I can reproduce any clicks.

If I’m reading the “Monitor Setup” section of the manual (http://manual.ardour.org/recording/monitoring/monitor-setup-in-ardour/) correctly, with tape-machine mode off, the session recording, and auto-input disabled, arming and disarming a track should switch monitoring from live to playback on that track. Also from what’s said there, I’d infer the only way to avoid changes in monitoring when arming/disarming while recording would be to have tape-machine mode off, auto-input enabled and the JACK transport stopped, in which case I think it should monitor live all the time. But I’m probably confused.

Hmm…, I don’t normally run the transport, but I do remember discovering after a recent recording session that it had been started somehow - I assumed through a stray mouse click. I suppose it’s possible that it had been rolling during one of the sessions that exhibits the clicks. Probably doubtful as an explanation for all of them, but I will keep this in mind too…