On 2016-01-30, at 10:04 AM, Paul Davis <paul(a)linuxaudiosystems.com> wrote: As a user, let me give you an entirely different viewpoint. I love Jack, and see no alternative, for this: I can have different applications send audio output to different devices. Almost all applications want to send audio to the default audio device. (Which makes sense, right?). So, with Jack, and no programs being jack-aware other than QJackCtl, I can tell all these different programs which device to use. If you can name any alternative to this, please do. I am on a Mac. Are there problems? Sure. Apple's stupidity of saying "Lets retrofit a security manager on something that was not designed for security", along with no way for users to adjust things, and "This is good enough for Apple's stuff, no user needs more than we say they can have", means that a lot of things can't make use of any audio when Jack is active. (Technically: The sandbox system, designed to put an additional layer of security beyond just file access rights or same user-ID, while having the goal of preventing a malicious program from doing something just because it has your user permissions, is adding a layer to a system that was not designed for it. So, you can, and do, get into situations where a program is denied the ability to talk to other programs by a public API because it's a network socket (seriously, a local-domain file system socket is denied by default), with no way for any user input/output tool (think human interface device for deaf, or disabled) to be registered by the users as privileged. If you think I'm being crazy, look up "Dasher", consider how useful it would be for typing on a touch-screen tablet, and then realize that iOS basically blocks any input "device" like that, and the desktop is being locked down more and more.) Sorry, end rant. --- Entertaining minecraft videos http://YouTube.com/keybounce

On 2016-01-30, at 10:58 AM, Paul Davis <paul(a)linuxaudiosystems.com> wrote: This is true. I did not realize it was just the Jack1 version being discussed when I wrote my last message; all I saw was Jack going dead. As for applications that don't offer device options, can you show me any program from Apple that does? Quicktime Player, Mail's sounds, Safari playing HTML5, at least Terminal's beeps use the error device instead of the normal output device, etc. -- all use the default audio output. So do many if not most third-party apps. Firefox, Flash player, heck Dish Anywhere's custom plugin, etc. Etc. It's easier to list what does support other audio devices. Vlc, MPlayer, OBS, the screen recorder I use, Teamspeak, ... umm ... what else?

On 01/30/2016 07:04 PM, Paul Davis wrote: Just a very quick comment on this: JACK makes Linux (and OS X) the best platform for highly innovative immersive audio stuff and massive multichannel systems, by a huge margin. It also makes it great for prototyping. It's true that the necessity of JACK for the "simple project studio" has diminished somewhat, but at the same time, linux audio has outgrown this niche. I routinely use jack-based systems for 3d audio rendering that have more than 1k jack ports in use. True, it's somewhat messy, but the corresponding amp racks, MADI and Dante links and shitloads of loudspeakers are not exactly turn-key either. I welcome the fact that a beginning ardour user does not have to master jack anymore, in the same way that my sound engineering apprentice does not have to master the rear side of the ampracks in order to get some intermission music into the theatre. But for me anything that makes linux audio interesting requires jack. That said, your motives in stepping down are perfectly understandable. But I don't agree with your assessment of JACK's importance. -- Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio) Tonmeister VDT http://stackingdwarves.net

On Sun, Jan 31, 2016 at 5:12 AM, Spencer Russell <sfr(a)media.mit.edu> wrote: I don't think Jack is the wrong solution for a DAW either. But Jack never got finished. It has a wonderful API, but it shouldn't be a struggle for a program to create a jack client if a jack server isn't running. (there were a lot of talk about this around 10 years ago, but the end result never became as good as it should I think). I think the first program trying to create a client also should start the server. Not just fork off a process, but actually run the server. And if another program wants to create a jack client, it connects to the first client process, which is the one running the server. Furthermore, GUI should be built into libjack, so that you can call jack_open_audio_driver_configuration_gui(), jack_open_audio_connection_configuration_gui(), etc. inside your client. I know there is something called libjackserver, but how many uses it? Does it do all these things? How stable is it? In my opinion, there shouldn't be any libjackserver, or jackd program, or qjackctl, only libjack. Another problem with Jack is that it never attempted to do consumer audio, and then we got pulseaudio in addition to Jack. There should only be Jack, IMO.

On Sun, 31 Jan 2016 08:44:42 -0500 Paul Davis <paul(a)linuxaudiosystems.com> wrote: I'll comment as somewhat of a heretic using reaper in wine together with wineasio/jack. I have a monolithic environment in that reaper is the daw, and my plugins are vsts hosted by reaper either in it's own process or in separate processes (for bridging/sandboxing). I also enjoy all the benefits in using jack, being able to record/output from/to pulseaudio and alsa (mostly using the alsa loopback device in combination with zita-a2jbridge as it seems to be the best solution). In addition I can use zita-n2jbridge to distribute audio over my lan, and even use zita-a2jbridge to connect additional soundcards. Mostly features I don't use very often, but very handy to just change output in reaper and hear my mix on the laptop or tv speakers (with very low latency)... When I start reaper, wineasio creates the jack client, the server autostarts (if not running) and wineasio auto connects the reaper outputs to the main soundcard outputs. When rewriting the wineasio client, it was very handy having the jack api and I suspect that it would have been a lot harder to do if I had to program using the alsa api instead. What can I say, I really love the environment and think JACK is working fantastically well. Having the plugins hosted in my daw is clearly superior (imo), but the routing flexibilty of jack and the ease of programming to the jack api makes jack a great asset in my setup. As always YMMW. -- Joakim

