First of all my great congratulations to Paul and his fellow developers: It’s a pleasure for me to work with Ardour3 using Mackie MCU Pro - it’s fantastic to connect MCU switches to Ardour’s functions and control Ardour with MCU. And in general working with Ardour3’s editor and functions is real fun.
Just when it comes to export a session to WAV file (File > Export) I fear I make a mistake in my adjustments, but I’ve no idea what mistake it could be. While export with Ardour 2.8.16 worked perfectly, export with Ardour 3 does not run so “smoothly”, the resulting WAV file contents dropouts, and Ardour’s log window says:
[ERROR]: no space in FIFO for non-process thread MIDI write
I use to have sessions with about 4 tracks and automation, from 4 to 10 minutes long. I'm using a 2,66 GHz Pentium4 with 1,5 GB memory.
I already supposed if my pc is too slow - and if I should change JACK’s adjustments of buffers and frames. Setting much larger values on both seemed to help a bit but just a bit, not completely. And on a new Dell E6430 notebook (where I tried it out for experimental reasons) with 8 GB memory I got the same problem.
I also tried other values in Ardour’s “JACK > latency” menu but without any changes in the resulting WAV file. Larger Play Buffers in Ardour’s “Edit > Preferences” window (like Paul said here: https://community.ardour.org/node/5089) also didn’t help.
Might anyone of you have an idea what my mistake is…?
Thanks a lot!
Kind of “update”: I guess my problem has something to do with CPU power - when I started qjackctl before starting Ardour 3 I learned from Ubuntu Studio’s System monitor that my CPU was 100% busy during export. (5 tracks, volume automation on 3 of them, total project length about 7 minutes.)
Results: see above.
Instead of qjackctl I have now started Patchage before starting Ardour 3 - now CPU was less busy during export: only about 83%. And there were neither dropouts nor any other sound problems in the resulting WAV file.
So I guess Patchage is a kind of emergency solution for my old Pentium 4 when it comes to export… (for normal editing work with Ardour 3 qjackctl works fine).
I struggle to understand how you can get audio drop-outs during a non-realtime export. Surely this must be a bug? Exporting a session should be nothing more (at its base level) than presenting a series of numbers to a (complex) algorithm composed of the various plugin ‘process’ functions. There are no real-time constraints, so in a properly designed system it should be expected to proceed limited by the slowest process / available CPU power. (otherwise it makes as much sense as getting a ‘drop-out’ when asking a spreadsheet to compute some accounts?!)
Yes you are right - maybe it’s a problem of what you call “a properly designed system” ;-)… I once thought of de-installing PulseAudio, but I didn’t succeed in my attempt (only very small attempts).
Kind of second update, for all those who might have a similar problem: I start to learn what my mistake was - on the “test” notebook I had simply forgotten to disable frequency scaling in BIOS…
And I guess it has been a similar problem on my Pentium 4 desktop pc: after dis(!)abling hyper threading in BIOS Ardour 3 exports in a very fine way - I’m just listening to my second test export file, without any dropouts or glitches.
Offline (non-realtime) exports should not cause drop-outs, irrespective of frequency scaling, CPU power, or ‘hyperthready-ness’. (What I actually mean is, that they don’t on any other DAW as far as I’m aware).
Do you have JAMIN connected anywhere? That’s the only other time I’ve heard of things going awry (recently) during exports, and is most definitely a bug.
linuxdsp is absolutely correct. Assuming Ardour is the only thing in the signal chain (No external processes or effects) then this is most definitely a bug and should be reported, but will need VERY detailed info on how your session was set up, etc. in order to replicate.
ive just discovered the same problem on my desktop machine, and i cant understand why. Ardour 2 exported fine, and as said its a non realtime export, so x runs shouldnt happen as it will only ever go as fast as it can within the engines limits.
ive exported 2 tracks and they both have audio drop outs and skips.
Im running 16 channel recording , source files are all 24 bit 44.1k waves, mono.
the only plugins im running is calf eq, compressors and 1 rever and 1 delay. Only plugins running on channels i need (no plugins loaded where i dont need to adjust anything)
This is on
4gb dual channel ram
64 bit athlon dual core
ati radeon 256mb hd3650 pci-e card
There is no externeal routing, everything is loaded directly onto tracks, and on the master bus i have a calf compressor.
I cant disable hyperthreading in the bios, its not an availible option.
Thank you for answering :-).
@linuxdsp: Yes I also think that it should not happen during offline exports. As for JAMin: it’s not connected.
@seablade: Ardour is the only thing in the signal chain. I’ve never written a bug report (I just have a mantis account) so I’m anxious to write a useless (incomplete) report and wreck someone’s nerves ;-), so I hesitate - but I’ll set up a completely new A3 session, see if the problem occurs again and try to sum up the session’s details.
heres a track that i exported yesterday that has the drop outs.
I have a couple of projects that didnt have this problem the only difference is they are only 3-4 tracks with a few plugins.
Hum… I must admit that I can’t hear any dropouts, I find your file sounds fine (including the time of the groove) - just a short noise far right at 3:04, but I guess it’s a tom tom… maybe I’m not experienced enough in listening to the music style…? May you describe where the dropouts are…?
Hum… did you check the MP3 version (like the one on the web) or Ardour 3’s original export file (a WAV i suppose)? I wonder if it may be a problem of external converting WAV to MP3 (I use soundconverter - it works well), so not a problem of Ardour…
Did you have the dropouts always at the same place or did their location change?
yeah i checked my recording on another computer and it seems fine, then i checked it in another player on my machine. I was using xine before, then i tried mplayer so it seems that its a playback issue with xine rather than the ecoded file.
yeah the strange noise is probably the toms, they were gated far too tight by the engineer, so theres nothing that can be done with it. the bass also drops out on one of the tracks (which i think was the bass playerhaving a dodgy lead or his output on th ebass is a bit dodgy)
check your exported file on another player, as that seems to be why i was getting drop outs.
the dropouts in my case were from the original wave file but as it turns out the wave is fine, so i guess xine isnt playing nice.
i moved to ubuntu 12.04 from 12.10 as i couldnt stand the bugs, only to find other bugs i didnt have before.
Sounds good - I myself use 12.04 LTS both as Ubuntu and Ubuntu Studio, and both works very well.
To listen to your file I used Audacious (http://audacious-media-player.org/).
By the way, in my last message I forgot the link for Soundconverter: http://soundconverter.org/. I can recommend it even for professional use; sounds very good.