Hello everyone,
I have recently discovered JamRouter
https://github.com/williamweston/jamrouter
the use of which resulted in a subjective improvement in feel when playing
percussive parts on high-throughput MIDI controllers such as the QuNeo or
the Linnstrument over a2jmidid. The documented test cases in the readme seem
rather impressive as well.
It appears to me that JamRouter is highly undervalued and I would like to
ask for your opinions as a Jack users on whether it has simply been
overlooked, or whether there is a technical reason it is not receiving more
attention.
Thank you very much!
Carlo
--
View this message in context: http://jack-audio.10948.n7.nabble.com/Considering-JamRouter-a-low-jitter-MI…
Sent from the Jackit mailing list archive at Nabble.com.
Hello again,
as elaborated in my previous mail (bad news) the jackaudio.org page is
kind of in trouble.
Before these problems can be resolved, there are a few things that have
to be made clear:
1 Who has currently access to the webspace hosting jackaudio.org? I
know Paul has, I think Stéphane has and somewhere in the back of my head
a voice tells me the Filipe might have access?
2 What I know is, that whoever has access to the webspace of
jackaudio.org has not been monitoring the jack-devel list for my pull
requests. I asked Paul directly and it was done, but I think that should
not be required all the time, so here are some proposals:
2.1 Allow me to access the webspace and do the updates myself. I do not
need a real shell, some kind of file system access should be sufficient.
Pro:
* technically easy, depending on how it's done
* simplifies communication for me (no need to send pull requests to the
List)
* will result in fast updates in the future
* adds no more dependecy on GitHub services
Con:
* trust/security/legal concerns
* shifts more responsibility on me, reduces control for the webspace owner
* still fails in case I am not available
2.2 Set up continuous integration process
GitHub offers an API for interacting with external services in case a
repository is updated. This could be used to deploy changes in the
jackaudio.org repository automatically to the webspace. I would need to
look up how this could work in detail and if there are additional costs
involved. Maybe it can be done in the same way as the ardour.org
homepage is set up?
Pro:
* removes more need for manual intervention in the long run
* no need to authorize additional users to access the webspace
* keeps working even if the maintainers of the website changes
Con:
* requires an external or internal service to be authorized to access
the webspace
* requires some amount of initial setup and testing
* adds a dependecy on GitHub services
* needs documentation and maintenance cost might be to high
2.3 Remove the webspace from the chain completely.
The page will then be hosted only on GitHub pages under the
jackaudio.org domain.
Pro:
* simplifies deployment considerably
* Deployment does not depend on multiple people anymore: faster, less
work hours wasted
* Deployment of updates will be much faster
* more features of the GitHub Pages service can be used, like fetching
repository metadata, hosting of binaries, etc...
* Adding/removing maintainers is easy and handled through access to the
GitHub repository
Con:
* Makes the page dependant on GitHub, if GitHub goes down or evil, so
will the page. Still, it will be possible to host the static page on any
webspace when that happens and just change the domain record.
* Domain owner has less control over the page content.
* Needs some setup by the domain owner, I remember there have been
concerns about the records for mail adresses and the jack mailing lists.
(not entirely sure since the lists seem to sit on a subdomain, this
probably also entails security concerns...)
2.4 Migrate to something completely unrelated. aka Your suggestions?
3 hosting of binaries
This needs input by those who manage the releases of jack1 and jack2
since it is tied into the release process.
What users usually expect is the following ordered by importance
(subjective):
a) one official location for downloads
b) a predictable and consistent naming convention for files and archives
and the contents (especially for packaging)
c) predictable and consistent URLs for all versions and
variants(especially for packaging)
d) complete source tarballs
e) patchnotes
f) additional mirrors
g) checksums
h) release announcement
b, d, e, g, and h are usually provided by the ones responsible for the
releases, the rest depends on which approach was chosen in section 2.
If the webspace is used, I strongly suggest to use it also for the
binries and in case I get access I can offer to put the binaries there
for you in the right place. Otherwise there is the opportunity to create
tags on your GitHub repositories and attach the files there, which is
also a nice place to put checksums, patchnotes and other version
information and also provides automatically a source archive of the
tagged commit.
I will not add the binaries into the repository of the webpage and git
LFS does not sound especially compelling to me too since it requires,
surprise, external hosting of the files anyway and in that case, there
is almost no gain over just using the webspace or the GitHub releases
features.
Dear Paul, dear Stéphane, dear Filipe,
maybe talk to each other on the LAC about it and come to a conclusion,
because I am at a loss here and can not go any further without your
intervention. It's not the end of the world, but it kind of keeps
bugging me and the users.
best regards
Markus
after a long session of debugging i finally found out the problem of a
friend of mine, why my jack-enabled application (hooray: Pd) would crash
on their system.
to cut it short:
- Pd is including <jack/weakjack.h> to support weak linking (mainly for
OSX; but while we are there, I think we'd like to support that on all
platforms)
- Ubuntu-16.04LTS' linker seems to have "--as-needed" enabled by default.
now in general, I think that the "--as-needed" flag is nice, as it
removed plenty of cruft from all application.
unfortunately "man 1 ld" says:
--as-needed causes a DT_NEEDED tag to only be emitted for
a library that at that point in the link satisfies a non-weak
undefined symbol reference from a regular object file
now, it seems that *all* symbols defined in <jack/jack.h> are defined as
WEAK.
this means that it is impossible for libjack to acquire a DT_NEEDED tag
for any application (since there are only weak symbols in libjack for
the application to depend on), which in turn means that the linker will
happily optimize away the dependency on libjack.
the application ends up not dylinking against libjack, with all symbols
being set to NULL.
example:
<snip>
$ cat <<EOF >myjack.c
#include <jack/weakjack.h>
#include <jack/jack.h>
int main() {
jack_client_open("foobar", JackNoStartServer, 0, 0);
return 0;
}
$ gcc -o myjack myjack.c -Wl,--as-needed -ljack
$ ldd myjack | grep jack
$
</snip>
with ubuntu-16.04LTS, the commandline is just
gcc -o myjack myjack.c -ljack
this is certainly wrong.
i do want weak symbols in jack, and still be able to use jack if the
library is present and filled with symbols.
(in linux there we only have weak symbols anyhow; no "weak linking" as
in OSX where the .so file need not be present).
what's the proper way to make my application link against libjack,
without having to add special linker magic (that is not announced via
pkg-config)?
gfmrdsa
IOhannes
PS: on IRC, harry suggested that robin has some weirdo shit for this
problem...
On Sun, Jun 25, 2017 at 5:25 PM, jonetsu <jonetsu(a)teksavvy.com> wrote:
> On Sun, 25 Jun 2017 14:34:05 +0200
> Kjetil Matheussen <k.s.matheussen(a)gmail.com> wrote:
>
> > Does it mean that jackd was started automatically by the client?
> > (I guess not since "-v" was added explicitly by jonetsu.)
>
> If jackd is not running then Bitwig 2.1.1 will start it. Does this
> interfere in some way when jackd is already running ?
Not sure. There is something called "Temporary mode" which is enabled
with the option "-T". I can't find documentation about what it does, but
if you start jackd without the "-T" option, we should see a different
output in the terminal.
My _guess_ is that temporary mode automatically shuts down the
jack server when the last client exits, and that this behavior doesn't
work well with bitwig since it opens and closes several clients
during its lifetime.
(Just forwarding the reply to list now. Sorry if there's html in this mail,
it seems
like gnome terminal has started to copy fonts/colors/as well when copying
to the clipboard
(why?). Hope this doesn't manifest itself as html in the email.)
On Sun, 25 Jun 2017 17:43:33 +0200
Kjetil Matheussen <k.s.matheussen(a)gmail.com> wrote:
(I haven't subscribed to the list yet, so I'm also sending to your
address just in case)
> In my opinion, we should remove the code that automatically starts
> the jack server from a client. It's just messy.
I removed the -T switch.
The current calling is:
/usr/bin/jackd -v --sync -P80 -ndefault -dalsa -dhw:M1010LT -r44100
-p256 -n8
The behaviour without the -T switch has indeed changed although the
problem remains as described. At one point in loading projects Bitwig
will not be able to enable audio. Here's the change in behaviour.
These few lines from jackd were taken when Bitwig cannot enable audio.
[...]
Jack: JackRequest::UnRegisterPort
Jack: JackEngine::PortUnRegister ref = 2 port_index = 39
Jack: JackEngine::PortDisconnect ref = -1 src = 39 dst = 65535
Jack: JackGraphManager::DisconnectAllOutput port_index = 39
Jack: JackConnectionManager::RemoveOutputPort ref = 2 port_index = 39
Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9
Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10
Jack: JackRequest::UnRegisterPort
Jack: JackEngine::PortUnRegister ref = 2 port_index = 40
Jack: JackEngine::PortDisconnect ref = -1 src = 40 dst = 65535
Jack: JackGraphManager::DisconnectAllOutput port_index = 40
Jack: JackConnectionManager::RemoveOutputPort ref = 2 port_index = 40
Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9
Jack: JackRequest::Notification
Jack: JackDriver::ClientNotify ref = 1 driver = freewheel name =
freewheel notify = 18 Jack: JackDriver::ClientNotify ref = 1 driver =
freewheel name = freewheel notify = 18 Jack: JackDriver::ClientNotify
ref = 1 driver = freewheel name = freewheel notify = 18 Jack:
JackDriver::ClientNotify ref = 1 driver = freewheel name = freewheel
notify = 18 Jack: JackEngine::ClientNotify: no callback for
notification = 4 Jack: JackEngine::ClientNotify: no callback for
notification = 4 Jack: JackEngine::ClientNotify: no callback for
notification = 4 Jack: JackSocketServerChannel::Execute : fPollTable i
= 2 fd = 10 Jack: JackSocketServerChannel::Execute : fPollTable i = 1
fd = 9 Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd =
10 Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9
Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10 Jack:
JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9 Jack:
JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10 Jack:
JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9 Jack:
JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10 Jack:
JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9 Jack:
JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10
It loops endlessly with the last two lines during which time the
audio is not enabled in the newly loaded Bitwig project. The
loop frequency is slow, perhaps each 5 seconds.
Curiously, after closing Bitwig jackd will continue looping with
the last line below.
Jack: JackDriver::ClientNotify ref = 2 driver = sys
(cc to the jack-devel mailing list)
> jonetsu:
> > When using the latest Bitwig and loading several projects, enabling
> > audio for each one, playing it for a few seconds then loading another
> > one, playing it, so on so forth, jackd will steadily terminate, like
> > this:
> >
> > Jack: JackPosixProcessSync::TimedWait time out = 116080
> > Jack: JackPosixProcessSync::TimedWait finished delta = 3668.0
> > Jack: JackEngine::ClientExternalClose ref = 2
> > Jack: JackEngine::ClientCloseAux ref = 2
> > Jack: JackEngine::ReleaseRefnum server quit
> > Unknown error...
> > terminate called after throwing an instance of
> > 'Jack::JackTemporaryException' what():
>
>
Hi, I just took a glance at the source code of jack2,
and when you get this message:
"Jack: JackEngine::ClientExternalClose ref = 2"
...and you don't see any message about "Kill", it's the client
that has called jack_close(). So it seems like BitWig has called
jack_close() manually. However, the rest of the messages
indicates that something is wrong somewhere.
Hello everyone.
Most of you don't know, but after this year LAC Stephane gave me
permission to maintain the JACK2 project.
One thing that was highly requested by users and other developers was to
make a new release.
So I went ahead and made one.
I'm calling this one RC1 because I'm not confident enough to call it a
full new release just yet.
I need to try to get Windows and OSX builds working (hopefully doable
with mingw and osx + waf after the last wscript updates).
If someone wants to volunteer to maintain and take care of those it
would much appreciated.
The website is not updated yet.
Paul Davis will try to get an auto-update hook from github to
jackaudio.org, so we don't have to ask him to update for every little
change...
Hopefully happens this weekend.
Hi, here's a couple of jack-related releases:
1. Radium just got support for Jack Transport. Radium is a DAW.
http://users.notam02.no/~kjetism/radium/
2. Kill Jack is a program that kills Jack unconditionally. Binaries for
Linux/OSX/Windows are available in the github repo, in addition
to source code: https://github.com/kmatheussen/KillJack
About Kill Jack:
============
The Jack server sometimes crashes/freezes in ways which make users restart
the computer in order to use Jack again.
Users don't really have to restart the computer, but googling the problem
and finding a solution could take more time than restarting.
This is not very user friendly.
The problem exists on all platforms. It's not a bug in Jack per se, it's
how the program reacts when a client misbehave in certain ways.
On Tue, 6 Jun 2017 16:30:05 +0000 (UTC), RICHARD A CLARY wrote:
>WELL! Thank you, this will keep me busy for some days I am sure.
>Yes, Mint is a QUI for Ubuntu and is the most popular for those of us
>trying to loss Windows. The learning curve is very steep w/ little
>guidance however. I will pursue what you have sent and deeply
>appreciate this. I may send an email inquiry in a few days, otherwise
>will try not to bother you often. Again THANK YOU.
Hi,
I ried to reply off-list to your off-list reply, but got an error [1].
So once again, but now to the mailing list:
Hi,
you are welcome!
I guess you don't bother the jack mailing list, at least you don't
bother me. The Linux audio users mailing list just is the best place to
get the help you need.
Please, in the future reply to the mailing list.
Regards,
Ralf
[1]
From: Mail Delivery Subsystem <MAILER-DAEMON>
To: ralf.mardorf(a)alice-dsl.net
Subject: Returned mail: see transcript for details
Date: Tue, 6 Jun 2017 17:53:13 +0000
The original message was received at Tue, 6 Jun 2017 17:53:12 +0000
from x5ce0d0ad.dyn.telefonica.de [92.224.208.173]
----- The following addresses had permanent fatal errors -----
<richardclary(a)bellsouth.net>
(reason: 553 5.3.0 flpd588 DNSBL:ATTRBL 521< 91.136.10.245
>_is_blocked.For assistance forward this email to
abuse_rbl(a)abuse-att.net)