Finally reading the jackd manpage again (
http://linux.die.net/man/1/jackd ) I notice
////// ////////// ///////// ///////// ////// ///////
-H, --hwmon
Enable hardware monitoring of capture ports. This is a method for
obtaining "zero latency" monitoring of audio input. It requires
support in hardware and from the underlying ALSA device driver.
When enabled, requests to monitor capture ports will be satisfied by
creating a direct signal path between audio interface input and output
connectors, with no processing by the host computer at all. This
offers the lowest possible latency for the monitored signal.
Presently (March 2003), only the RME Hammerfall series and cards based
on the ICE1712 chipset (M-Audio Delta series, Terratec, and others)
support --hwmon. In the future, some consumer cards may also be
supported by modifying their mixer settings.
Without --hwmon, port monitoring requires JACK to read audio into
system memory, then copy it back out to the hardware again, imposing
the basic JACK system latency determined by the --period and
--nperiods parameters.
////// ////////// ///////// ///////// ////// ///////
I've had this option set forever in qjackctl, and I haven't seen
anything particularly special going on. The digital monitor outputs
that can be mixed via envy24control(1) or
http://mudita24.googlecode.com (see screenshots) are available as
"catpure_11" and "capture_12" whether or not this option is given to
jackd.
So what exactly does this option do? Or is it automatically enabled,
when set, by making a connection between the capture ports and the
output ports?
Being able to use "zero latency monitoring" with jackd is annoying
using jackd AND envy24control(1) or mudita24 -- if you manually setup
"Zero latency monitoring" in the "Patchbay/Router" panel like I have
in the
http://code.google.com/p/mudita24/ screenshots, eventually
jackd will switch them back to PCM outputs. Therefore you must do the
routing via jackd if you're using jack. It would be nice to know that
the "-H" option set by qjackctl's setup actually did something useful,
like magically tell ALSA (via amixer(1)) to route the output
appropriately. (Note that at the ALSA level, the use of jackd only
results in switching outputs back to their PCMs, I"ve never figured
out how to get jack to automatically switch them back to the the
digital mixer, based on routing done in qjackctl.)
Niels
http://nielsmayer.com
PS: likewise what does the "-M, --hwmeter" option do -- again I don't
see any difference between this being on or off. And how would it know
of the vagaries of the ice1712's metering, the fact that it's a peak
meter registering 0 to -48.1dbFS? I'd imagine other hardware metering
(RME? MOTU) might have have DSP-based RMS metering, and a totally
different architecture than:
http://nielsmayer.com/envy24control/envy24mixer-architecture.png