On Sun, 31 Jan 2016 14:37:13 +0100 Christian Schoenebeck <schoenebeck(a)crudebyte.com> wrote: I'm absolutely not a fan of zombifying clients (at least up to a certain point), but I'd also not be a fan of automagically changing latencies... IMO it far better to just the client cause xruns and to let the user deal with the problem himself. -- Joakim

On Sun, 31 Jan 2016 10:06:16 -0500 Paul Davis <paul(a)linuxaudiosystems.com> wrote: I guess it's a matter of perspective, but personally I'd also dislike latencies of a client changing automagically. I'd still prefer for the user having to manually change his configuration. -- Joakim

On Sun, Jan 31, 2016 at 2:44 PM, Paul Davis <paul(a)linuxaudiosystems.comwrote: Well, I've never used it. It doesn't feel safe. There is no obvious place to check that it does what it's supposed to. If only one program produces sound, why would you also want to start a server? 1. If it is the last client which is about to close, then the server closes as well. 2. If you close the client running the server while other clients are running as well, then the server must be transferred to another client first, in a glitch-free and spike-free manner, of course. This functionality would both feel natural (the user doesn't have to think about the server concept at all), plus that it would provide an enormous number of fun and interesting programming challenges for the implementors of that functionality. >> Furthermore, GUI should be built into libjack, so that you can call >> jack_open_audio_driver_configuration_gui(), >> jack_open_audio_connection_configuration_gui(), >> etc. inside your client. >>> I know there is something called libjackserver, but how many uses it? >> libjackserver isn't what you think it is. you're thinking of the server > API, used to start, stop and otherwise control a JACK server. it is the > basis of jack2's dbus support, so basically everything using jack2 is using > it. it is also present in jack1, and is also used internally there. > libjackserver is also used *all* the time. Oh right, guess I knew that once though. > Does it do >> all these things? How stable is it? In my opinion, there shouldn't >> be any libjackserver, or jackd program, or qjackctl, only libjack. >> this would simply lead *back* to jackd, since lots of people would want a > program they could start in order to start jack, that would run before and > after other clients. someone would write it, link it to libjack and it > would become "jackd". But my point is that you don't need the jackd program. Every client is also a potential server (although the user doesn't know this), and since libjack provides functionalities for configuring jack the same way for all clients, jackd is not needed. This way we can also create formally specified error messages for the clients. Currently, if something goes wrong, you have to dig around in the "messages" window in qjackctl, which may contain some information that could help you make things work. It's really bad actually.

On Sun, Jan 31, 2016 at 9:59 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote: I think so too, but I meant to say that, as a user, I always start jackd first since I don't want to risk a client to start jackd in a way I don't feel sure about. It would be better if this information was available in a function in libjack so that clients can show what's happening. Yes. First you imagine what would be perfect. Later we can worry about reality.

On Sun, Jan 31, 2016 at 10:24 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote: I meant server options. Driver name, realtime on/off, driver options, timeout, etc. But it's better than having different GUIs in every client for configuring jack. I think I have listed the problems. The far worst problem is that there is no proper error response when a driver doesn't start. Especially on Windows, where qjackctl is quite buggy and portaudio often refuses to start.

On Sun, Jan 31, 2016 at 11:10 PM, Paul Davis <paul(a)linuxaudiosystems.comwrote: You want to see which options jack has been started with. You want this information visible in an obvious way. It is both undocumented and flaky to have to "run ps -Af|grep jackd" or something like that to get this information. And that's what I'm suggesting. One well known point of control, provided by libjack, which every client can use, if they want. as well as the capability to start the server from scripts etc. Sure, there's nothing wrong creating a dummy-client that only runs the server, if you need that. >>>>>> what problem are you actually concerned with fixing? what users does it >>> affect? when? >>>>> I think I have listed the problems. The far worst problem is that there >> is no proper error response when a driver doesn't start. Especially on >> Windows, >> where qjackctl is quite buggy and portaudio often refuses to start. >> Qjackctl arranges to catch all output from the server, which is by far the > simplest way to present information to the user, especially in a context > where the reasons for failure can be incredibly complex. It might not work > as well on Windows as it does on *nix platforms, but I hardly think that > this would justify some new mechanism to pass failure information between > processes. This is so flaky and uncertain. Layers upon layers of software, which all may fail. The end result is that there is a higher chance for the user to not get the information he needs, plus the added complexity and frustration. libjack should take care of all this.

