6 Sep
2005
6 Sep
'05
9:18 a.m.
How about a nicer interface to do synchronized I/O ? Currently the docs say,
in effect: "this is really hard .. just use JACK". I like JACK but there are
someinstances where it is not needed.
-Ben
6 Sep
6 Sep
9:48 a.m.
On Tue, 2005-09-06 at 08:58 -0500, Ben Loftis wrote:
How about a nicer interface to do synchronized I/O ?
Currently the docs say,
in effect: "this is really hard .. just use JACK". I like JACK but there are
someinstances where it is not needed.
JACK does not add significant overhead. There's really no reason not to
use it.
Lee
11:09 a.m.
On Tue, 2005-09-06 at 09:48 -0400, Lee Revell wrote:
On Tue, 2005-09-06 at 08:58 -0500, Ben Loftis wrote:
overhead, no. complication and runtime dependencies, yes.
i can easily imagine people building embedded linux audio systems who
would not want to use JACK, and i think they could very well be right to
do so.
--p
How about a nicer interface to do synchronized
I/O ? Currently the docs say,
in effect: "this is really hard .. just use JACK". I like JACK but there are
someinstances where it is not needed.
JACK does not add significant overhead. There's really no reason not to
use it.
11:20 a.m.
On Tue, 2005-09-06 at 11:10 -0400, Paul Davis wrote:
On Tue, 2005-09-06 at 09:48 -0400, Lee Revell wrote:
OK.
So what exactly is meant here by "synchronized I/O"?
Lee
On Tue, 2005-09-06 at 08:58 -0500, Ben Loftis
wrote:
overhead, no. complication and runtime dependencies, yes.
i can easily imagine people building embedded linux audio systems who
would not want to use JACK, and i think they could very well be right to
do so. How about a nicer interface to do synchronized
I/O ? Currently the docs say,
in effect: "this is really hard .. just use JACK". I like JACK but there are
someinstances where it is not needed.
JACK does not add significant overhead. There's really no reason not to
use it.
6813
days inactive
6813
days old
linux-audio-dev@lists.linuxaudio.org
3 comments
3 participants
participants (3)
-
Ben Loftis -
Lee Revell -
Paul Davis