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