Exported file has clicking not heard in Ardour playback


I am new to ardour and Jamin, and was trying to use the two to better master a recording my band did a while back. I loaded in the WAV file, and got Jamin to properly work as an insert on the post fade master bus, and played around to get a nice sounding mix, however, when I export the file and go to listen to it, there are a number of really loud clicks as if its clipping that I could not hear while listening to the mix through ardour and jamin.

Does anybody have any idea what could be causing this, and why it only comes up after I export the new mastered mix?

Any help would be appreciated.

I went through the audio wave form and checked for any clipping, there were only 2 spots that were marked red that I reduced gain in, but there are far more clicks within the newly exported file.

Also, if this is useful, if i re export the file that I loaded into ardour, without using the Jamin insert, the new file plays fine, so i ruled out that its something buggy in my ardour exporting - and is definitely something I’m not seeing that Jamin is doing to the tune, I just don’t get why it doesn’t show up until after I export.


hello bballplaya344
I assume that signal outgoing from Ardour’s master out is too strong after going through Jamin, so you can plugin Jamin before master fader and use plugin Fast Lookahead Limiter (as i remember right) post fader. Use Normalize if your file after loading to Ardour has red dots of clips - mark file and press “n” to normalize. Oh, and maybe use limiter from Jamin too.


bballplaya344, my guess is you’re having xruns that cause the clicks.
If you’re starting jack through qjackctl check how many xruns it reports before and after you run through the session. If it has increased you need to increase your Frames/Period in the qjackctl setup.

If the above doesn’t apply, try to run the session through a neutral scene in Jamin, i.e. don’t touch any of the Jamin settings. If that sounds OK you probably pushed something in Jamin to clipping.

how do you tell what a program’s (or soundcard’s) rt priority is, and how do you change it?

I had a similar issue with exported WAV’s having ‘robot machine gun’ sounds in them. The root cause was the RT priority that jackd was running at; it was set by default to 10; bumping this to 72 (2 less than the 74 that the ICE1712 is at) fixed the robot machine guns (what an exported XRUN, with a small frames and buffers setting, sounds like), and no more XRUNs reported by JAMin. Did find that the lower the latency setting, the slower the export through JAMin; with a 128/2 setting, it took over twice as long to export as with 256/2. (See also the ‘Got Jack?’ thread, specificially http://ardour.org/node/2421#comment-10181 and the one right above it.)

Playback through JAMin wasn’t an issue; export was, and it didn’t matter how high I set the thing (finally got a mostly clean export with 2048/4; which just caused the fewer numbers of XRUNs, when they did occur, to cause a much more noticeable repeat in the audio). The rt kernel was installed and JACK setup to be realtime (using the default priority); /etc/security/limits.conf was set up (by automation of the PlanetCCRMA jack-audio-connection-kit RPM’s); everything else was Just Right (and, again, worked fine for the most part in ‘normal’ playback/recording mode. Just the export mode had issues).

Speaking of export mode, getting ready to file a bug report about the export mode causing a JACK problem; putting together as much information as I can before filing it, and, for that matter, trying to determine whether to file it in the ardour tracker or the jack tracker.

The root problem is that exporting in ardour causes JACK to go into a weird mode, and nothing will play or record until I exit ardour and restart JACK. The message output box in qjackctl, with verbose ON, ends with the following text:

Jack: JackClient::kStopFreewheel
Jack: JackClient::SetupDriverSync driver sem in flush mode
Jack: JackExternalClient::ClientNotify ref = 4 name = jamin notify = 8
Jack: JackExternalClient::ClientNotify ref = 5 name = ardour notify = 8
Jack: JackThreadedDriver::Start
Jack: Create non RT thread
Cannot set scheduling priority for RT thread res = 22 err = No such file or directory
Cannot start thread
Jack: fPollTable i = 1 fd = 13
Jack: fPollTable i = 2 fd = 14

This occurs whether JAMin is loaded or not, and regardless of how simple or complex the session is.

Current versions: Ardour 2.8.2, Fedora version ardour-2.8.2-2.fc11.i586;
JACK version: jack-audio-connection-kit-1.9.2-2.fc11.ccrma.i586
RT kernel: kernel-rtPAE-

Probably a JACK issue, though, which is why I haven’t yet filed a full bug report, as I am still trying to figure out how to determine if it’s Ardour or JACK causing this. Maybe JACK 1.9.3 fixes this; don’t know.

I realise this is a really old thread, but thought I’d post for completeness. I recently encountered the same “robot machine gun” issue, which wouldn’t go away no matter how high the latency. Again, playback was fine, but export failed every time. Adding the boot parameter, “acpi=off”, finally solved it for me.

Sorry for the long lag in replying.

On my Fedora 11 box, I run, as root:
service rtirq status
to get the current priorities for the hardware.