22 Mar
2005
22 Mar
'05
5:16 p.m.
On Tue, 22 Mar 2005 11:31:02 +0000, Steve Harris
<S.W.Harris(a)ecs.soton.ac.uk> wrote:
[...]
Thanks alot for your reply ;-)
I do care; this is also why I'm wondering if JACK will turn out to be
an unneeded overhead or not, also I'd like to make sure that I can make
the most of whatever sound-card features will be available.
So far the plusses for using JACK is:
- Simpler API for audio output (simpler than raw alsa lib)
- Integrated mixing of streams
- Renders audio capture practicly transperent.
That being said, my concerns are:
- Having an intermediate daemon application between the streaming
application and the kernel will definitly cause a significant overhead
in terms of context switches. Although JACK brags of handleing
these context switches and scheduling in a clean and thought out
fashion; I'll only have one application to stream from, the that defeats
the purpose of /scheduling/ it.
- Using JACK as a stream mixer may bring us further away from
the metal than we'd like to be,
* does "dmix" make use of any of the sound card's features to
perform
multi-stream mixing ?
* does JACK ?
So far I think that JACK will simplify the project alot, I just
have to figure
out how many cpu cycles it will cost and if we can save those cycles by
writing code ;-)
Cheers,
-Tristan
- Is JACK a
suitable place to implement entire audio pipelines ?
(i.e. if I have one "jack client" for each link in the pipeline; one
reading an mp3 file, another decoding the mp3 file and outputting
pcm data and another one creating FFT data for other purposes etc.)
No. In particular sending FFT data over JACK will be tricky.
I would only use JACK for PCM i/o, and do everything else with some other
IPC.
- Is ALSA capable of really "mixing" or
does it only route available
commands supported by the hardware ?
Goggle for dmix. If you care about this though, JACK is probably better.