<br><br><div class="gmail_quote">On Tue, Sep 4, 2012 at 3:07 AM, Grant <span dir="ltr"><<a href="mailto:emailgrant@gmail.com" target="_blank">emailgrant@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">>> jackd also includes an alsa to jack bridge, as does the aforementioned<br>
>> zita-ajbridge. both are easy to use, the latter is very low latency<br>
><br>
><br>
> "bridge" is sort of the wrong word. both these tools make ALSA-supported<br>
> audio interfaces available to JACK clients, in addition to whatever backend<br>
> the JACK server is using. they do not "bridge" between an application that<br>
> uses ALSA and JACK.<br>
><br>
> sort of.<br>
<br>
</div>Just so I understand, the practical result of this is that I can use<br>
an audio application which lacks jack support (perhaps iTunes?) and<br>
send its audio output to jackd?<br></blockquote><div><br>on OS X, any application that uses CoreAudio for audio I/O (which basically means every application except JACK native ones) can use JACK as its input and/or output device. configuring this is generally trivial.<br>
<br>on Windows, any application that uses ASIO for audio I/O (which basically means most pro-audio/music creation applications) can use JACK as its input and/or output device. configuring this is generally easy.<br><br>on Linux, any application that uses GStreamer (or a layer above it), ffmeg, the regular ALSA PCM API or PulseAudio's audio API can use JACK as its input/output device. configuring this can range from easy to quite tricky. <br>
</div></div>