I’ve read the Jack FAQ and I understand what it tells me. My problem is that Jack doesn’t behave consistent with what I read. I’ve gone into the Jack 2 setup many times. I’ve changed the Interface and the Input Device. No matter what I set them to, Jack 2 is dead set on one particular configuration. At some point, that configuration will change and I don’t know why. Right now, for example, it is interested in my M-Audio Audiophile and shows the 12 capture ports for that device. If I go into the Setup and set the Interface and/or the Input device to be my Scarlett 2i2 (hw:USB), it changes nothing. Apps that use Jack 2 are still outputting to the 2496. Yesterday, Jack 2 only showed 2 capture ports. I’m not sure what device it thought it was (either the 2i2 or the built-in sound device of my mother board), but at that time, it seemed nothing I could do to persuade jack to use the 2496. It’s all very odd. I’m not saying that there’s a bug. I am sure there’s something I’m not doing correctly. But reading the FAQ and other documentation I can find isn’t revealing it to me.
Hmm…
I don’t suppose you could try Jack1? I have my suspicions that you are running into an issue with jackdbus which is a feature in Jack2 that caused me no end of headaches, part of the reason I use Jack1 strictly now personally.
Seablade
@mbratch At the risk of annoying you with a redundant question, are you sure you don’t have a “rogue” JACK process running there? (eg, after stopping JACK in qjackctl, pgrep jackd should output nothing.) I’ve seen symptoms very much like what you describe - settings not sticking, wrong numbers of ins and outs showing up, etc - after 2 or 3 frustrating re-tries, I discovered a jackd that I had “accidentally” started in an earlier Ardour session, still running.
If JACK is configured to use e.g. hw:0,0 it will be entirely random, each boot. Its an “interesting” (for want of a better word) feature of linux, that the soundcards are enumerated in essentially random order by the kernel, at boot - mostly dependent on which becomes available / visible first - therefore card 0, will sometimes be the onboard sound interface, sometimes not.
@don3 haha no worries, it’s not annoying. I appreciate your pressing of the question. I didn’t find any rogue jack processes. But I did notice something odd.
Starting from a “clean” setup (no jack or Ardour running), if I run Ardour, then it will run jackd automatically (expected when I tell it to use jack for audio). When I exit Ardour, jackd continues running. Expected. Then I run qjackctl, which will start a process called jackdbus. Now jackdbus and jackd are both running. I haven’t figured out the difference between these, but let’s call that expected as well. However, if I click the STOP button in qjackctl, both jackd and jackdbus continue to run without interruption (at least they show no signs of being issues a HUP signal in Linux). Clicking STOP and START in qjackctl doesn’t seem to have any affect, which doesn’t seem expected. But if STOP/START don’t do anything, that would explain why my Setup changes in qjackctl haven’t been having any affect while running the app. (NOTE: I have, though, determined that if I change settings in Setup and restart everything manually, including jack, then the settings seem to stick.)
Perhaps, then, the issue I’m having with configuring jack is that qjackctl isn’t handing the jackd stop/start.
Independent of that, I think I’ve achieved a controllable scenario by relying on the zita_a2j and zita_j2a tools that @paul mentioned. So I can run Ardour (or Hydrogen or whatever), look at what Jack thinks it has for HW, and run a script that calls the appropriate zita commands to add whatever I need. That seems to be consistently working for me without having to manually stop/start jack outside of qjackctl.
Perhaps, then, the issue I'm having with configuring jack is that qjackctl isn't handing the jackd stop/start.
Yep this is a symptom, as I mentioned, of jackdbus in my experience. A common headache until I switched to Jack1.
Seablade@mbratch: jackdbus is jackd with dbus support enabled, so you were in effect running two separate instances of jackd.
@linuxdsp: The order in which sound cards are found by the kernel does have an unpredictable element if you’re plugging and unplugging usb or firewire devices, but I’ve always found the order to be consistent when using multiple pci interfaces (although in the past I’ve seen it change between kernel versions - that hasn’t happened for a few years now).
Yep this is a symptom, as I mentioned, of jackdbus in my experience. A common headache until I switched to Jack1.jackdbus is more trouble than it's worth IME. I compile jack2 without dbus support and with the default "classic" start/stop behaviour, which gives the same start/stop behaviour as jack1.
@linuxdsp: The order in which sound cards are found by the kernel does have an unpredictable element if you're plugging and unplugging usb or firewire devices, but I've always found the order to be consistent when using multiple pci interfaces (although in the past I've seen it change between kernel versions - that hasn't happened for a few years now).
I see it here on a laptop until I locked it down through ALSA, this is just on the internal options (HDMI/Internal Sound).
jackdbus is more trouble than it's worth IME. I compile jack2 without dbus support and with the default "classic" start/stop behaviour, which gives the same start/stop behaviour as jack1.
My experience has been similar, though there are some good things about the concept, just doesn’t like me.
Seablade@seablade: yes - you can lock down the interface by specifying it via its name instead of its hw enumeration - which is what I normally do when starting jack from the command line (I don’t use GUI frontends for JACK, so I’m not sure what the current state of things like qjackctl etc is anymore - I just start JACK at bootup via a script, since most of what I do on linux requires JACK to be running anyway). I think the problem we have here is one which sadly crops up far too often in relation to audio on linux - the components of the system can all be made to work - eventually - and fundamentally its not too complicated - but the documentation is a bit ragged (or relates to completely different / obsolete versions) and the various tweaks and tricks required are not exactly ‘discoverable’.
I’m doing more work on Mac / WIndows at the moment - and its a stark contrast how much stuff really does ‘just work’ straight out of the box - by contrast, the last time I installed linux on real hardware it took a week to get it working “properly” (and - being Ubuntu, it still tries to burn out the backlight on my screen every time it boots / shuts down / hibernates, activates the “screen saver” or any one of numerous different scenarios etc - this has been a problem for only about the last five years or more, on every machine I’ve used - though, to be fair you can at least set the brightness from the keyboard now, it just reverts to 2000% maximum full power on the next boot - persistent settings? that would be a smart “innovation” - maybe one day fundamental stuff like this will get fixed… But I digress 
)
comparisons of generic PC hardware running any OS to Apple hardware running OS X just don’t really make any sense when they enter this sort of domain. If you want “everything just works out of the box”, you have to have the right hardware and the right OS - just one of them won’t do. And even then, you will still find little odds and ends that don’t work, whose consequences may vary depending on what you use it for.
OS X gets to run on specified hardware, designed by and manufactured for Apple. Try running OS X on a hackintosh and you’ll start to get more of a sense of how limited its support for hardware really is. Try booting it on an AMD processor and you’ll tear your hair out (you need to hexedit the darwin kernel to even get it to boot!)
The last two Linux machines I’ve had have been self-builds, running Fedora initially and now Debian Jessie. It is amazing to me how well they work, arguably better than my 3 OS X machines. Is this because Linux is great? Not really … though it is pretty astounding how good it has become … I just got lucky with the hardware I’m running.
@seablade: yes - you can lock down the interface by specifying it via its name instead of its hw enumeration - which is what I normally do when starting jack from the command line (I don't use GUI frontends for JACK, so I'm not sure what the current state of things like qjackctl etc is anymore - I just start JACK at bootup via a script, since most of what I do on linux requires JACK to be running anyway). I think the problem we have here is one which sadly crops up far too often in relation to audio on linux - the components of the system can all be made to work - eventually - and fundamentally its not too complicated - but the documentation is a bit ragged (or relates to completely different / obsolete versions) and the various tweaks and tricks required are not exactly 'discoverable'.
No argument there.
I'm doing more work on Mac / WIndows at the moment - and its a stark contrast how much stuff really does 'just work' straight out of the box - by contrast, the last time I installed linux on real hardware it took a week to get it working "properly" (and - being Ubuntu, it still tries to burn out the backlight on my screen every time it boots / shuts down / hibernates, activates the "screen saver" or any one of numerous different scenarios etc - this has been a problem for only about the last five years or more, on every machine I've used - though, to be fair you can at least set the brightness from the keyboard now, it just reverts to 2000% maximum full power on the next boot - persistent settings? that would be a smart "innovation" - maybe one day fundamental stuff like this will get fixed... But I digress :) )
Argument here though, or rather countpoint:)
I just started using bog standard Ubuntu again for the first time in quite a while on my laptop. Given that it is a Chromebook Pixel 2, there are some things I certainly had to tweak to get working, but standard support is coming I will say. That being said I am moving from Mac to Linux for the exact reasons you cited, as to be honest Ubuntu really did ‘just work’ with the exception of adding in KxStudio repos and installing Jack1 for my needs.(Ignoring the aforementioned hardware support being developed for a computer that came out what, a month or two ago?)
So it can vary as Paul mentioned, sometimes your hardware and software can ‘just work’, but the catch is that ‘sometimes’
SeabladeSo now I know jackd and jackdbus are essentially the same, I think the start/stop of Jack2 is still broken. Neither of them are “stopped” when stop is clicked.
Overall, though, I’m very happy with my choice of Ubuntu Studio for my DAW setup. I’m specifically liking the way I can hook programs together like Hydrogen and Ardour through Jack. I’ve been a very long time Linux user as well as Windows. I use each for different reasons (I do some software work for which tools only exist on Windows, for example). Now that I have learned the idiosyncrasies of Jack2 from you all, I believe I know how to control it for my needs. This has been a very fruitful discussion for me.
Glad to hear it is working for you! I lost my patience with jackdbus long ago so good luck to you:)
SeabladeGood to know its working -
@paul: I completely appreciate that its an unfair comparison, OS X on very specific hardware vs generic PC hardware combinations (in part why I also mentioned that I’m using Windows too, which is more generic, and on various combinations of generic hardware, setup has been comparatively trouble free).
That said, I don’t think there is anything wrong with citing OS X as the kind of ‘gold standard’ that we (linux audio developers) should aim for - I get the idea that building a machine specifically for audio is a specialised task and might / does therefore require some extra skill - but its certainly possible that the linux (audio) experience could be more friendly. The same issues cropping up again and again in different guises - on this and other forums is evidence of that. Which is why I mention it (again…) in this thread.
@seablade: I’ve installed various distributions though mainly Ubuntus on many different laptop / notebook machines over the past five years or more - perhaps I’ve just been unlucky with every choice of hardware, but in evey case there are some basic things which just don’t work properly (normally video driver issues - I have never had complete success with any open source video drivers - and especially this wretched screen backlight brightness problem. Googling the various linux forums, suggests this has been a frustration for many users, going back to Ubuntu 9 or earlier). This is not cutting edge hardware (I like to test my software on ‘workhorse’ machines, rather than the PC equivalent of a supercar) - but its not obsolete (yet) either…
So now I know jackd and jackdbus are essentially the same, I think the start/stop of Jack2 is still broken.Jack2 start/stop behaviour is the same as with Jack1 if compiled with the default options. It's only when the dbus support option is enabled at compile time that the behaviour you're experiencing occurs. That's an issue with your distro's packaging, not Jack2 itself.
@linuxdsp: if you read audio-related forums, you will find plenty of accounts of windows behaving oddly on random hardware. Regarding building an audio machine - the task is made even harder by the fact that motherboard manufacturers feel free to vary specifications at will, something that does not happen to Apple.
In general, if you comparing platforms where the manufacturer of components provides vendor support for their components and other platforms where the manufacturers provide nothing, it is pretty obvious who/what is going to come out ahead in the “it just works” category. If that is the expected experience on Linux then you’re very often going to be left down. I don’t see how this can placed at the feet of Linux, however. There is almost no hardware where, when the manufacturer has provided full information on how to implement drivers for it, someone in the Linux community does not step up and provide even better functioning support than exists on Windows or OS X (a recent example for me has been my logitech “unity” wireless keyboard and mouse, which has much better support on Linux than it does on OS X even with Logitech’s own software there). Video drivers have and always will be a problem … even on Windows. I remember dozens of stories from software developers who have been unable to get things to work as intended or as documented on Windows because of “bug NNNN in version X.Y of DirectX when used with these cards”, bugs that never get solved - you’re just supposed to move along or get a different video card.
In short, I think that anecdotal lists and comparisons really serve no-one. If people are not clear that hardware which requires vendor support on Windows or OS X has a good chance of not working well or at all on Linux, then they need to be properly informed about that. If people think that random hardware will work as predictably or as well as an Apple system, they need to be corrected in their impressions. But beyond that, swapping tales about “it broke on every version I ever tried it on” seems essentially useless to me - people’s experiences will vary so widely that these accounts are almost information-free.
Yep I haven’t messed with the backlight much on this machine yet, I know it exists, but I haven’t ever bothered to find it:)
That being said, I think to Paul’s point a true comparison might be comparing say the Dell XPS Developer edition laptop with Ubuntu from the factory, to OS X. You are likely still to come up slightly short, but not very much, but at least that Manufacturer is making an effort on certain laptops to ensure Linux compatibility.
Seablade
PS I Have yet to have a fresh re-install of Windows ‘just work’ for the record:) Mostly driver issues.
@seablade: This is way off topic, but just to clarify I didn’t mean e.g. a backlight for the keyboard or any such - I meant the actual screen brightness control e.g. the light in the LCD panel - maybe all the Ubuntu devs wear Ray-Bans or whatever while they’re programming…
- but my screen insists on going to maximum brightness, at every boot (and at several different points in the boot / shutdown process) regardless of any previous adjustments - and especially when entering / exiting power saving modes (ironically). I’m not alone is suffering this problem - on many different machines, since about Ubuntu 9 and I just find it odd / frustrating that it doesn’t appear any attempt has been made to address the issue - for any hardware - over the course of so many years…
Yep I followed what you were saying, just meant that I hadn’t really messed with it on the machine I am on now, and that it hadn’t bothered me much yet, certainly not enough for me to invest time messing with it:)
Seablade