Hi all,
Today I need make a export of all tracks to another DAW(Harrision MixBus). So I have tried to use the Stem export, but when I clicked on the export button Ardour totaly freeze. Have someone same issues with stem export or it’s only problem with my system/settings? My system is AMD platform with OS Ubuntu x64 with 3.11.0 - low latency kernel and my sound card device is Phonic 24 Univsersal connected via firewire (FFADO).
What version of Jack?
Seablade
I running jack extrenaly from terminal with command /usr/bin/jackd. With parameter “–version” gives me: jackdmp 1.9.10
It is more than possible that your version of Jack is the problem. There have been numerous reports of Jack2 causing a hang on export due to a bug in freewheeling mode. I thought it had been fixed, but I am not sure I have heard of a release, so you may or may not have it. Jack1 in general is better in this regards.
SeabladePlease can we have just one version of jack… that just works and somehow ban / obliterate all the other ones… 
(Disclaimer - I’ve just installed Ubuntu on a machine and for one reason or another, once again ended up with jack2 installed by default, and, once again had to untangle the mess created when installing jack1 from source… despite following all the precautions etc, and making sure the install / build / lib locations, paths etc were correct and uninstalling the previous version or so I thought - it normally has something to do with 64Bit and multi-arch in my case, and Ubuntu and /usr/lib vs /usr/lib64 - or any combination of ‘/usr’ ‘lib’ ‘64’ ‘local’ ‘bin’ ‘include’ or symbolic links thereof …
I realize this has more to do with Ubuntu (or any non audio specific distro) and its fitness for audio use, perhaps than a problem with JACK specifically but…
Ubuntu audio devs - its great that the synaptic install of jack attempts to configure for realtime permissions, but its not great that it still fails to add the user to the audio group correctly thereby rendering all the other changes ineffective and still causes jack to fail to start.)
… The same machine is now stuck in an interminable update, reboot, configure, reboot, download, update, reboot, configure, shutdown, reboot cycle on its Windows partition… The main reason I got into linux in the first place.
Thank’s for answer Seablade, I will try another Jack version:)
linuxdsp,
I feel your pain. Ubuntu is great, but I really prefer to get my hands on things and make sure things are configured correctly. Maybe see if http://gentoostudio.org might be a good platform for you? Yes, it’s a different learning curve that requires a much more hands-on approach, but on the other hand, there’s none of that “does it for you” stuff that may or may not work.
Would have preferred to PM you this, but didn’t see how. Just wanted to try to be helpful in some way.
I don’t think linuxdsp’s pain was due to lack of being able to accomplish it himself:) It was a general frustration, and one which I can completely share I think.
Seablade Yes, add user to audio group and make little configuration in /etc/limits.conf is just piece of cake 
Ubuntu is geart distro but have another one pain in the a**…the Pulse audio…This service sometimes block Jack to aquire soundcard.
@audiodef: Thanks - as seablade implied, (and for the record… )I am capable of fixing up the problems myself… which I did, but it was just a case of frustration because it happened at all.
JACK is awesome, specifically JACK1, it (and ardour) were the main / only reasons I thought linux might be viable for pro-audio several years back.
But back then there was just JACK1 (or jack 0.99) and it worked - even if you didn’t set up the realtime stuff it started up and you got sound, albeit a bit glitchy but it was enough encouragement to think “this kind of works, lets see how to tweak it to make it work better” - same thought process as you might have with an ASIO setup on Windows etc.
The main issue with JACK now is that we have two different versions (and confusingly JACK2 is not and incremental upgrade to JACK1 but a fork) and they each have different “feature sets” (and bugs)
Add to that the fact that JACK will only start at all if realtime permissions are correctly set up and more often than not you will end up with potential new users installing the software, a process which seems to complete correctly, and then be faced with no audio, JACK failing to start and some cryptic error message. I feel this not quite how it should have ended up.
Its a huge improvement that Ardour is now packaged as a simple installable binary - wouldn’t it be great if there was a similar JACK install - or as part of the Ardour package - as is the case e.g. for Mixbus on OSX. I understand there are changes happening to make Ardour less JACK dependent but while that addresses some of the setup problems, it also sidesteps some of those issues whereas a working JACK setup is an essential part of making pro-audio possible on linux.
(and all too often that’s the first thing that goes wrong)
In my case the problems were also because I had somehow managed to get the synaptic install of JACK(2) and then even though I thought I had removed it before compiling and installing JACK1 from source, I still ended up with a libjack conflict due to a mismatch between the remnants of JACK2 and the new build of JACK1 (despite being careful to setup all the correct paths and obey the warnings while configuring the JACK build) - possibly made worse because I had a multi-arch development setup on the machine so I can do 32 and 64Bit builds.
(And even if in most cases it is a simple change to the limits file, my general point is, it shouldn’t be necessary - and on Ubuntu its
/etc/security/limits.d/audio.conf
just to add some more potential confusion)
BTW: Today I tried to use older version of Jack and now stem export working well, So it’s Jack version problem:)
@mbarhon, that’s also pert of the problem, it necessitates users having in depth and historical knowledge of what their distro does and did and how that compares to how other distros do it against what the canonical way is supposed to be. It’s a bit of a mine field.
linuxdsp: i don’t believe there has been any change in JACK’s response to “can’t get realtime scheduling” over the years. What DID change at one point several years ago was that we made realtime the default rather than a user option, because it became clear that it is basically pointless using JACK on most systems without it.
Though it does bring up a good point, is it possible to have realtime the default and automatically fall back to non-realtime if a user doesn’t have it properly set up? At least then it may start up as linuxdsp pointed out. Of course then the topic there becomes, is this actually an improvement as people will wonder why their performance is so bad…
Is it possible for a client to determine the realtime/non status of Jack?
Seablade@paul: it’s realtime being the default and the failure to start if realtime is not setup which I’m refering to - true it changed a long while back, but it periodically comes back to haunt me every time I (re)install a system, which due to the need for a stable development environment I don’t do that often (or at least not to the extent of a complete clean install requiring re-config of realtime settings etc, so normally once set up subsequent JACK updates continue to work)
however - wouldn’t it be nice if, as seablade mentioned, there was a better failover mechanism. At the moment a new user is most likely to encounter this via a failure to get any audio, failure of ardour to start properly and / or a cryptic error.
(or in the case of the OP, failure to export a session - via JACK2 - which is a bit disconcerting… especially if you have decided to trust a lot of hours to an application only to find the equivalent of not being able to get the finished project out of it)
(This is probably worth a separate discussion thread, but…)
Wouldn’t the ideal be, JACK always starts, as best it can (so you at least get some audio if possible) but that there is a means for a JACK client to get a simple / general “health report” from JACK on connection, so that it can display a helpful GUI warning / pop-up to the effect that JACK needs to be properly configured.
Config for realtime is easy if you know what is required and why (and now there is also helpful info on the jackaudio site) and is trivial for a developer, however - and this is again a slightly different topic - it would all become much easier if JACK had its own ‘official’ installer package - similar to the ardour binaries etc - which makes some guess at fixing up the realtime config, or gives the user some info about it.
(I’ve also just done a complete Windows install on the same machine, so, while I have had cause to complain about the usual grief associated with endless updates etc, it has also contrasted installing e.g. ASIO (4all) drivers which has a proper installer, pdf manual on the desktop etc etc vs getting JACK installed on linux - which seemed more painful than it should have been…)
a general installer would be a huge effort given the variation in kernel and system configuration mechanisms. this really is something that distros just ought to get right, because they are the only ones who really control how RT scheduling and memlock access can be granted.
I have also experienced Ardour (3 - 4.2) freezing on export. I’m using KXStudio.
As falkTX suggests: “If you have the ALSA-Audio bridge running, stop it before doing an Ardour3 export. It’s an issue in alsa_in/out, it breaks jack freewheel mode.”
Worked for me.