I need to combine two HDSPe MADI FX cards to one virtual device. I have a
working driver, which is alsa-compatible. I can select each single card in
any alsa-compatible application and all channels work flawless.
For combining the MADI FX cards to one virtual device, I created an
.asoundrc with 194 inputs for each card. When I start that virtual device
jackd -R -d alsa -C madifx_record_all -P madifx_playback_all
I get this error:
> creating alsa driver ...
> jackd: pcm_multi.c:1060: snd_pcm_multi_open: Assertion
However, it works when I reduce the amount from 194 to 64 channels per
card. I tried to use 128 channels per card, but that fails the same way.
See my alsa-info attached, which also includes the .asoundrc content.
I also found this, which might be related:
To me, this looks like a bug. What do you think?
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.
* technically easy, depending on how it's done
* simplifies communication for me (no need to send pull requests to the
* will result in fast updates in the future
* adds no more dependecy on GitHub services
* 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?
* 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
* requires an external or internal service to be authorized to access
* 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
* 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
* 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
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
f) additional mirrors
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
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
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.
I'm running into issues with a project that uses JACK and would
appreciate help or pointers therewith.
The basic premise is as follows: I want to use JACK to transfer audio
from a _Windows slave_ to a _Linux master_.
I've been using the latest JACK distro I could find (1.9.10). I've
successfully got it to run using NetJack2 (with `jack_load netmanager`
on the master and `jackd -d net` on the slave). It works great...
...But it only works great over Ethernet. And I'd very much like it to
work over WLAN, which it doesn't. Over wireless, the sound is completely
garbled. AFAICT, it's a network issue.
I've tried to tinker with the options to get it to work better (say, at
the cost of latency), but with no success. If anyone has pointers has to
how to improve the setup with NetJack2 in order for it to work over
WLAN, they would be greatly appreciated.
That being said, reading the doc and looking around the web for info
suggests it might very well be the case that NetJack2 simply isn't
suited for WLAN transport. Indeed, some resources indicate that NetJack1
would be more adapted.
Trouble with that, then, is that, at least in the distro I got, NetJack1
doesn't work on Windows. Trying to start it yields the following error:
netjack_poll not implemented
, after which the program exits.
I've seen a thread (I believe on this list) indicating that at least
some people were aware of the issue, although no solution was provided.
Given that that thread was a bit old, and assuming the above conclusion
-- that NetJack2 isn't suited to wireless -- is correct, I guess my
question boils down to:
Can anyone tell me how I can get NetJack1 work on Windows?
Many thanks in advance, although will have some left for later,
Hi Jack list,
I have a network with 5 slaves (net driver) and 1 netmanager (with
After a while, on slave hang and i got
Sat May 27 17:00:51 2017: ERROR: Recv fd = 94 err = Resource temporarily
Sat May 27 17:00:51 2017: ERROR: Recv connection lost error = Resource
temporarily unavailable, 'PiFm_Bar' exiting
This one try to reconnect and the master add a new 'PiFm_Bar'
Sat May 27 17:00:51 2017: ERROR: Recv fd = 94 err = Resource temporarily
Sat May 27 17:00:51 2017: ERROR: Recv connection lost error = Resource
temporarily unavailable, 'PiFm_Bar' exiting
And the cycle happen again.
The network parameters :
Sat May 27 17:00:51 2017: **************** Network parameters
Sat May 27 17:00:51 2017: Name : PiFm_Bar
Sat May 27 17:00:51 2017: Protocol revision : 8
Sat May 27 17:00:51 2017: MTU : 1500
Sat May 27 17:00:51 2017: Master name : LaChoze
Sat May 27 17:00:51 2017: Slave name : PiFm_Bar
Sat May 27 17:00:51 2017: ID : 9
Sat May 27 17:00:51 2017: Transport Sync : no
Sat May 27 17:00:51 2017: Send channels (audio - midi) : 2 - 3
Sat May 27 17:00:51 2017: Return channels (audio - midi) : 0 - 3
Sat May 27 17:00:51 2017: Sample rate : 48000 frames per second
Sat May 27 17:00:51 2017: Period size : 256 frames per period
Sat May 27 17:00:51 2017: Network latency : 10 cycles
Sat May 27 17:00:51 2017: SampleEncoder : Float
Sat May 27 17:00:51 2017: Slave mode : async
Sat May 27 17:00:51 2017:
After that, the full jack server (master) hang, with all clients (Ardour
have a memory leak and is killed).
Is this problem become from jack's configuration, network or netjack ?
Thanks a lot,
I have an RME Hammerfall DSP, a card that I believe supports --hwmix on
jackd. How does this work? Does this require special support by the
application? If so, which applications exist using it via Jack?
And yes, I've looked through the documentation I could readily find and
I am sure that I am missing something.
By the way: subscribing to this list is ridiculously hard. It is called
"jack-devel(a)lists.jackaudio.org". Mailing to it gets an autoresponse to
please subscribe before mailing. There is no info how to do this in the
mail, not even in the headers, and the sender is
Looking at the general list host "http://lists.jackaudio.org" states
that the list overview has been disabled and that one should append the
list name to "the current URL" in order to find the info. Which does
not work. It turns out that the "list name" isn't actually "jack-devel"
but rather "jack-devel-jackaudio.org".
Reminds me of the Usenet group alt.hack which was moderated without a
moderator. You were eligible for posting there if you figured out how
to do it.
I couldn't agree more. I posted a message to asking about the download
links on April 12. Nobody ever responded to me.
In the meantime, I just checked, and those bad dropbox links still exist on
the jack website.
Since I and others have inquired about the download links, you guys have
wasted no time answering someone's query's about using a Macbook with the
With all due respect, this project is a joke -- plus, once I finally did
manage to find the download links and install it, it didn't work on my
system (W7 64 bit). I wouldn't dream of even attempting to get help on this
Again, what a joke: this is the reason open source software will never
catch on. You guys just don't care.
On Fri, May 5, 2017 at 5:19 AM, Jörn Nettingsmeier <
> On 05/04/2017 02:20 PM, IOhannes m zmoelnig wrote:
>> i think the current state is a real disservice to the project (at
>> least for all those users who cannot just emerge/yum/apt install JACK),
>> which might explain the slightly sarcastic tone.
>> ¹ reminder to self: get out of sarcasm mode asap.
> I also think this dropbox stuff for osx is extremely weird - I never cared
> until I got myself a used macbook for professional reasons, but it feels
> Jörn Nettingsmeier
> De Rijpgracht 8, 1055VR Amsterdam, Nederland
> Tel. +49 177 7937487
> Meister für Veranstaltungstechnik (Bühne/Studio), Tonmeister VDT
> Jack-Devel mailing list
Hello users and developers of JACK,
recently, there have been a lot more questions and remarks about the
jackaudio.org homepage and the releases, especially of jack2.
Since most of these questions and remarks are entirely justified, this
mail (bad news) will provide some insight I have about the current
situation of the page, the release process and how all these things did
happen up to now. This is a long mail, only read it if it is really
relevant to you.
1 the page
The main part of the current homepage for JACK ( jackaudio.org ) is a
set of static html pages, generated from markdown files with jekyll .
The whole build process for the static page is compatible to the GitHub
pages  infrastructure, which means it can be built completely with
and without GitHub and as well as deployed as a GitHub page. Further
details can be obtained from the README in the GitHub repository. The
page also contains a html version of the JACK API documentation and some
of the tutorials and Information were moved to a Wiki provided by
GitHub. The sources for the page are hosted as a dedicated repository
on GitHub under the jackaudio organization, together with jack1 and
jack2. Attached to the repository, you can also find the mentioned
Wiki. There is also a dedicated bug tracker for the page attached to
the repository of the homepage on GitHub.
2 webpage hosting
The page is currently hosted on a webspace owned by Paul Davis, who also
owns the jackaudio.org domain. To my best knowledge, only Paul and
Stèpahe Letz have currently access to the webspace. Hosting the page on
this webspace instead of using the GitHub pages infrastructure directly
was a decision made for various reasons.
The domain is also associated to the jack mailing lists which made it
difficult at that time (2014) to point the domain to GitHub pages instead.
Having a page that was not dependent on the GitHub pages infrastructure
was a requirement at the time we transitioned from a broken and hacked
Drupal installation to a static page.
3 webpage development and deployment
The GitHub repository is currently maintained by me with help in form of
bug reports, pull requests and edits of the wiki from the community. If
I determine (by the rule of thumb) that enough changes to the page have
accumulated or a release of jack1 or jack2 occurs, I prepare the page to
be pulled and basically send a pull request to the jack-devel mailing
list, signalling that the github repo should be pulled to the webspace.
Since the page is designed in a way to be compatible with GitHub pages
and already set up to work as a GitHub page, it became accessible under
the github domain , which was nice for development purposes and was
supposed to serve as a preview before pulling changes to the webspace.
4 The case of JACK release binaries
The page also links to release binaries and source tarballs of jack1 and
jack2 (at least it's supposed to). These binaries are not included in
the git repository since having multiple large binaries inside the
repository would make it unfriendly to clone, especially after a few
releases. Multiple approaches to hosting the binaries have been
discussed. Paul did upload the binaries for jack1 to the mentioned
webspace after a release. For jack2, Stéphane decided to use DropBox
public files to host the release binaries. The use of tags on the
respective repositories of jack1 and jack2 was discussed multiple times.
Attaching the release binaries to tags could have solved the hosting
problem. Still, there was the requirement to be independent from GitHub
so this idea was not followed through. Also GitHub LFS was considered
but wasn't ready and released by GitHub in 2014/2015 and also wouldn't
really have resolved the issue of depending on GitHub, since the files
would have still been hosted on GitHub infrastructure. On a new release,
the maintainers would announce new links to the binaries and I would
update the site accordingly. It required manual intervention but since
release cycles were already long I wasn't too worried about that.
5 how it all came down
Over time minor challenges arose. Sometimes it was just GitHub changing
some configuration for their jelkyll configuration, sometimes DropBox
would limit the number of Downloads, sometimes it would take a few days
longer or required a second reminder to get my changes puled to the
webspace. At some point Paul decided to step down as the lead developer
of jack1 but keeping the webspace and the domain online. Reaction times
for getting changes to the webspace became longer (at least it felt like
that to me) and then also DropBox terminated their free hosting of
public shares. At that point a lot of people were also asking for an
update of the jack2 installer on OSX. The whole thing resulted in
multiple questions on the mailinglists, reports in bugtrackers all over
place on lists and bugtrackers I didn't even knew I was subscribed to,
someone even managed to use the review feature on a commit of the jack
repo. I did some mitigation on the bugtrackers and after some time went
by I made a grave mistake.
I went ahead and grabbed the old binaries from archive.org, created tags
for the releases of jack2 for windows and OSX on the repository of the
homepage and attached the files to these tags. I updated the links on
the page, did some additional maintenance and requested the changes to
be pulled to the webspace on the jack-devel list. That was intended to
be an intermediate solution but you may have already guessed that one
part of my mistake: There is a saying, that intermediate solutions are
the ones that will never go away, so sad, so true. Second, attaching the
binaries to the repo of the webpage confused a lot of people since
normally the tag would have been attached to a commit of the jack2
repository. When a tag is created, GitHub automatically creates a source
tarball and zip for the respective commit, so that a developer only has
to attach the release binaries. I could no do this, since a have no
access to the jack2 repository. The problem is, that users do not expect
to find the releases attached to the repository of the homepage and
also, if you take a look at these tags , you will notice that they
have the source tarballs of the homepage attached where a user would
normally expect the source tarball of jack2.
It's a mess right now more so because shortly afterwards I received a
release of the new installer for OSX and Windows and now there is
another release that uses this suboptimal solution and the old page on
the webspace still has the DropBox links. I updatetd the links on the
page in the GitHub repo accordingly, hoping that people would search for
the binaries on the page after it was (supposed to be) pulled, requested
the changes to be pulled to the webspace... that was half a month ago
and there was apparently no pull.
So that's how we ended up with broken dropbox links on the webspace
(jackaudio.org), two* versions of the page (jackaudio. org and ) and
a whole lot of confusion and frustration about source tarballs
containing strange markdown files and not the jack2 source code.
The technical problems are actually not that hard to solve, but a think
wen have an organizational problem here.
There will be a follow up (good news) to this mail where I propose some
ways to clear this mess and how to avoid it in the future, it may be a
base for discussion and LAC should be a good opportunity to get this
sorted out since the most important decision makers will be there.
* To be more correct and as a very observant user mentioned, there are
three versions since the gh-pages branch of the repo also gets special
treatment (see GitHub pages docs for details) but that is not that much
relevant for this topic.
PS: It's already 1 AM and I am still *jacked* and *pun*ching