Hello all.
I have embarked on a long journey of porting my radio automation and
mixing system from OSX (making extensive use of Apple's CoreAudio API)
to a Linux/JACK/gstreamer system and potentially, making it a cross
platform application. The application is actually a collection of
programs, ranging from a studio UI, library management UI, database
back-end, and an faceless audio-engine/mix system. I am currently
working on the audio-engine port, since potentially I could port that
and continue to use the old UIs on Macs until I can get those ported as
well.
In order to make this manageable, I decided to pull some audio features
out of my existing audio-engine, notably AudioUnit effects hosting, IAX
phone support, and multiple audio-device support. I should be able to
add VL2 effects hosting and IAX back in at some point. But for the
short term, I can use jack to host effects in another program for now,
and just give up IAX/asterisk integration. The multiple audio-device
support, via my own clock drift measurement and re-sampling scheme, is
a loss for now, but it looks like alas-in and alas-out programs could
be stop-gap approaches to that, and appears to use a similar underlying
approach.
So far, the porting is going much faster than I had expected. Jack2 is
a very clean and well though out API. It is not unlike CoreAudio, only
it's MUCH easier to use. Leveraging JACKs inter-application audio
routing, I have further broken my audio-engine down into a mixing
system and control session host, with separate programs executed for
playing and recording/streaming audio content. This a very nice, clean
way to break thing up, made possible by JACK. Thanks.
That is the big picture. I have come across some questions that I need
a little help with, all regarding the start-up process of the jackd
server:
1) At first, JACK seems to be designed for a single jackd server
running on a system, with the server control API lacking, as far as I
can tell, a method to control multiple servers by name. But then, with
the name command line option, I can actually run multiple servers tied
to different audio devices. Does the server control API simple not
support names at this point? Maybe this is just how JACK evolved,
originally one jackd per machine, then named server support added, but
not fully implemented across all the API?
2) Again, with the named server: I can start a named jackd server. I
can connect to it using QjackCtl by setting the name property in
the advanced tab of QjackCtl settings. But when I try to connect to the
named server from my audio-engine application, via a jack_client_open()
call, passing the name char string, my application instead tries to
start up a jackd server instance, using the command noted in the jackd
man page (first line of $HOME/.jackdrc). Is this a bug, or am I
missing some detail?
3) Regarding the jack_client_open() behavior when no server is yet
running: the function call does seem to execute the first line of
$HOME/.jackdrc and start the jackd server running. However, it
appears to inherit all the file descriptors from my application. This
is a problem because my application is designed to self-restart on a
crash. With jackd holding my application's TCP control socket open, my
application can't restart (bind again to the desired TCP port) until
after I kill the jackd process. I assume the auto-jackd startup code
is forking and execing, and the code simply isn't closing the parent's
file descriptors. Is this a bug or intentional? Is there a way I can
detect if a jackd server is running ahead of time, so I can start the
server myself using my own fork/exec which would closing my descriptors
on the child, then, once I know jackd is running, call
jack_client_open() in my app?
4) because my audio-engine is a faceless application, and can be run
without a desktop session, I need it to be able to connect to a jackd
server run by other users, or to start a jackd server that can be used
by other users. I can verify that with Ubuntu 18.10, I can not start
jackd from a user account, then connect to it from my application
running as a different user, even if I run my app as root, not that I
intend to do that as a real world workaround. Is there some approach,
group permissions possibly, to allowing other users to access a jackd
server?
5) Wishful thinking: Give jackd the ability to read QjackCtl config
files, so I could configure things from the GUI, then stop jackd and be
able to restart it from the server-control API or command line with a
command line option pointing to a config file. Better yet, make a
persistent JACK-aware place to store such file in the file hierarchy.
Thanks,
Ethan Funk
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.
This may have been answered recently but I can't find it.
Is there a way, via the Jack API or Jack server API,
to ask if Jack is already running?
I see there is a DBus command for that in jack_control,
but jack_control crashes for me. Maybe my Python's fault?
Thanks.
Tim.
To consolidate remaining problems
CONFIRMED: Jack routes output to 1818vsl properly. So outputs work.
I verified that sound can be sent to 1818vsl, therefore since I cannot
create any signal in mixbus, I asume that mixbus will be able to send
sound to the 1818vsl successfully as it is connected to the same working
port on jack that setbfree sent sound to the 1818vsl. So that test of
mine confirmed that jack does route correctly to 1818vsl
So in my case we do not have to discuss the output routing to the
interface. Jack seems to do that well.
1) I have to figure out why with jack started and inputs and outputs of
1818vsl connected to mixbus, no sound is received.
Any suggestion how I can test the routing of inputs on the 181vsl to
what jack routed ?
Here is my patchage setup as already reported
"http://grossmann-venter.com/issues/jack/patchage_status-01.png"
The 18 inputs of the 1818vsl is clearly made available and connedcted to
mixbus.
I want to connect some of them to something else I can monitor
independent from mixbus.
Anyone has a suggestion?
Ardour is not a good option, as mixbus is basically ardour with a skin.
I need to add something else to one of the 18 routes and send signal
from the 1818vsl and capture it with something.
Please suggest what you are using to attach to ports to test for data.
Thanks.
2) After (1) is solved etc, I need to get pulseaudio to work through
jack, but I will discuss that later. Without pulseaudio I will not have
any control of desktop sound as there is no volume control. E.g.
audacity blasts at full volume through jack as it by error starts with
full volume at startup..annoying and not pleasant.. So I will have to
route all those through pulseaudio at a later date once I have mixbus
working
As far as I understood there are 3 opinions:
1.) Don't change anything
2.) Add some API-calls to control the volume of every port
3.) Add an API-call to control the volume of system:playback_*
I'd say that 2.) will introduce too much complexity. This is what jack
clients should do.
But some time ago I proposed 3.)
- Not every audio adapter has a software controllable hardware mixer,
e.g. Focusrite Scarlett Solo, 2i2, 2i4. So alsamixer can't do the job.
- No need to break clients' connection to system:playback_* and make
connections to a volume control application like jack_mixer.
That's really nasty when the application connects only at playback
with changing port names, like Audacity. Then you need tools like
jack-plumbing.
I can live without that but that's what new users would appreciate,
especially when there are some apps for the system tray/dock/whatever.
Jack1 is run as following
export JACK_PROMISCUOUS_SERVER=
umask 0
jackd -dalsa
JACK_PROMISCUOUS_SERVER is exported in environment.
Now programs using jack don't show any errors, but there is no sound and jackd gives the following errors:
мар 24 17:25:41 nixos jackd[15035]: jackd 0.125.0
мар 24 17:25:41 nixos jackd[15035]: Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.
мар 24 17:25:41 nixos jackd[15035]: jackd comes with ABSOLUTELY NO WARRANTY
мар 24 17:25:41 nixos jackd[15035]: This is free software, and you are welcome to redistribute it
мар 24 17:25:41 nixos jackd[15035]: under certain conditions; see the file COPYING for details
мар 24 17:25:41 nixos jackd[15035]: JACK compiled with System V SHM support.
мар 24 17:25:41 nixos jackd[15035]: loading driver ..
мар 24 17:25:41 nixos jackd[15035]: creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
мар 24 17:25:41 nixos jackd[15035]: configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
мар 24 17:25:41 nixos jackd[15035]: ALSA: final selected sample format for capture: 32bit integer little-endian
мар 24 17:25:41 nixos jackd[15035]: ALSA: use 2 periods for capture
мар 24 17:25:41 nixos jackd[15035]: ALSA: final selected sample format for playback: 32bit integer little-endian
мар 24 17:25:41 nixos jackd[15035]: ALSA: use 2 periods for playback
мар 24 17:26:23 nixos jackd[15035]: subgraph starting at ADLplug timed out (subgraph_wait_fd=9, status = 0, state = Triggered, pollret = 0 revents = 0x0)
мар 24 17:26:23 nixos jackd[15035]: pp: cannot clean up byte from graph wait fd - no data present
мар 24 17:26:23 nixos jackd[15035]: **** alsa_pcm: xrun of at least 42199.144 msecs
мар 24 17:26:23 nixos jackd[15035]: subgraph starting at ADLplug timed out (subgraph_wait_fd=9, status = 0, state = Triggered, pollret = 0 revents = 0x0)
мар 24 17:26:23 nixos jackd[15035]: pp: cannot clean up byte from graph wait fd - no data present
Holger Marzen wrote:
> I don't know if and how SPDIF-input appears in jackd and if it has to
> be
> routed IN the interface by some magic platform-dependent software.
> I'd test the analog inputs first since they are connected to mixbus.
>
I sorted everything out, there is nothing that do not work
pulseaudio/jack/bluetooth/all desktop sound and I can now route as i
wish with patchage. Very nice.
I can now focus on spdif.
My keyboard is connected to the 1818 via a direct spdif link. I can use
the easy midi connections but I prefer spdif. Always had great results
with it live.
I know that spdif is always routed to the channels 9&10 on 1818vsl.
Somehow though mixbus sees absolutely no signal on 9&10 and I made sure
that all alsa capture volume settings are maximum. All other inputs are
successfully routed to mixbus and I get a signal.
I am just a bit baffled about why it suddenly does not work. All spdif
sync signals are handled between 1818vsl and the keyboard, so that
cannot be the problem unless alsa for some reason need them, but I
cannot see why. It must be the case as mixbus seemingly have timing
ports. My understanding is that I do not need mtc/ltc for any spdif
signal to at least appear in mixbus as a precondition, neither does
1818vsl seemingly forward the clock through usb. If it is alsa seemingly
do not recognize it.
all I can think of is that there is an alsa error muting channels 9&10.
They are clearly connected correctly by jack.
See attached graphic
http://grossmann-venter.com/issues/jack/routes.png
On Tue, March 26, 2019 19:11, liebrecht(a)grossmann-venter.com wrote:
> Not my place to comment on this, but it will be very nice.
With all due respect, you have spilled so much BS to this list that it's
time to stop now, thank you. If you intend to get help from this list,
provide useful information in a dense way, learn how to reply to a list
thread and free yourself from wrong expectations and things you've picked
up elsewhere.
Best regards
Thomas
Regarding my previous post with the same topic.
To consolidate remaining problems
CONFIRMED: I can confirm that mixbus output reaches the 1818vsl. I
switched on the internal metronome in mixbus and it was routed by jack
to the 1818vsl.
The problem now is... how to verify that jack actually routes the inputs
of the 1818vsl properly.
See my previous post regarding this where I ask if someone regularly
tests inputs and outputs with a test program.
I need something independent that will capture from the system capture
data as routed by jack from the system outputs which are routing the
1818vsl inputs..
