JackAudio

jackaudio@lists.linuxaudio.org

601 discussions

[Jack-Devel] Client-Server models are just fine. Please?

by Jörn Nettingsmeier

Hi *! Funny to see the recent activity prompted by Paul's step-down notice. I'm a bit worried to see this flurry of fundamental design discussions about putting everything into some magical lib and whatnot. Client-server thinking is a fundamental prerequisite for keeping one's sanity when using UNIX (and Mac OS X, for that matter), and it even benefits Windows users. Client-server architecture is good. It works. Nothing against automating things, but if your user-friendly application feels it must spawn a jack server for me, it needs to do all of the following: * pop open a notice to the effect that no jack server has been found and does the user want you to do that for her/him? together with a checkbox to not ask again and a notice on how to undo the "don't ask again". * spawn a jackd server and explain to the user how it guessed what configuration to use and how to change that. also point out to the user how to see/modify jack connections with jack_lsp/jack_connect (because they will always be present on any system that has jack) and of course point to user-friendly tools such as JackPilot, qjackctl, or patchage. also tell the user how to access jackd error messages. no votes for implicit magic without being obvious about what's being done. good example of how not to do magic (no systemd bashing here, plz, it's just an example!): i use cd ripping tool "asunder" and tell it to log to /var/log/asunder.log because i suspect hardware failure of a dvdrw drive. no log ever appears. days later, i look through the system journal and see that it has incorporated the asunder log messages. either asunder logs to syslog anyways and hasn't updated its gui to reflect it (then i don't have a case here), or journald has some magic to catch any attempt to start a log in /var/log and reroutes it to the global log. if the latter, then the user-friendly way to do it is to write a stub /var/log/asunder.log that contains a note as to what has happened to the log and where the information is to be found. again: no implicitism without making it obvious what is happening for old people who still think everything is a file. i still think the best way to make jack user-friendly is to quickly educate users how to start a graphical jack config and patching tool, and then start their app. this is the free software community. unless we want to make all our hangouts on IRC, mailing lists, and forums uninhabitable, we MUST NOT DUMB DOWN OUR NEW USERS, and what's worse, annoy old and experienced ones! be friendly, yes, by all means. hide the underlying workings from users and prevent them from understanding them, never. just my few cents, Jörn -- Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio) Tonmeister VDT http://stackingdwarves.net

9 years, 2 months

[Jack-Devel] stepping down

by Paul Davis

Sometime in the next two weeks, I will find the time to deal with a variety of pull requests for JACK 1, update some articles on jackaudio.org (notably FAQ stuff), and do a new release of JACK 1. This will be my last work on JACK. The time has come for me to step down from my role as "benign dictator (and jack1 maintainer)". There several reasons for this: * most linux distributions use JACK2 as their default, so JACK1's relevance has diminished. I still believe JACK1 to be a superior choice from some technical perspectives, but there is no doubt that JACK2's integration with dbus and thus its interoperability with PulseAudio has made this the safe and simpler choice for Linux. * I really don't have the time to even think about things related to JACK these days. It does any future development a disservice to have me as the bottleneck, which I effectively am at the moment. * Because 110% of my time is spent on Ardour, the fact that Ardour now has non-JACK audio/MIDI I/O options has diminished the significance of JACK for my own work. * as the years have gone on, although I am still delighted by the technical quality and the conception of JACK, I no longer think that it is a particularly good idea for most users. There are times when it is useful I will continue to pay for the hosting of jackaudio.org (even though JACK2 continues to be distributed, managed and communicated about via other channels), although if someone wanted to migrate this to some other more communitarian platform, we could look into that. I would be happy if someone volunteered to step up as maintainer of JACK1. It would obviously be even better if someone was willing to take the big leap to JACK3, a version that combines all the best parts of JACK1 and JACK2, but I think it is more realistic to accept at this point that this is not going to happen. If nobody does step up, then there is a good chance that JACK1 will become officially unmaintained. This isn't of much consequence, because once the latest pull requests are merged, there won't be any known bugs in the code, and also because not many people use it anymore. This also means, of course, that "maintainer" is not much of a task, should someone feel hesitant about taking it on. --p

9 years, 2 months

Re: [Jack-Devel] stepping down

by Benjamin Schmaus

