Forgot to add, that the main benefit of doing this is that then both
apps can share the same dsp resource, which is prolly what you were
aiming at (at least that was my assumption, since I remember vaguely you
mentioning artsd somewhere in there).
NB: there is also dmix and snoop alsa plugins that do the same thing,
but I've not had much luck running that with the apps that do not
natively support alsa, and even furthermore, some native alsa apps have
had issues with it (at least in my case).
Ico
-----Original Message-----
From: linux-audio-user-admin(a)music.columbia.edu
[mailto:linux-audio-user-
admin(a)music.columbia.edu] On Behalf Of Ivica Bukvic
Sent: Monday, April 14, 2003 10:33 AM
To: linux-audio-user(a)music.columbia.edu
Subject: RE: [linux-audio-user] ALSA device sharing?
> On Sun, 13 Apr 2003 20:22:34 -0400, Ivica Bukvic wrote / a écrit:
>
> > jacklaunch <appname> <flags...etc>
>
> Hi
>
> I'm so confused here: I was believing jack needed alsa to work. So
if
alsa
> is launched before, xmms and xine should run fine because they see
and
use
alsa/oss emulation.
What am I missing here?
It does, but once the alsa is running, and jackd is running on top of
alsa, you can use jacklaunch hack to open up a new full-duplex
connection to jackd even with the apps that do not natively support
jack's framework (regardless whether it is oss or alsa, I think --
I've
tested it only with oss apps). This does cost you some
latency, but is
still generally lightyears ahead of artsd, esd and other such stuff.
Hope this helps!
Ico