On Mon, Feb 1, 2016 at 10:19 AM, Patrick Shirkey <pshirkey(a)boosthardware.com Yes, that's an interesting programming challenge. It's probably very hard to make this work decently, but the thing is that if you want to run several clients at the same time, you will still have the option of starting a "main client" first, same way as you run jackd now. What I was replying to in this thread, was if you want run a DAW, you very often only want to run one client, and then you don't need to start jackd and qjackctl.

On Mon, Feb 1, 2016 at 10:38 AM, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote: But if the DAW crashes, would it be any point continuing to run the other clients? (And by "continue to run" I only mean continue to run the jack callback, the other clients don't have to crash.)

On Mon, Feb 1, 2016 at 10:58 AM, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote: Well, in that situation, it would probably make sense to start a main client first.

On Mon, Feb 1, 2016 at 10:46 AM, Stéphane Letz <letz(a)grame.fr> wrote: Both you and Paul have done amazing work which I'm very grateful for. But I'm not suggesting a redesign here, just a fairly minor change. Would it be that much work to put jackd into libjack? That's the first step. I also suggest creating a formally defined api for error messages so that the clients can show what's going wrong if a driver fails. I also suggest to rewrite some parts of qjackctl and add it to the jack packages as external executables that can be launched by libjack. This modified version of qjackctl will now not be linked to libjack, but instead communicate with libjack through sockets, just plainly doing GUI operation for whoever client that needs it. This might be a larger job though, but probably doable over a couple of weekends or so.

On Sun, Jan 31, 2016 at 5:10 PM, Kjetil Matheussen <k.s.matheussen(a)gmail.com i haven't seen a single bug report regarding such behaviour. what isn't reported can't get fixed. the only times i have to SIGKILL jackd is when i'm doing code development and i do something deeply screwy. there will ALWAYS be a server in a system like JACK. if there is code that ends up requiring SIGKILL, then the same code can end up executing inside whatever process is running that code.

On Sun, Jan 31, 2016 at 4:22 PM, Kjetil Matheussen <k.s.matheussen(a)gmail.com > > > On Sun, Jan 31, 2016 at 9:59 PM, Paul Davis <paul(a)linuxaudiosystems.com> > >> >> and no effective difference for users over and above the current >> auto-start scenario. >> >> Another problem with the current auto-start system is that when the > client exits, a ghostly > jackd process still continue to live in the system. (Why can't I play any > sound on my linux > machine anymore?) > Not true if the server was started with the -T flag, which causes it to exit with the last client. This is a user choice. Jack2's support for this flag was broken for years.

Hi Paul, hi others, Having been somewhat absent for a long time, I still passively always watched the progress the FOSS audio world made. It is my plan to be more active in the Linux pro audio world (when it comes to development) in the future. But that is another story. At this point, I'd rather simply like to say "Thank you!" to you, Paul, for starting the JACK and Ardour universe. Thanks for all your enduring dedication. But also thanks to Stéphane, to falkTX, to Rui,... to all of you, who put so much effort into the wonderful world of Linux Audio! Paul Davis &lt;paul(a)linuxaudiosystems.com&gt; [30.01.2016 13:04]: &lt;CAFa_cKnTwUpK6uba+fxYijW31O1xciO3hRd_TaWwnWDPaxBsuw(a)mail.gmail.com&gt; Your analysis of the current situation is really interesting for me. Actually, I was thinking a lot about the topic of session management the last days, and I'd like to ask some questions about it: Curiously, I had a hard time to find out something about the history of session management on the internet. For example: What where the reasons that, once LASH silently vanished, LASH was followed by (at least --- not counting "non" here) successors: JACK session and LADISH? Is there a fundamental difference between the two? But that is not my main question. It comes here: Suppose, A) a JACK session manager used chunks instead of the "save your state %here" approach, ( My guess this approached was chosen instead of chunks: 1) It requires less changes for a client to implement session management support 2) Cross-process chunks might have been considered a challange ) B) This sesssion management is integrated into a DAW, et's say e.g. Ardour. Hence, I could start some JACK clients, set up my connections, do some config in my clients, hit save in Ardour, and save the whole stuff to *one* file. When I reload it, everything is there as I left it. Even if one of the clients was, let's say LMMS or Qtractor, it would be still up to the user to decide whether they want to use Ardour, Qtractor or LMMS as a JACK session client or as the session master. So this wouldn't mean a privilege for any DAW setlled by the developers. ---> Would you consider the JACK approach then to be more valuable for the end user? ---> Do you think this is something to strive for? Your opinions on these thoughts are highly appreciated :). Kind regards, micu -- OpenPGP / GnuPG: 0xE4CB4E80 Fingerprint: 1A15 A480 1F8B 07F6 9D12 3426 CEFE 7455 E4CB 4E80 <<</>> http://www.micuintus.de