Hi list,
(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.
Kindest regards,
Stefan
On Fri, 07 Dec 2018, liebrecht(a)grossmann-venter.com wrote:
>On 2018-12-07 00:54, Ralf Mardorf wrote:
>> However, hardware monitoring when using Class Compliant USB devices
>> usually can't be done by the audio device's internal routing, a
>> mixing console is needed for latency free monitoring, while cards
>> that need an individual ALSA driver, such as the HDSPe AIO might be
>> able to use the internal hardware routing (e.g. by hdspmixer).
>Thanks all for the insightful responses.
>
>The last part of your answer is something I dont see often.
>Do you have any point of departure where I can read up about which
>devices can access the onboard DSP of audio interfaces such as those
>you mention eg 1818vsl or other. It is the first time I see hints of
>someone or programs able to access the onboard DSP for low latency
>monitoring. Didnt see this ever mentioned but it is desperately
>needed. After receiving your post I tried to find similar on the web,
>but it is all very unclear what is possible and for which devices.
Please reply to the mailing list and don't top-post.
That is probably a misunderstanding. The Presonus and the Focusrite 2nd
gen USB devices don't provide access to the device's internal routing
when using it with a Linux machine. They are class compliant and don't
need individual drivers. Sound devices that aren't class compliant need
an individual driver and there might be access to the device's internal
routing, as there is for some RME audio devices, when using the Linux's
hdspmixer wich is similar to RME's totalmix,
http://www.rme-audio.de/en/support/techinfo/hdsp_totalmix_software.php.
Monitoring without latency means, that you could route the input
channels, directly to the output channels. IOW if you connect a
microphone, you could listen to the unprocessed signal without latency,
it's not the signal processed by your Linux machine.
On Tue, February 19, 2019 23:43, Adrian Knoth wrote:
> Hi!
>
>
>> the list archive
>> http://lists.jackaudio.org/private.cgi/jack-devel-jackaudio.org
>> starts from April 2015.
>>
>> - Does anybody know about earlier archives?
>> - Does anybody have (personal) copies of the archives?
>>
>
> I've found a copy (including the LAD list) on my machine.
>
>
> Goes back to at least 2011.
>
>
> You can download it here:
>
>
> http://adi.loris.tv/linuxaudio.tar.xz
>
>
> Let me know if you make this publicly available somewhere. You probably
> need to disentangle the multiple lists in this archive by checking some
> header fields.
>
Thank you Adrian! I'll have a look.
Currently the mailing list archive is for members only. Then again
nabble.com seems to have a copy of the whole archive.
Would there be any issue for anybody if all archives are published
publicly (say in a github repository)?. Any thoughts?
Greetings
Hi guys,
I'm seeing segfaults caused by an incorrect regex (found while fooling
around to see what syntax is allowed, since it's not really documented).
Turns out the correct answer to that is "regexec.c", and thus, POSIX
regexes. Someone might want to put that in the docs somewhere.
Thread 1 "shairport-sync" hit Breakpoint 1, jack_init (argc=<optimized
out>, argv=<optimized out>)
at audio_jack.c:221
221 if (config.jack_autoconnect_pattern != NULL) {
(gdb) print config.jack_autoconnect_pattern
$1 = 0x5c8a0 "effect_1:in{L|R}"
^--- this is likely the problem
(gdb) step
222 debug(1, "config.jack_autoconnect_pattern is %s.",
config.jack_autoconnect_pattern);
(gdb) next
223 const char** port_list = jack_get_ports(client,
config.jack_autoconnect_pattern,
(gdb) step
Thread 1 "shairport-sync" received signal SIGSEGV, Segmentation fault.
0x76847e8c in __regexec (preg=<optimized out>, string=0x71801e34
"system:playback_1", nmatch=0, pmatch=0x0,
eflags=0) at regexec.c:243
243 regexec.c: No such file or directory.
(gdb) bt
#0 0x76847e8c in __regexec (preg=<optimized out>, string=0x71801e34
"system:playback_1", nmatch=0, pmatch=0x0,
eflags=0) at regexec.c:243
#1 0x76f1d0f4 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#2 0x76f1d1c4 in ?? () from /usr/lib/arm-linux-gnueabihf/libjack.so.0
#3 0x0002c988 in jack_init (argc=<optimized out>, argv=<optimized out>)
at audio_jack.c:223
#4 0x00016adc in main (argc=1, argv=0x7efffc54) at shairport.c:1474
It turns out that the return value of regcomp is not checked by libjack.
That's the last point where a segfault can be prevented from a simple
syntax error. The only way to catch that in the application is to set up
an entirely redundant regex scaffold and check the regcomp return value,
before throwing it all away and letting libjack do the work all over again.
In the case of configurable auto-connect patterns, which many JACK
clients now offer as a sane and useful replacement of auto-connecting to
system:playback_N, this SEGV is triggered by end-user action, not
programmer mistake. That's a harsh user experience, and should be fixed.
A brief look at the source seems to indicate the problem also exists in
jack1.
I don't really feel qualified to tackle this myself, since it will
require lots of error handling in a multi-threaded library, which I
don't know too much about... glad to help testing, though.
All best,
Jörn
--
Jörn Nettingsmeier
Tuinbouwstraat 180, 1097 ZB Amsterdam, Nederland
Tel. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio), Tonmeister VDT
http://stackingdwarves.net
Hi all,
the list archive
http://lists.jackaudio.org/private.cgi/jack-devel-jackaudio.org/
starts from April 2015.
- Does anybody know about earlier archives?
- Does anybody have (personal) copies of the archives?
Any hints are valuable, thanks
Greetings
Thomas
I am helping check out a new ALSA driver, and it seems that jackd is not
happy with the capabilities this driver provides:
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
ALSA: mmap-based access is not possible for the capture stream of this
audio interface
ALSA: cannot configure capture channel
Not just capture:
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
ALSA: mmap-based access is not possible for the playback stream of this
audio interface
ALSA: cannot configure playback channel
I am not very familiar yet with low level ALSA drivers, any tips where I
should look to see what the driver messed up? Is mmap access usually a
requirement for ALSA drivers? Is it technically optional but highly
recommended, or it is required and this driver is just incomplete?
--
Chris Caudle