4 May
2017
4 May
'17
6:52 p.m.
"Chris Caudle" <chris(a)chriscaudle.org> writes:
So what? If Jack transparently reverts to software monitoring in its
realtime thread when hardware monitoring is not available, the program
works as well as possible on either hardware.
Uh what? The Roland is an accordion. It has an analog line out and a
digital Midi out. It does not accept any feedback during normal
operation.
That's one bit? Uh, that makes it hard to guess what it even does on a
multi-channel card like the RME.
I found this reply from Paul Davis (original jackd
author/designer) for
essentially the same question from many years back:
---------------------------
On Fri, Aug 27, 2010 at 3:29 PM, Niels Mayer <[hidden email]> wrote:
The hardware specific utilities do a much less versatile job than Ardour
could (for example, I can control Ardour using my nanoKontrol device,
but not hdspmixer). And having one utility for every card is a hopeless
feat.
Finally reading the jackd manpage again (
http://linux.die.net/man/1/jackd ) I notice
-H, --hwmon
Most people do not use this. It is entirely replaced by using a h/w
specific utility (such as hdspmixer or envy2ctl) to control signal
routing. The one benefit that it has is that it means that JACK
*applications*
can control that kind of routing, which early in the life of Ardour
seemed kind of important. It no longer seems very important. If
you're already using a h/w specific utility for this purpose, then
don't use -H.
That doesn't really tell what the option does. It just provides a bit
of history around it. And I suspect from the options Ardour provides me
when using a Hammerfall card independent of the presence or absence of
--hwmon that --hwmon is also a noop as an option and essentially
unconditionally enabled when the card supports it.
---------------------------
So it looks like this feature never really became common, and it
appears that the jackd hardware monitor option only works on ICE or
hdsp based cards. Maybe a few others, but unfortunately you would
have to inspect the ALSA driver source to make sure.
And likely the Ardour source to figure out what it does. Assuming that
it is related to the "via Audio Driver" monitoring option.
On Thu, May 4, 2017 4:17 am, David Kastrup wrote:
Yes. The audio interface gets the line outs from the Roland and
provides a line out of itself. This line out is mixed from the output
of the Aeolus organ and the line outs from the Roland. When the Midi
program switches from the Roland signal that it is changed to organ
mode, its key signals are routed to the Aeolus organ and the Roland line
outs are switched off in the audio interface mixer so that the Roland's
undesired organ patches don't mess with the output from Aeolus.
This allows replacing just part of the Roland's patches with stuff
synthesized on my computer while retaining the Roland's selection and
registration mechanisms and switches.
I am currently in the process of Frankensteining
a Roland FR1b "virtual
accordion" with soft- and hardware Midi expanders, and the Roland only
has a single Midi connector that is either in- or output. So when the
registration calls for the Roland to be silent, I have to access the
mixer programmatically.
Which mixer? The mixer in the audio interface? Since I
don't want the software to be tied to a particular soundcard,
a more generic interface that _does_ use hardware monitoring/mixing
of some kind internally when available would seem like the best fit.
In practical terms it seems you will be tied to a particular
soundcard, or at least family of cards, since it seems only the
ICE/envy24 drivers and the RME drivers implemented this feature. Maybe a few others, but good luck figuring out which.
I consider that Jack's job. That would be what makes sense.
But it's
not clear to me where which stuff is being done and whether,
say, using jack_mix_box for the Roland sound control will magically
buy me "zero-latency" monitoring or not.
Only if the ALSA driver reports has_hw_monitoring as true. Which
driver does the Roland sound control use? It really
depends on what --hwmon does and what interfaces of Jack
are involved.
From a quick look at the jackd code it appears that the ALSA backend
of jackd queries the ALSA driver, and if the drivers reports
has_hw_monitoring then it sets the hw_monitoring property of the
driver to on if requested. If the driver reports has_hw_monitoring as false then
it does nothing.
Not really. Most of them have amixer settings, and there are generic
utilities that work with those. But those utilities, again, don't have
control interfaces feeding into them like Ardour has. And jack_mixer,
if I understand correctly, only does software volume control.
the manual pages are vague and terribly outdated
and
That is unfortunately true. For most uses for which jack was designed, it
does what it is needed and has fallen into a barely maintained "just keep
it compiling" kind of state. There is a new jackd maintainer, but I think
just working on it part time, and basic things like keeping man pages and
web pages up to date is not being done currently.
Many ALSA cards have some sort of hardware mixer
Yes, but most of them have utilities for configuring the hardware
mixer. The hwmon option to jackd is just on/off, it
doesn't give any way to
control the gain of the connection, or the routing if there are
multiple inputs and multiple outputs. I think the jackd option never
caught on because it was too limited to be useful.
Well, maybe. In my ideal world, I'd tell Jack which channel I want to
map to which output with which gain, and if it can map this to hardware,
it will, and otherwise use software. But of course this would require
putting this kind of thing into Jack API and responsibility in the
first place. Jack can already connect in- and outputs. Just the gain
is missing...
--
David Kastrup