(Sorry this question has already been discussed but the search function in the archive of the list does not work)
Is anyone working on the problem of getting Jack up and running on MacOS again? I installed Jack with brew but I get these “could not handle external client request” errors which seems to be old problems from looking at search results and GitHub discussions - problems introduced when MacOS audio architecture was changed a while back. Is there any progress on these matters? Is someone working on it? I need Jack as it is a dependency to another library I would like to use but I realize that I might have to abandon MacOS as a platform in the process.
That is such good news. What(low cost) hardware would this development be
used on to support the developers with testing/debugging and maybe even
* MOTU LP32 (Preferred)
* MiniDSP https://www.minidsp.com/products/network-audio/avb-dg (I think
MOTU's switch uses midDSP switch hardware)
I hope someday it will be possible to connect 4 or more 8 channel ADAT
modules (32 channels) to a PC under Ubuntu via AVB with low latency. The
only option to get this done under Windows is a Focursrite DANTE based
Rednet 3 right now because Thunderbolt is not really available there as
well. Plan to get Rednet3, but that does not solve the Linux environment
which I prefer. Would love to be able to use the Rednet 3 under Linux but
since DANTE is proprietary , so unlikely.
My two wishes:
[a] Multi (16+) channel low latency audio I/O using ADAT audio AD/DA
[b[ Bitwig supporting LV2 plugins.
With those two, the Linux Audio environment would be perfect and the world
a better place.
*(Apology for the re-sends and ignore the previous edits. Web based Gmail
is such a annoyance and un-logically structured)*
I am new to jack and trying to setup Jack2 on Ubuntu 17.10 on a Dell
laptop 15-5570 that uses a Realtek ALC3246 sound device.
It is basically working ( I am testing it with simple_client and
latent_client) but I think that I am doing something wrong as the first
time I use it after booting the laptop I get the error.
"ATTENTION: The playback device "hw:0" is already in use. Please stop
the application using it and run JACK again" followed by lots of
"Cannot connect to server socket err = No such file or directory"
"Cannot connect to server request channel"
fuser -v /dev/snd/pcmC0D0p shows that it is use by pulseaudio.
However the 2nd and subsequent runs of the jack example clients work
just fine without any error.
Thanks for any suggestions or help
In Mixbus, I noticed that if I turn the latency up to 1024 samples, my DSP
usage goes from 33% to 23% or so. The problem is, 512 samples is the only
setting that doesn't produce nasty distorted audio, lower or higher are all
bad. In the MPC software I can't even change it, only in Mixbus. I thought
it was maybe due to a rate mismatch. Is there any way to increase the
latency to 1024 and not get that nastiness? Thank you.
Sent from: http://jack-audio.10948.n7.nabble.com/Jackit-f3.html
I have a requirement to do a re-sampling based on drift detected on jitter buffer.
Suppose I have set jack process callback to 128 samples, and I detected that I have to do
an resampling by 10%, ie n_in = 1.1 * nout then I need 12.8 samples more, which is not available and
has to wait for next callback. This will delay my processing. If I make my buffer size
more than 128, I may have to do a decimation based on drift in which direction.
How to handle these cases of having varying buffer size requirements ?
On Thu, February 8, 2018 11:12 am, lowkeyoutlaw wrote:
> Mpc is a stand alone application. There is no way to route
> audio and midi from it to any other application without
> something like VAC or Jack.
> Mixbus' routing doesn't see the MPC audio outs at all on its own.
Then I don't understand what you wrote previously:
"Mixbus can see the MPC's midi out, but Jack cannot."
You did not show how you started jackd, are you using the -X winmme
argument to start the MIDI driver?
I'm looking for the ported C source code of jack_iodelay. At the end of ma page it says
"Originally written in C++ by Fons Adriaensen, ported to C by Torben Hohn."
Please share the link for this C source code.