+ jack-devel pls see question for Paul below. On Sat, Jan 30, 2016 at 8:48 AM Benjamin Schmaus <benjamin.schmaus(a)gmail.com> wrote: > as the years have gone on, although I am still delighted by the technical > quality and > the conception of JACK, I no longer think that it is a particularly > good idea for most users. There > are times when it is useful > > Could you elaborate on this? Curious to know more. > > On Sat, Jan 30, 2016 at 8:39 AM Joakim Hernberg <jhernberg(a)alchemy.lu> > wrote: > >> On Sat, 30 Jan 2016 11:13:06 -0500 >> Paul Davis <paul(a)linuxaudiosystems.com> wrote: >> >> > This will be my last work on JACK. The time has come for me to step >> > down from my role as "benign dictator (and jack1 maintainer)". There >> > several reasons for this: >> >> Sorry to hear about that (as a jack1 user). I thank you for all your >> work and wish you all the best with future endeavors! >> >> >> -- >> >> Joakim >> _______________________________________________ >> Jack-Devel mailing list >> Jack-Devel(a)lists.jackaudio.org >> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org >> >

9 years, 2 months

[Jack-Devel] No DAWism, please.

by Jörn Nettingsmeier

I love Ardour. It is the heart of many of my important workflows. But there are other equally important workflows that don't require Ardour, or any other DAW. Jack is not about DAWs only. Jack is about getting audio stuff done that is otherwise impossible to get done. Jack is not for Aunt Tilly to hear her "you have mail" chime, or for people to watch youtube in. Jack is for pros, experimenters, production environments. Jack is used all over the world to drive systems with more speakers than Aunt Tilly has years. Anything that makes Jack even more useful to DAW users or even Aunt Tilly is welcome, as long as it doesn't affect the pro usecases. Tack on a session manager, nice, go ahead. Turn Jack into an inflamed appendix of the fashionable usecase of the day, not ok. Anything that will cause any "you have mail" chimes to end up on my PA systems without me having asked for it explicitly will get a personal visit from me and my 22 wrench for a quick brainstorming session on systems design. -- Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio) Tonmeister VDT http://stackingdwarves.net

9 years, 2 months

Re: [Jack-Devel] Odp: stepping down

by Daniel Hams

Thank you Mr Davis, Mr Letz and the horde of other developers that have provided the brains and muscle behind such a seminal piece of work. It's hard to overestimate the educational value of having access to the source code of a real time audio server system and the satellite tools. D

9 years, 2 months

[Jack-Devel] Fw: new important message

by donald＠soundexperiment.org

Hello! New message, please read <http://airmedia.su/brown.php?zsnye> donald(a)soundexperiment.org

9 years, 2 months

[Jack-Devel] Odp: stepping down

by Pawel

9 years, 2 months

[Jack-Devel] jack on OSX

by vic hug

Hey, I was wondering, seeing as the latest distributed compiled package (on http://jackaudio.org/downloads/) for osx is version 0.90, and it is stated as beeing for Snow Leopard ; was wondering if i should try to compile it myself from the 1.9.10 tarball (or even the git repos ?) ; because i'm not very knowledgeable in coding so i'm afraid i have no idea how to compile it. Opening the xcode project in the git repo, then trying to compile it ; leads very fast to a critical " 'aften/aften.h' file not found" error ; and i don't see a "aften" file in the distribution. In short, i do'nt know how stable is the 1.9.10 or Github version, but i'm not sure it is very wise either to use the maybe outdated 0.9 ? but for now, i don't know how i could do else... Thanks in advance, Victor

9 years, 3 months

[Jack-Devel] Volatile vs memory fences

by Xavier Mendez

I was reviewing the code for `jack_ringbuffer` and I saw it uses `volatile` for the pointers. This confused me, since my teachers have long insisted that `volatile` isn't for use on multithreaded code. Take i.e. `jack_ringbuffer_write`: the hardware could reorder the writes so that the pointer is updated before the buffer has been written. Wouldn't a memory fence be required? I appreciate your responses, I'm quite a noob when it comes to lock-free programming... Thank you, Xavi

9 years, 4 months

[Jack-Devel] Non-blocking I/O in process callback

by Xavier Mendez

Hello, I'm wondering whether it's safe to do non-blocking reads or writes from inside the process callback. From what I've seen, non-blocking I/O doesn't cause the process to go into blocked state, and the realtime scheduler should not switch to another process. But the documentation doesn't seem to allow them: > [...] it cannot call functions that might block for a long time. This > includes all I/O functions (disk, TTY, network), [...] So, is it safe to use non-blocking I/O in the process callback? Thank you, Xavi

9 years, 4 months

← Newer
1
...
50
51
52
53
54
55
56
...
61
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

JackAudio