@@ -44,86 +44,114 @@ <h2 id="project_tagline">TODO</h2>
4444
4545 < h1 id ="how-does-jack-compare-to- "> How does JACK compare to …</ h1 >
4646
47- < h2 id ="how-does-jack-compare-to "> How does JACK compare to…?</ h2 >
47+ < p > Please mail the jack-devel mailing list if you have any concerns about
48+ the answers to these questions. Also, no disrespect to any effort is
49+ intended, only a recognition of different goals and design principles.</ p >
4850
49- < p > Please mail the jackit-devel mailing list if you have any concerns about the
50- answers to these questions. Also, no disrespect to any effort is intended,
51- only a recognition of different goals and design principles.</ p >
52-
53- < h3 id ="other-linux-centered-systems "> Other Linux-centered systems</ h3 >
51+ < h2 id ="other-linux-centered-systems "> Other Linux-centered systems</ h2 >
5452
5553< ul >
56- < li > ALSA: both a HAL and a user-space library for audio under Linux.
57- ALSA is used to provide the default audio i/o driver for JACK.
58- ALSA is a very powerful audio API, but it does not provide a
59- callback-based API or offer any solutions for inter-application
60- communication, though it has been discussed and is theoretically possible.</ li >
61- < li > aRts, a streaming media architecture:
54+ < li >
55+ < p > ALSA: both a HAL and a user-space library for audio under Linux.
56+ ALSA is used to provide the default audio i/o driver for JACK. ALSA
57+ is a very powerful audio API, but it does not provide a callback-based
58+ API or offer any solutions for inter-application communication, though
59+ it has been discussed and is theoretically possible.</ p >
60+ </ li >
61+ < li >
62+ < p > aRts, a streaming media architecture:
6263aRts was not designed from the ground up with low-latency in mind.
63- Not a fault, but a design decision. A jack output element could be written
64- for aRts, though, as far as I can tell.
65- Note: aRts is not really used anymore by any Linux systems.</ li >
66- < li > GStreamer, another streaming media architecture:
64+ Not a fault, but a design decision. A jack output element could be
65+ written for aRts, though, as far as I can tell. Note: aRts is not
66+ really used anymore by any Linux systems.</ p >
67+ </ li >
68+ < li >
69+ < p > GStreamer, another streaming media architecture:
6770GStreamer is designed for in-process construction of media pipelines,
6871and is not used to link applications.
69- JACK elements for GStreamer are under available.</ li >
70- < li > LADSPA, LV2: LADSPA is an internal plugin API for DSP routines,
71- not a way of linking external applications together.</ li >
72- < li > Phonon</ li >
73- < li > Canberra</ li >
72+ JACK elements for GStreamer are under available.</ p >
73+ </ li >
74+ < li >
75+ < p > LADSPA, LV2: LADSPA is an internal plugin API for DSP routines,
76+ not a way of linking external applications together.</ p >
77+ </ li >
78+ < li >
79+ < p > Phonon</ p >
80+ </ li >
81+ < li >
82+ < p > Canberra</ p >
83+ </ li >
7484</ ul >
7585
76- < h3 id ="cross-platform-systems "> Cross-platform systems</ h3 >
86+ < h2 id ="cross-platform-systems "> Cross-platform systems</ h2 >
7787
7888< ul >
79- < li > PortAudio:
80- a “cross platform, open-source, audio I/O library” offering both
81- callback- and blocking I/O-based APIs.
82- PortAudio backends exist for various Windows, Mac, and Unix HALs.
83- It is mainly focused on hardware I/O rather than a general concept of
84- ports and connections. The callback-style API used by both projects
85- makes it relatively easy to port between the two (no pun intended),
86- and there is a JACK backend for PortAudio so porting is not always necessary.</ li >
87- < li > SDL:</ li >
88- < li > SFML:</ li >
89- < li > OpenAL:</ li >
89+ < li >
90+ < p > PortAudio:
91+ a “cross platform, open-source, audio I/O library” offering both
92+ callback- and blocking I/O-based APIs. PortAudio backends exist for
93+ various Windows, Mac, and Unix HALs. It is mainly focused on hardware
94+ I/O rather than a general concept of ports and connections. The
95+ callback-style API used by both projects makes it relatively easy to
96+ port between the two (no pun intended), and there is a JACK backend
97+ for PortAudio so porting is not always necessary.</ p >
98+ </ li >
99+ < li >
100+ < p > SDL:</ p >
101+ </ li >
102+ < li >
103+ < p > SFML:</ p >
104+ </ li >
105+ < li >
106+ < p > OpenAL:</ p >
107+ </ li >
90108</ ul >
91109
92- < h3 id ="macos--andor-windows-centered-systems "> MacOS- and/or Windows-centered systems</ h3 >
110+ < h2 id ="macos--andor-windows-centered-systems "> MacOS- and/or Windows-centered systems</ h2 >
93111
94112< ul >
95- < li > CoreAudio, the Mac OS X audio API:
96- Very similar to JACK in some the sense of being centered on
97- a synchronous-execution-via-callback API, but does not include
113+ < li >
114+ < p > CoreAudio, the Mac OS X audio API:
115+ Very similar to JACK in some the sense of being centered on a
116+ synchronous-execution-via-callback API, but does not include
98117inter-application audio routing. CoreAudio also includes a
99- hardware-level abstraction layer, whereas JACK uses higher-level drivers
100- for that purpose. The first JACK driver was based on ALSA,
101- but others are available for the OSS and PortAudio interfaces.</ li >
102- < li > ASIO:
103- a HAL for both Windows and MacOS that replaces the native device driver model
104- with something much cleaner. It supports hardware-level latencies,
105- but it does not connect applications to each other.
106- Also, it is subject to license restrictions, and does not exist for Linux
107- (though it would not be impossible to implement it on top of ALSA).</ li >
108- < li > ReWire, an inter-app communications API for Windows and MacOS
109- from PropellerHeads and Steinberg, ReWire is similar in that it provides
110- inter-application audio routing, but does not allow for
111- fully independent processes, and has silly restrictions
112- (“up to 64 channels”, etc).
113- JACK also comes without silly license restrictions.</ li >
114- < li > VST, AudioUnits, DirectX, MAS, RTAS:
118+ hardware-level abstraction layer, whereas JACK uses higher-level
119+ drivers for that purpose. The first JACK driver was based on ALSA, but
120+ others are available for the OSS and PortAudio interfaces.</ p >
121+ </ li >
122+ < li >
123+ < p > ASIO:
124+ a HAL for both Windows and MacOS that replaces the native device
125+ driver model with something much cleaner. It supports hardware-level
126+ latencies, but it does not connect applications to each other. Also,
127+ it is subject to license restrictions, and does not exist for Linux
128+ (though it would not be impossible to implement it on top of ALSA).</ p >
129+ </ li >
130+ < li >
131+ < p > ReWire, an inter-app communications API for Windows and MacOS
132+ from PropellerHeads and Steinberg, ReWire is similar in that it
133+ provides inter-application audio routing, but does not allow for fully
134+ independent processes, and has silly restrictions (“up to 64
135+ channels”, etc). JACK also comes without silly license restrictions.</ p >
136+ </ li >
137+ < li >
138+ < p > VST, AudioUnits, DirectX, MAS, RTAS:
115139these are all Windows/MacOS audio plugin APIs. None of them permit
116- inter-application data sharing. Some plugin hosts can make this possible
117- by using some other system such as ReWire. These APIs also require that
118- the callback you write to process/generate data be executed
119- in the context of the plugin host;
120- JACK allows your callback to be executed within the context
121- of your own application (if you wish to).</ li >
122- < li > Virtual Audio Cable, VAC (Windows only):
140+ inter-application data sharing. Some plugin hosts can make this
141+ possible by using some other system such as ReWire. These APIs also
142+ require that the callback you write to process/generate data be
143+ executed in the context of the plugin host; JACK allows your callback
144+ to be executed within the context of your own application (if you wish
145+ to).</ p >
146+ </ li >
147+ < li >
148+ < p > Virtual Audio Cable, VAC (Windows only):
123149Creates a set of virtual audio devices named “Virtual Cables”, each
124- consisting of a pair of the waveform input/output devices. Applications
125- can send audio stream to an output side of a cable, and any other
126- application can receive this stream from an input side. ASIO-compatible.</ li >
150+ consisting of a pair of the waveform input/output devices.
151+ Applications can send audio stream to an output side of a cable, and
152+ any other application can receive this stream from an input side.
153+ ASIO-compatible.</ p >
154+ </ li >
127155</ ul >
128156
129157
0 commit comments