[ut2004] Text-To-Speed Working on Single Channel Cards (I think)

[Matthew N Cheely]

Last I heard, this won't work for teamspeak, because teamspeak is an OSS
only program, and uses fopen(), which is incompatible with the aoss
emulation script. Check out the ALSAWiki page for teamspeak for a longer
discussion:

http://opensrc.org/alsa/index.php?page=TeamSpeak

On Thu, 15 Apr 2004, Peter Wright wrote:

> On Thu, 2004-04-15 at 02:45, Matthew N Cheely wrote:
>
> Does this Virtual Audio Device work for all programs? Because when
> running Team Speak you dont get the sound through UT :(
>
> > It came up earlier that some people were having trouble with
> > text-to-speech (TTS) in ut2004, because their soundcarWe do this bds could only handle
> > one stream at a time. The symptoms were that you would get no TTS during
> > the game, but when the game quit, all of the sudden you'd hear all the
> > TTS from the game. I am pretty sure I have figured out how to solve this
> > problem, but I can't take the last step of testing it with unreal, because
> > I have since discovered that ut2004 and my alsa libraries don't seem to
> > play nice together for some reason. So, I'm going to explain in detail how
> > to get it set up on the list, and you guys let me know if it works.
> >
> > Okay, so you've done everything listed at
> > http://www.icculus.org/lgWe do this bfaq/#ut2k4tts
> > and you've got the symptoms listed above.
> >
> > The first thing to do is to set up a virtual audio device for your alsa
> > driver that can do software mixing, using the dmix plugin, which is part
> > of alsa. We do this by creating/editing /etc/asound.conf We use
> > /etc/asound.conf so that our settings will apply systemwide, since both
> > the festival sever run by speechd as root and our user programs will need
> > to be able to use the configuration.
> >
> > Here is my /etc/asound.conf file.
> >
> > ---snip----
> >
> > #unmixed device for programs that have trouble with dmix (xine)
> > pcm.unmixed {
> > 	type hw
> > 	card 0
> > }
> >
> > #handles software mixing of output
> > pcm.dmixer {
> > 	ipc_key 1024
> > 	type dmix
> > 	slave.pcm "hw:0,0"
> > }
> >
> > #handles software mixing of capture
> > pcm.dsnooper {
> > 	ipc_key 2048
> > 	type dsnoop
> > 	slave.pcm "hw:0,0"
> > }
> >
> > #fuses input and output mixing into a duplex device
> > pcm.duplex {
> > 	type asym
> > 	playback.pcm "dmixer"
> > 	capture.pcm "dsnooper"
> > }
> >
> > #this has something to do with sample rate conversion
> > pcm.!default {
> > 	type plug
> > 	slave.pcm "duplex"
> > }
> >
> > #control device
> > ctl.!default {
> > 	type hw
> > 	card 0
> > }
> >
> > #aoss emulation stuff:
> > pcm.dsp0 {
> > 	type plug
> > 	slave.pcm "duplex"
> > }
> >
> > ctl.mixer0 {
> > 	type hw
> > 	card 0
> > }
> >
> > #end aoss stuff
> >
> >
> > ---snip----
> >
> > Most people should just be able to copy this file to their
> > /etc/asound.conf and mixing should work nicely. The file basically
> > just creates a bunch of virutal audio devices (pcms):
> >
> > unmixed => This pcm is just an alias for direct hardware access. We tell a
> > program to use the 'umixed' device if we want it to bypass all our
> > software mixing plugins.
> >
> > dmixer => This device uses the dmix plugin in also to perform software
> > mixing. As long as all our programs' sound outputs are passing through
> > this device, we'll hear all of them at once.
> >
> > dsnooper => This device uses the dsnoop plugin, which is like dmix,
> > except it mixes the soundcard's input channels so we can capture from more
> > than one device at a time (the CD and MIC, for example)
> >
> > duplex => This device uses the asym plugin to give us a single device
> > which we can capture from and output to with mixing. It redirects any
> > output sent to it to the dmixer device, and if it is asked for capture
> > information, it uses the dsnooper device
> >
> > !default => This is the device alsa programs will use by default if we
> > don't specify a device. It is just an alias for the duplex device. Why
> > didn't we just name the duplex device !default? Honestly, I'm not exactly
> > sure, but I think it has something to do with sample rate conversion. I
> > tried it both ways, and it only works for me this way.
> >
> > ctl.!default => This is the mixer device for setting volumes and stuff,
> > just tells things to go straight to the hardware for that.
> >
> > dsp0 and mixer0 are special devices which can be used by programs designed
> > to work with oss sound drivers (/dev/dsp and /dev/mixer). This way you can
> > use the pcm plugin functionality of dmix and dsnoop with oss programs.
> > There's a catch, though. This doesn't work with the oss emulation kernel
> > modules. You have to use a special 'aoss' script. To use it, make sure
> > the oss emulation modules aren't loaded or compiled into your kernel. Then
> > you just append 'aoss' before whatever program you want to run, i.e.:
> >
> > aoss mpg123 foo.mp3
> >
> > Not that this won't work with programs that use libc's fopen() function to
> > access /dev/dsp, only programs that use glibc's open(). If you don't
> > understand this, just know that it doesn't work with everything.
> >
> > So, anyway, as you can see, I've just attached the dsp0 device to my
> > duplex device.
> >
> > Alright, so the sound card should be configured for software mixing. Try
> > it out by running a couple of alsa programs like aplay or alsaplayer at
> > the same time.
> >
> > Now we have to get festival working with alsa. It's an oss program, and it
> > doesn't use fopen() so we should be able to use the aoss script. However,
> > this doesn't work when festival is in server mode for some weird reason I
> > have yet to figure out. It works fine in interactive mode, but that's no
> > good to us, because speechd necessarily uses the server mode. If anybody
> > out there who's a better programmer than me (most anybody) cares to look
> > at the code and see if they can figure it out, it would be excellent. I
> > tried asking people on the festival mailing list about this, but got no
> > response.
> >
> > Never fear, however! Festival luckily has several audio output modes, one
> > of which will run the program of your choice. We just have to set it up to
> > use this mode and the appropriate program. To make sure this happens
> > whenever it runs, we add the following lines to /etc/festival.scm
> >
> > (Parameter.set 'Audio_Command "aplay -f S16_LE -t raw -r $SR $FILE")
> > (Parameter.set 'Audio_Method 'Audio_Command)
> >
> > This tells festival to use the command "aplay" (which uses the alsa
> > driver) to play our soundfile, a signed-16-bit-little-endian (-f S16_LE)
> > raw (-t raw) file. Festival will provide the sample rate and file name
> > in the $SR and $FILE positions.
> >
> > Now you should be good to go. I'd test this first with alsaplayer or
> > aplay and /dev/speech, before trying it in ut2004. The reason being that
> > ut2004 may be trying to use OSS devices without you knowing it, which it
> > does silently if ALSA fails for any reason.
> >
> > Here are some handy links for you. I got most of this information from
> > somwhere on the following pages. There are examples of more complex stuff
> > you can do with dmix and dsnoop. One thing I learned from reasearching all
> > this - ALSA is bad-ass.
> >
> > Alsa Wiki: has good pages on dmix and .asoundrc (asound.conf)
> > http://alsa.opensrc.org
> >
> > Alsa Documentation: has a page on .asoundrc, info on specific soundcards, etc.
> > http://www.alsa-project.org/documentation.php3
> >
> > Festival Homepage: (seems to be down today)
> > http://www.cstr.ed.ac.uk/projects/festival/
> >
> >
>
>