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 there,
Does anyone have any examples on how to use the loopback driver ?
If I want to drive an ALSA system and also have loopback going for
everything which hits the ALSA output, is that possible ?
thanks
Matt
Here http://jackaudio.org/downloads/
"Mixed 64/32 bit, 0.90 of JackOSX for Snow Leopard" ==> should be corrected to "Mixed 64/32 bit, 0.90 of JackOSX for Snow Leopard and later…"
Can someone with write access correct that?
Thanks.
Stéphane
Hi,
I using debian's
jackd version 0.124.1 tmpdir /dev/shm protocol 25
started via
jackd -t1500 -dalsa -dhw:2 -r44100 -p128 -n4 -s -Xseq
(or "jackd -Xalsa_midi ...")
Then jackd segfaults shortly after
creating alsa_midi driver ...
- every time, e.g:
jackd[25175]: segfault at 0 ip (null) sp 00000000ffb828ac
error 14 in jackd[8048000+5000]
It does not segfault when -Xseq (-Xalsa_midi) is removed from the
argument list.
The very same invocation (same jackd version!) used to work until now,
but I did update quite a few packages (e.g. libc, ...) in the mean time.
I did try a reinstall of the jackd1-package, but it did not help.
But I have not restarted the computer yet...
Analysis:
Starting jackd in gdb yields:
Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
without any backtrace left.
But with some single-stepping I managed to get to this point:
#0 0xf7f960d7 in jack_client_handle_latency_callback () from
/usr/lib/i386-linux-gnu/libjackserver.so.0
#1 0xf7f89466 in jack_deliver_event () from
/usr/lib/i386-linux-gnu/libjackserver.so.0
#2 0xf7f8b5ca in ?? () from /usr/lib/i386-linux-gnu/libjackserver.so.0
#3 0xf7f8bec1 in jack_sort_graph () from
/usr/lib/i386-linux-gnu/libjackserver.so.0
#4 0xf7f8f792 in jack_client_activate () from
/usr/lib/i386-linux-gnu/libjackserver.so.0
#5 0xf7f8d662 in ?? () from /usr/lib/i386-linux-gnu/libjackserver.so.0
#6 0xf7f8e50a in internal_client_request () from
/usr/lib/i386-linux-gnu/libjackserver.so.0
#7 0xf7f9563e in jack_client_deliver_request () from
/usr/lib/i386-linux-gnu/libjackserver.so.0
#8 0xf7f9868b in jack_activate () from
/usr/lib/i386-linux-gnu/libjackserver.so.0
#9 0xf6b47456 in ?? () from /usr/lib/i386-linux-gnu/jack/jack_alsa_midi.so
#10 0xf7f88faa in jack_add_slave_driver () from
/usr/lib/i386-linux-gnu/libjackserver.so.0
#11 0xf7f89097 in jack_engine_load_slave_driver () from
/usr/lib/i386-linux-gnu/libjackserver.so.0
#12 0x0804a6d4 in ?? ()
#13 0xf7bc8a63 in __libc_start_main
The very next instruction crashes:
0xf7f960db <jack_client_handle_latency_callback+459> call
*0x10f4(%eax)
because *(eax+0x10f4)==0
Starting jackd in valgrind:
[...]
ALSA: use 4 periods for playback
creating alsa_midi driver ...
==25829== Conditional jump or move depends on uninitialised value(s)
==25829== at 0x406EFAC: jack_client_handle_latency_callback (in
/usr/lib/i386-linux-gnu/libjackserver.so.0.0.28)
==25829== by 0x4062465: jack_deliver_event (in
/usr/lib/i386-linux-gnu/libjackserver.so.0.0.28)
==25829== by 0x40645C9: ??? (in
/usr/lib/i386-linux-gnu/libjackserver.so.0.0.28)
==25829== by 0x4064EC0: jack_sort_graph (in
/usr/lib/i386-linux-gnu/libjackserver.so.0.0.28)
==25829== by 0x4068791: jack_client_activate (in
/usr/lib/i386-linux-gnu/libjackserver.so.0.0.28)
==25829== by 0x4066661: ??? (in
/usr/lib/i386-linux-gnu/libjackserver.so.0.0.28)
==25829== by 0x1: ???
==25829==
==25829== Conditional jump or move depends on uninitialised value(s)
==25829== at 0x406EFAC: jack_client_handle_latency_callback (in
/usr/lib/i386-linux-gnu/libjackserver.so.0.0.28)
==25829== by 0x4062465: jack_deliver_event (in
/usr/lib/i386-linux-gnu/libjackserver.so.0.0.28)
==25829== by 0x4064629: ??? (in
/usr/lib/i386-linux-gnu/libjackserver.so.0.0.28)
==25829== by 0x4064EC0: jack_sort_graph (in
/usr/lib/i386-linux-gnu/libjackserver.so.0.0.28)
==25829== by 0x4068791: jack_client_activate (in
/usr/lib/i386-linux-gnu/libjackserver.so.0.0.28)
==25829== by 0x4066661: ??? (in
/usr/lib/i386-linux-gnu/libjackserver.so.0.0.28)
==25829== by 0x1: ???
==25829==
Does this make sense to anyone?
Tobias
Hi, guys!
I recently committed the entry for jack2 to the MXE cross-compiler,
specifically version 1.9.10. One notable thing was needed and that was
linking to flac, vorbis, vorbisenc, and ogg, dependencies that libsndfile
had (needed for static linking). Timothy Gu of MXE suggested that a recent
commit in jack2 utilised pkg-config for libsndfile and that would eliminate
the need of my not-so-pretty hack. Anyway, this is not the main reason for
this message. But any general points about cross-compilation of jack2 and
required/suggested libraries would be nice. The main reason is portaudio.
After building jack2 in MXE, I saw this in my log:
+ install
/home/xnakos/Projects/mxe/usr/i686-w64-mingw32.shared/lib/libportaudio.dll.a
(from build/windows/libportaudio.dll.a)
This resulted in portaudio library, which was already built in MXE as a
requirement for jack2, to be overwritten. I am not quite sure I understand
the reasons for this. So I would really enjoy an explanation! In practice,
when trying to cross-compile Hydrogen drum machine, this overwrite would
result in linking errors such as:
CMakeFiles/hydrogen-core-0.9.7.dir/objects.a(portaudio_driver.cpp.obj): In
function `ZN6H2Core15PortAudioDriver10disconnectEv':
portaudio_driver.cpp:107: undefined reference to `Pa_StopStream'
portaudio_driver.cpp:114: undefined reference to `Pa_CloseStream'
portaudio_driver.cpp:121: undefined reference to `Pa_Terminate'
portaudio_driver.cpp:111: undefined reference to `Pa_GetErrorText'
portaudio_driver.cpp:118: undefined reference to `Pa_GetErrorText'
CMakeFiles/hydrogen-core-0.9.7.dir/objects.a(portaudio_driver.cpp.obj): In
function `ZN6H2Core15PortAudioDriver7connectEv':
portaudio_driver.cpp:71: undefined reference to `Pa_Initialize'
portaudio_driver.cpp:75: undefined reference to `Pa_GetErrorText'
portaudio_driver.cpp:87: undefined reference to `Pa_OpenDefaultStream'
portaudio_driver.cpp:91: undefined reference to `Pa_GetErrorText'
portaudio_driver.cpp:95: undefined reference to `Pa_StartStream'
portaudio_driver.cpp:99: undefined reference to `Pa_GetErrorText'
These errors are not present when linking to the original portaudio
library. Any information would be great, because I am definitely missing a
lot.
Harry
Hi,
I'm trying to compile a 64 bit jack application (radium) with mingw-64.
When I compile it in 32 bit mode, it works fine, but when creating a 64
bit version, it crashes when calling a jack_* function.
The same happens when trying to run a simple test program:
"
#include <jack/jack.h>
int main(){
jack_ringbuffer_create(8000); // (Also crashes if callling
jack_client_open)
return 0;
}
"
If I compile it like this (32 bit):
$ i686-w64-mingw32-gcc winjacktest.c -I/home/kjetil/.wine/drive_c/Program\
Files/Jack/includes /home/kjetil/.wine/drive_c/Program\
Files/Jack/lib/libjack.lib
...it works
But if I compile it like this (64 bit):
$ x86_64-w64-mingw32-gcc winjacktest.c
-I/home/kjetil/.wine/drive_c/Program\ Files/Jack/includes
/home/kjetil/.wine/drive_c/Program\ Files/Jack/lib/libjack64.lib
...it crashes.
I also have a backtrace. The second last frame in the backtrace is the call
to "jack_ringbuffer",
while the last frame shows that an unrelated function is called instead of
jack_rinbuffer_create.
So it seems like either the stack itself is a little bit corrupted, or
libjack64.lib sends the program
further to a random place in the program instead of the libjack64.dll
library. The latter might
be more likely though, since it's the same backtrace every time.
I've tried installed both the 32 bit and the 64 bit version of
jack which are available for download at jackaudio.org. Same behaviour for
both.
My gcc is a little bit old, but I guess that isn't the reason for the crash:
$ x86_64-w64-mingw32-gcc --version
x86_64-w64-mingw32-gcc (GCC) 4.7.2 20120920 (Fedora MinGW 4.7.2-7.fc17)
$ i686-w64-mingw32-gcc --version
i686-w64-mingw32-gcc (GCC) 4.7.2 20120920 (Fedora MinGW 4.7.2-7.fc17)
Thanks for any help. Please let me know if there's anything I should try.
Anyone have an idea why I get xruns with negative values with 0.124.1 on
archlinux?
They look like this: **** alsa_pcm: xrun of at least
-50400583.680 msecs
--
Joakim
Hi,
I work on the creation of a live music/light/video show, with
electro-acoustic composition, and lot more. We need a robust
synchronisation between all elements (synths and OSX / linux computers)
and we want to mix and process with free softwares, so use the netjack
capabilites for transport audio on a gigabyte network.
According to this issue (https://github.com/jackaudio/jack2/issues/124),
the transport sync it's in Work in Progress state from 2011, so if
someone have knowledges and desire for work on this, we can pay some
beer / food / [enter what you want here].
We don't know how many work it needed to get netjack transport sync
working, and maybe it's the first step...
This show it's a little self-production, so wa haven't lot of funds, but
we try to do the best !
Thanks for reading, and thanks for all propositions / ideas !
Hallo,
I'm an active FreeBSD user and I'm trying to nail down a problem of
zombies caused by KDE components which make use of jack-audio-connection-kit-0.121.3
To get this debugged I have inserted a wrapper script as
/usr/local/bin/jackd which does some logging and calls at the end the
real jackd as jackd.bin (see below). I've stumbled over something in the
source and man page of jackd which I do not understand:
The man page explains the flag -l as for changing the LISTEN port, while
the implementation in the C-source use the flag -l to just print the
actual working directory (/tmp) and do exit(0); see below.
Perhaps, the KDE components do not expect the termination of the forked
jackd server and resulting to state zombie.
Do I misunderstand something stupidly wrong? Thanks for a helping hand.
matthias
----- Forwarded message from Matthias Apitz <guru(a)unixarea.de> -----
Date: Fri, 5 Jun 2015 20:04:53 +0200
From: Matthias Apitz <guru(a)unixarea.de>
To: Tobias Berner <tcberner(a)gmail.com>, kde-freebsd(a)kde.org, multimedia(a)freebsd.org
Subject: [kde-freebsd] KDE && jackd flag -l (was: kbiff && zombies)
I have modified the shell wrapper script for jackd as:
#!/bin/sh
printf "\nnew jackd call, pid: %d\n" $$ >> /tmp/jackd
echo args: $0 $* >> /tmp/jackd
/usr/local/bin/jackd.bin $* &
echo last pg pid: $! >> /tmp/jackd
ps axl >> /tmp/jackd
and it turns out that all KDE components, already on KDE start the
/usr/local/bin/knotify4, are calling jackd as
/usr/local/bin/jackd -l
which is fine according the man page of jackd:
-l, --listen-port int
The socket port we are listening on for sync
packets (default: 3000)
but the source of jackd implements with -l only the printout of the
current working directory and exit(0):
case 'l':
/* special flag to allow libjack to determine
* jackd's idea of where tmpdir is */
printf ("%s\n", jack_tmpdir);
exit (0);
I have search in the KDE sources, without any luck, where 'jackd -l' is
issued to understand the problem; no luck; and for the moment I only can
say that there is some missimplementation, either in KDE or in jackd.
matthias
_______________________________________________
kde-freebsd mailing list
kde-freebsd(a)kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information
----- End forwarded message -----
--
Matthias Apitz, guru(a)unixarea.de, http://www.unixarea.de/ +49-170-4527211 +49-176-38902045
"Wenn der Mensch von den Umständen gebildet wird, so muß man die Umstände menschlich bilden."
"Si el hombre es formado por las circunstancias entonces es necesario formar humanamente
las circunstancias", Karl Marx in Die heilige Familie / La sagrada familia (MEW 2, 138)
From: xelnagazchild(a)hotmail.com
To: jack-devel-request(a)lists.jackaudio.org
Subject: FW: [Jack-Devel] jack on OSX
Date: Tue, 26 May 2015 20:59:16 +0200
From: xelnagazchild(a)hotmail.com
To: letz(a)grame.fr
Subject: RE: [Jack-Devel] jack on OSX
Date: Tue, 26 May 2015 13:30:41 +0200
i did attach a crashlog, maybe it didn't make it to the list
Anyway please find it there : https://www.mediafire.com/?n427iy5j7chka04
> Subject: Re: [Jack-Devel] jack on OSX
> From: letz(a)grame.fr
> Date: Tue, 26 May 2015 08:20:07 +0200
> CC: jack-devel(a)lists.jackaudio.org
> To: xelnagazchild(a)hotmail.com
>
> Crash log please?
>
> Stéphane
>
> Le 25 mai 2015 à 19:55, vic hug <xelnagazchild(a)hotmail.com> a écrit :
>
> > i'm asking those questions because, since today, i can't use a game engine named Godot : http://www.godotengine.org/ - it crashes on startup, and it will only launch when i uninstall Jack. The weird thing is that i had Jack installed alongside Godot on my system for some time now. I also tried launching old versions of Godot, and they all crash with a similar looking crashlog.
> > Plus after uninstalling Jack, when emptying the thrash, i get blocked because Jackmp.framework is in use by something in my system - i don't know what.
> > I just tried reinstalling Jack, Godot crashes on launch, uninstalled it, Godot doesn't crash.
> > I installed updates from Apple this weekend concerning commandline tools and XCode and Apple Remote Desktop, so i don't if something could come from here.. I also installed linux-sampler as described here : https://bugs.linuxsampler.org/cgi-bin/show_bug.cgi?id=240 so maybe a conflict there ?... anyway i attach a crashlog, it might be more informative than my babbling...
> > sorry for the flood, thanks in advance
> >
> > From: xelnagazchild(a)hotmail.com
> > To: jack-devel(a)lists.jackaudio.org
> > Date: Mon, 25 May 2015 19:36:21 +0200
> > Subject: Re: [Jack-Devel] jack on OSX
> >
> > To be more accurate, i'm using yosemite (10.10.3)
> >
> > From: xelnagazchild(a)hotmail.com
> > To: jack-devel(a)lists.jackaudio.org
> > Date: Mon, 25 May 2015 19:34:24 +0200
> > Subject: [Jack-Devel] jack on OSX
> >
> > 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
> >
> > _______________________________________________ Jack-Devel mailing list Jack-Devel@lists.jackaudio.orghttp://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
> >
> > _______________________________________________ Jack-Devel mailing list Jack-Devel@lists.jackaudio.orghttp://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
> > <Godot_2015-05-25-194213_Macintosh-de-Vic.crash>_______________________________________________
> > Jack-Devel mailing list
> > Jack-Devel(a)lists.jackaudio.org
> > http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>