Hi all,
The build of qjackctl included with jackdmp for windows is getting really
old.
The biggest problem is that the default "startup time" is set too low,
making it
seem like "jack crashes". (I"ve got many complains that "jack crashes").
Another problem is that you manually have to append "-S" to the "Server
Prefix".
So here:
https://github.com/kmatheussen/qjackctl
...I've cloned the official qjackctl repository, fixed these two problems,
and added some files to make it straight forward to build qjackctl under
mingw32.
(Building is just running the "build_mingw32.sh" script)
Windows binary: http://folk.uio.no/~ksvalast/qjackctl.zip
Perhaps this build, or something similar, can be included in the next
release of jack for windows?
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
Hi,
I'm building a test application for doing bit-perfect loopback
testing on my sound card drivers. However, since jack uses floating
point types, it seems that I can't get a bit-perfect data in and out
from (16-bit) 0x0000 to 0xFFFF. the LSB seems to get rounded on and
off, and also it seems that jack enforces a range of -32767 to +32767
instead of -32768 to +32767 (for 16-bit audio).
Is it possible that it's as simple as changing jack_default_audio_sample_t?
:-)
Thanks,
-Caleb
Hello,
I have a question:
Is it expected that calling "get_all_connections(port)" from a port
registration callback in libjack can cause client being timed-out by
jackd1?
See more detailed test-case description and error output below.
I was creating an app where JACK (used only jackd1) manager code would
connect/disconnect JACK ports as they appear or disappear, with the
assumption that it'd be the only app managing jack connections
on-the-fly.
Fairly obvious (expected) way to do it seem to be:
* Init client.
* Run "set_port_registration_callback(my_callback)".
* Enumerate all current ports, create all connections between these.
* On every port registration callback:
* Run "get_all_connections(port)".
* connect() to ports which should-be - but not yet - connected.
* disconnect() from ports that should not be connected, but got
returned from that call.
But when I tried doing that, it seems that running
"get_all_connections(port)" causes (unexpected) error when port with
same name appears for the second time during app lifecycle.
I.e. starting jackd1 as "jackd -d dummy", then starting the client,
then running "alsa_out -d hw:CARD=SB", stopping alsa_out and running it
again, causes the client to time-out.
Error message in client (from libjack, I think):
cannot read result for request type 10 from server (Connection reset by peer)
cannot send event response to engine (Broken pipe)
cannot continue execution of the processing graph (Bad file descriptor)
jack_client_thread: graph error - exiting from JACK
jackd output when this happens:
timeout waiting for client test-client to handle a port registered event
cannot send port registration notification to test-client (Resource temporarily unavailable)
One complication here is that I'm using not a C client, but a python
CFFI wrapper around it (see links below), which seem to translate API
pretty much verbatim from what I see in doxygen docs.
But I can't be sure it's not an issue with the wrapper, of course.
I've attached the python code that 100% reliably reproduces this
behavior on this machine, and on clean a Debian Jessie VM.
Running "get_all_connections(port)" anywhere outside of that callback
seem to resolve (or work around) the issue.
I wasn't able to find any reference to the issue (i.e. something like
"you should not do that!") in the docs or the google, and python module
author can't confirm (see links below) whether it's an API bug/feature
or a problem with python module itself.
So the question is basically whether it's expected behavior of jack API
(and maybe is or should-be documented somewhere), or totally
unexpected, and likely an issue with python module?
Python API wrapper module:
https://github.com/spatialaudio/jackclient-python/
Related issue I've opened with the python API wrapper module:
https://github.com/spatialaudio/jackclient-python/issues/30
Python (python2) code to reproduce the issue (also attached to this mail):
http://hastebin.com/dehubayeyo.py
Code link above also contains instructions on how to run it to
reproduce the issue.
This code depends on python jack client module linked above, which can
be built/installed with e.g. "pip2 install --user jack-client"
(to ~/.local/, "pip" script is usually packaged in distros as
"python2-pip" [arch] or "python-pip" [debian]).
Would appreciate any suggestions. Thanks!
--
Mike Kazantsev // fraggod.net