Re: [Flightgear-devel] festival ... or not
On 11/11/2009 03:49 PM, Stuart Buchanan wrote: Could you put together some text I could add to The Manual please? Here is a start, based on my still-very-limited understanding of the situation: 0) The following two files should be distributed with FG: cat atis.scm (SayText temperature one five dewpoint minus five altimeter two niner niner two nil) atis.scm: done. (quit) cat atis-mbrola.scm (voice_en1_mbrola) (SayText temperature one five dewpoint minus five altimeter two niner niner two nil) atis-mbrola.scm: done. (quit) The question arises, where to put these files: -- $FG_ROOT/Test/ (new directory) -- $FG_ROOT/Docs/ -- $FG_ROOT/Docs/test/ (new directory) -- $FG_ROOT/Sounds/ -- $FG_ROOT/Sounds/test/ (new directory) -- ... Wherever. I dont' care. I'm sure somebody has an opinion. == 1) Install festival. 2) Verify that festival is working: atis.scm festival You should hear the synthesized voice saying temperature one five dewpoint minus five altimeter two niner niner two. You should then see atis.scm: done. on your command window. 3) See whether the mbrola subsystem is installed: mbrola -h If not, install mbrola. Test whether festival can use mbrola: atis-mbrola.scm festival You should hear a different synthesized voice saying temperature one five dewpoint minus five altimeter two niner niner two. You should then see atis.scm: done. on your command window. 4) In one window, start festival in server mode: festival --server In another window, check that it is working: atis.scm netcat localhost 1314 You should hear the voice, and the response to your command should be something like: LP #Utterance 0x7f63dd07e710 ft_StUfF_keyOK LP atis.scm: done. ft_StUfF_keyOK ER You can also use the atis-mbrola.scm file for all such testing. 5) The procedure for getting FGFS and festival to work _together_ is known to be installation-dependent. If you feel lucky, try starting FGFS while the festival server is running, and see if you hear transmissions from the tower using the synthesized voice. (Note we are talking about messages from the tower, not ATIS, since ATIS presently uses a different -- non-festival -- synthesis method.) If this works, you can skip the rest of this section. One key requirement is that both FGFS and festival must be able to do audio output _at the same time_. The venerable /dev/dsp audio device does _not_ generally allow this. Some ALSA devices are OK. 5a) Before going any farther, it pays to check whether some _third party_ (neither FGFS nor festival) is using /dev/dsp. This is a problem, because the solution we are looking for depends indirectly on /dev/dsp. The diagram we want to have is: FGFS --\ ALSA plug:dmix --- /dev/dsp festival --/ which has multiple connections to the ALSA plug:dmix but only one direct connection to /dev/dsp. Any third party that makes a direct connection to /dev/dsp will cause failures. You can check what's going on via: lsof | grep /dev/dsp echo This is a problem. || echo OK, not using DSP. 5b) The following command may help detect whether festival is connecting to /dev/dsp: atis.scm festival sleep 1 ; lsof \ | grep /dev/dsp echo This is a problem. || echo OK, not using DSP. If it says something like [6] 9271 festival 9271me8w CHR 14,3 0t0 1215574 /dev/dsp This is a problem. then you need to reconfigure festival to use some other audio device. It may help to add the following lines to your ~/.festivalrc : (Parameter.set 'Audio_Command echo $FILE ; aplay --device=plug:dmix --quiet --file-type=wav $FILE ) (Parameter.set 'Audio_Method 'Audio_Command) (Parameter.set 'Audio_Required_Format 'riff) Any time you change this file, or change /etc/fesival.scm be sure to restart any festival servers. Re-test to make sure these settings solve the problem. Once you are sure this is working, consider moving the key settings from your personal ~/.festivalrc to the system-wide /etc/festival.scm file. An alternative to fixing the festival configuration files is to use the aoss wrapper, e.g.: aoss festival --server 5c) Similarly we need to check whether FGFS is using /dev/dsp. In one window, start FGFS. Once it gets to the point where you can hear sounds, go to another command window and: lsof | grep /dev/dsp echo This is a problem. || echo OK, not using DSP. If FGFS is using /dev/dsp, it may help to add the following lines to your ~/.alsoftrc format = AL_FORMAT_STEREO16 cf_level = 2 drivers = alsa [alsa] # ALSA backend stuff device = plug:dmix capture = plug:dsnoop Re-test to make sure. If that doesn't work, you may need to do something with your ~/.asoundrc file, but I don't know the correct incantation in that case. Also I don't know how, except by experimentation, how to ascertain whether .alsoftrc or .asoundrc is the
Re: [Flightgear-devel] festival ... or not
John Denker wrote: Let's try to understand the situation better, [...] According to my experience, the best choice to get a vast variety of audio applications play their stuff nicely along with each other on Linux is to use PulseAudio as a backend plus the respective frontend compatibility interfaces, if required. There's a nice guide on how to set things up at: http://www.pulseaudio.org/wiki/PerfectSetup Yet I have to admit that I've never ever been using 'festival' On Debian Lenny (aka. 5.0.x) they're linking 'festival' against 'libesd' - which is well supported by PulseAudio, therefore I _suspect_ it'll run out of the box. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] festival ... or not
Hi Guys, John Denker wrote in part: On 11/09/2009 02:37 PM, Anders Gidenstam wrote in part: 2. I don't remeber if I had to touch the festival config or not, but here it is: and...@sleipner:/etc$ cat /etc/festival.scm (Parameter.set 'Audio_Command aplay -D plug:dmix -q -c 1 -t raw -f s16 -r $SR $FILE) (Parameter.set 'Audio_Method 'Audio_Command) (Parameter.set 'Audio_Required_Format 'snd) That helps, too! It is not optional. Thanks. I may be missing something, but I haven't had any problems getting festival to work on Ubuntu, other than extracting the files in the correct place. I don't have a /etc/festival.scm file. Is this specific to some sound driver? I'm pretty much in the dark when it comes to Linux sound systems, so I honestly don't know what is different between my system and yours. Yes, that would be a good first step. We're talking about problems that show up on plain vanilla Debian systems, which are not exactly uncommon or weird. And probably show up on lots of other systems, too. Could you put together some text I could add to The Manual please? It would be particularly useful if it had some information to help the user identify whether they needed to make these changes or not. Thanks, -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] festival ... or not
On 11/11/2009 03:49 PM, Stuart Buchanan wrote: I may be missing something, but I haven't had any problems getting festival to work on Ubuntu, other than extracting the files in the correct place. I don't have a /etc/festival.scm file. Is this specific to some sound driver? I'm pretty much in the dark when it comes to Linux sound systems, so I honestly don't know what is different between my system and yours. I'm in the dark too. This is another of those collective learning experiences. I am currently entertaining a somewhat-vague hypothesis that it depends on kernel configuration as well as on details of the distribution. In particular I hypothesize that some of these progs (festival, FGFS) look for the oss driver first, and if they don't find it they look for alsa drivers. As a way to partially check these hypotheses, it would be helpful for folks where it just works to tell us the results of the following commands: # loaded modules: lsmod | grep oss # kernel configuration: grep OSS /boot/config-$(uname -r) # or whatever the corresponding thing is on your system I will get the ball rolling as follows: chez moi we have: lsmod | grep oss snd_pcm_oss37344 0 snd_mixer_oss 15936 1 snd_pcm_oss snd_pcm79624 3 snd_pcm_oss,snd_hda_intel,snd_hda_codec snd62904 11 snd_pcm_oss,snd_mixer_oss,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_pcm,snd_seq,snd_timer,snd_seq_device grep OSS /boot/config-$(uname -r) CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_CHR_DEV_OSST=m CONFIG_SSB_POSSIBLE=y CONFIG_SSB_PCIHOST_POSSIBLE=y CONFIG_SSB_PCMCIAHOST_POSSIBLE=y CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y CONFIG_SOUND_OSS_CORE=y CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y CONFIG_SOUND_OSS=m Could you put together some text I could add to The Manual please? a) I don't think we know enough quite yet. See above. b) Sound processing is not my area of expertise. Let's try to understand the situation better, then decide who is in the best position to write it up. It would be particularly useful if it had some information to help the user identify whether they needed to make these changes or not. Yes, that would be useful. I've been thinking along the same lines, but festival in particular doesn't make it easy to figure out what device(s) it is using. Maybe the path of least resistance is to provide explicit configuration files ... to make us less sensitive to the vagaries of the default behavior. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] festival ... or not
I'm launch festival as $ aoss festival --server And I advise you to use HTS voices - they a really small, only few megs each, but its quality same as hundreds-Mb CMU voices... You can get it here http://hts.sp.nitech.ac.jp/?Download -- --- WBR, Vadym. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] festival ... or not
On 11/09/2009 02:37 PM, Anders Gidenstam wrote in part: and...@sleipner:~$ cat ~/.alsoftrc format = AL_FORMAT_STEREO16 cf_level = 2 drivers = alsa [alsa] # ALSA backend stuff device = plug:dmix capture = plug:dsnoop That helps! Thanks. 2. I don't remeber if I had to touch the festival config or not, but here it is: and...@sleipner:/etc$ cat /etc/festival.scm (Parameter.set 'Audio_Command aplay -D plug:dmix -q -c 1 -t raw -f s16 -r $SR $FILE) (Parameter.set 'Audio_Method 'Audio_Command) (Parameter.set 'Audio_Required_Format 'snd) That helps, too! It is not optional. Thanks. 3. I set /sim/sound/voices/enabled to true in my ~/.fgfs/preferences.xml file (included via .fgfsrc). That part agrees with the documentation. Well, that you have not configured your sound system correctly isn't really FlightGear's fault, is it? I don't care who's fault it is. That's because I always look at things from the user's point of view. If the documentation says it just works, but in many cases it doesn't work, and there's no useful error message or even the slightest clue about how to make it work, that's a problem for the user, n'est-ce pas? Of course, the documentation could match your system better than it does, but Linux sound is pretty diverse and changes over time. The wiki might contain something about systems closer to yours. Yes, that would be a good first step. We're talking about problems that show up on plain vanilla Debian systems, which are not exactly uncommon or weird. And probably show up on lots of other systems, too. There opportunities for improvement in the code as well. It would be good programming practice for FGFS to use festival in such a way as to detect runtime errors -- including but not limited to failure to open the audio device -- and then to give explanatory messages to the user. The importance of these improvements is underlined by the fact that the user who uses the existing code and documentation can have working FGFS sound (except for festive voices) and also working festival (except for FGFS). In such a situation it is hard for the user to know what else needs to be done to get them to work together. === FWIW here is a simpler and more correct version of /etc/festival.scm ... Note that .snd format is not the same as .raw format, but riff format is the same as .wav format. (Parameter.set 'Audio_Command aplay --device=plug:dmix --quiet --file-type=wav $FILE ) (Parameter.set 'Audio_Method 'Audio_Command) (Parameter.set 'Audio_Required_Format 'riff) -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
