On Mon, 05 Apr 2004 03:48:43 +0200 Christopher Loessl <[EMAIL PROTECTED]> wrote:
> Hi, > > I found on the list the following: > > > Can't run TeamSpeak and Quake3 at the same time... :( > > Can someone help me??? > > > > i'm using Debian SID, kernel 2.6.3, I have the correct snd_intel8x0 > > module installed and the "Alsa Conpt. OSS modules" > > > > If anyone need more info I can send it > > No, sadly you can't. You can do this with the commmercial OSS drivers > afaik. Teamspeak and Quake3 are two apps that just don't wanna work > with aoss from the alsa-oss package [quake3 uses mmap and Teamspeak > uses libc's fopen(). For more details, search the ML archives]... > > thats FALSE! > It work: > Just do > 5. Telling alsa your game only needs playback, no recording etc. > Now, to enable your game to play sound you have to tell alsa that your > game will not need to record sound or anything - else alsa will refuse > to give your game the capability to play sounds, since TeamSpeak > already has the rights to record, and no two programme should be able > to. Issue these commands as root: > echo "quake3.x86 0 0 direct" > /proc/asound/card0/pcm0p/oss > echo "quake3.x86 0 0 disable" > /proc/asound/card0/pcm0c/oss > (substite "quake3.x86" with the name you found for your specific game > in(4)). Now you should be able to play your game with sounds while > using TS. Actually: The problem still remains that two programs want to access the playback direction of the soundcard at the same time.. On a soundcard that cannot do hw mixing you will need to use ALSA's dmix pcm plugin.. This can only be achieved by running the two programs via the aoss script [from the alsa-oss package]. It can be pointed to a pcm device from the alsa-lib layer [the relevant name is "dsp0". see man aoss].. Now, teamspeak as of version 2.x cannot be used with aoss.. Well it will start and run, but it's calls to open(), read(), write(), etc.. are not intercepted, so it is really using the kernel OSS emu.. i don't know about the status of mmap in the alsa-oss package. But anyways. Teamspeak not working together with aoss is a real showstopper, even if you get the game to work with aoss. This is all for the playback direction.. Now let's assume we do have a soundcard which does hw mixing for the playback direction. In this case we won't bother with aoss, but use the kernel level OSS emu.. The SC still won't do sharing for recording, so only one app can use the capture direction.. IN this case, even though the SC can do hw mixing, the game will block when started after Teamspeak. Disabling of the capture direction of the kernel OSS emu for the game is the preferred remedy in this case [echo quake3.x86 0 0 disable >/proc/asound/card0/pcm0c/oss] .. On a soundcard w/o hw mixing i can imagine several scenarios: 1] let the game use the playback stream and teamspeak the capture stream.. Maybe they don't interfere, but at least you can hear commands from your buddies [use the appropriate echo commands for enabling/disabling capture/playback directions for the apps]. 2] have a look, if your SC has more than one digital audio playback device [cat /proc/asound/devices]. If so, tweak the OSS emu to use /dev/adsp for the second playback device.. Now configure your game to use /dev/adsp. Teamspeak uses /dev/dsp and maybe it works.. 3] get a better soundcard with hw mixing [you will still need to disable the capture direction for the game]/ Soundcards that do that can be had for as little as 10 bucks used [sb live with emu10k1, or cs46xx based cards].. 4] get a second cheap soundcard and have teamspeak use this second soundcard [but 3 is really the better sulution here].. Now, 2] and 4] have the disadvantage that the sound is coming through different outputs. So you will need to have normaql game sound on the speakers and an extra headset for teamspeak.. 1] has the disadvantage that i don't know if it works.. Therefore 3] really look like the best solution for me.. I have one little question to the alsa devs though: The kernel level OSS emu already does stuff like samplerate conversion, etc.. why can't it be extened to do channel mixing like the commercial oss drivers? I suppose it is unclean design, but a very unclean design that works is better than a clean design that doesn't I therefore ask you: How difficult would it be to implement that? I would give it a try myself. Do you have pointers where to start? Where do i find relevant docs? Florian Schmidt -- kT ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Alsa-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-user
