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

[Peter Wright]

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/
> 
>