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@xxxxxxxxxxxxxxxxxx [mailto:linux-audio-user- > admin@xxxxxxxxxxxxxxxxxx] On Behalf Of Ivica Bukvic > Sent: Monday, April 14, 2003 10:33 AM > To: linux-audio-user@xxxxxxxxxxxxxxxxxx > 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
