When I put breakpoints in gui or non-rt audio thread code, no problems.
But when I put breakpoints in rt audio thread code, behaviour is odd.
I can continue the program and even have more breakpoints.
But when the program tries to close, it hangs inside jack_deactivate().
I must kill it and QJackCtl and finally jackd. At bit cumbersome.
Seems breaking into the program hiccups jack.
Any tips or settings I can try?
I realize pausing the app is kinda crazy and over-qualifies
as 'waiting too long in an rt thread' but it seems to
get so far and work OK but fails at the end.
Can it be helped?
While not strictly Linux or "audio", I have a project that MAY
interest some folks here: For gainful employment, I'm involved with a
research project that uses the Pacarana sound engine from Symbolic
Sound. It comes with a proprietary application, Kyma (pronounced
"kee-ma"), which uses drag 'n' drop "patch bay" and a variant of
Smalltalk which Symbolic Sound has named "Capytalk". But the box also
However, my access to the box is limited. So, in order to test out my
code I've built an ... emulator isn't quite the word... mock object, I
guess, to acknowledge my OSC messages with appropriate responses (but
no audio) when I'm not in the same room as the Pacarana. The code is
written in Python 3 and lives out on:
Right now the CLI stuff works well enough for my purposes, and there's
the rudiments of a GUI reproduction of Kyma's Virtual Control Surface
(VCS). The GUI portion requires PySide which requires Qt. Also, it
advertises itself via mDNS / Bonjour / Zeroconf / avahi. It lives in
the newer pipenv virtual environment.
I'm both proud of it and embarrassed by it. ;-)