On Tue, 22 Mar 2005 11:31:02 +0000, Steve Harris
<S.W.Harris@email-addr-hidden> wrote:
[...]
> > - 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.
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
Received on Wed Mar 23 00:15:37 2005
This archive was generated by hypermail 2.1.8 : Wed Mar 23 2005 - 00:15:38 EET