[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Search]
Re: IBM ViaVoice and Alsa
- To: listaddr1@xxxxxxxxxxx
- Subject: Re: IBM ViaVoice and Alsa
- From: "T. V. Raman" <raman@xxxxxxxxxxx>
- Date: Sun, 7 May 2006 09:16:40 -0700
- Delivered-To: priestdo@xxxxxxxxxxx
- Delivered-To: emacspeak@xxxxxxxxxxx
- In-Reply-To: <17501.46887.178518.666721@xxxxxxxxxxx>
- List-Help: <mailto:emacspeak-request@xxxxxxxxxxx?subject=help>
- List-Post: <mailto:emacspeak@xxxxxxxxxxx>
- List-Subscribe: <mailto:emacspeak-request@xxxxxxxxxxx?subject=subscribe>
- List-Unsubscribe: <mailto:emacspeak-request@xxxxxxxxxxx?subject=unsubscribe>
- Old-Return-Path: <tvraman@xxxxxxxxxxx>
- Reply-To: raman@xxxxxxxxxxx
- Resent-Date: Sun, 7 May 2006 12:26:43 -0400 (EDT)
- Resent-From: emacspeak@xxxxxxxxxxx
- Resent-Message-ID: <P8Vfu.A.So.D_hXEB@xxxxxxxxxxx>
- Resent-Sender: emacspeak-request@xxxxxxxxxxx
On the viavoice/alsa side, everything is under our control, as
opposed to the OSS side.
Note that independent of whether the bug is in the ALSA layer or
the ViaVoice layer, the only thing preventing its fixing is the
sparse ALSA documentation.
On my work desktop and laptop for instance, I can use ViaVoice
and mplayer simultaneously --- no problems. On my home machine I
can use a bunch of audio programs simultaneously -- but not
Viavoice with them.
Look at the buffer size numbers in atcleci -- and also run aplay
with the -v flag to get a sense of the various numbers and
settings involved.
>>>>> "Lukas" == Lukas Loehrer <listaddr1@xxxxxxxxxxx> writes:
Lukas> This does not really solve Tim's problems but is more
Lukas> like a report of my own findings with viavoice and
Lukas> alsa.
Lukas>
Lukas> Theoretically, you should no longer need a .asoundrc
Lukas> file with current alsa versions as dmix is used by
Lukas> default. When I was working on alsa support for
Lukas> eflite, I found that alsa can behave quite differently
Lukas> on different machines. Also, I found that there can be
Lukas> very annoying interaction between different processes
Lukas> that all use the sound device quasi simultaniously,
Lukas> e.g. killing one process will kill unrelated others
Lukas> too only because they are also happend to use sound,
Lukas> or one process can sometimes corrupt the sound device
Lukas> in such a way that others will also sound strangely.
Lukas>
Lukas> As for viavoice with alsa, I have also observed the
Lukas> problem you describe where at the end of the
Lukas> utterence, it seems that It wants to talk a bit
Lukas> more. On one of my machines, it actually repeats that
Lukas> last sound indefinitely. On another machine, this
Lukas> probelm is fixed perfectly with the right .asoundrc
Lukas> file, so it can indeed make a huge difference to get
Lukas> those settings correct.
Lukas>
Lukas> I believe that most instability issues with viavoice
Lukas> are due to viavoice itself and do not stem from the
Lukas> alsa interface. However, I have identified 2 sound
Lukas> issues of which I have only fixed one so far:
Lukas>
Lukas> The funtion alsa_reset does not close the sound device
Lukas> but just opens a new one. This will most likely cause
Lukas> a resource leak. I changed the funtion to:
Lukas>
Lukas> void alsa_reset () { snd_pcm_drop (AHandle);
Lukas> snd_pcm_prepare(AHandle); }
Lukas>
Lukas> In this way, the same handle is reused.
Lukas>
Lukas> The second problem is more compicated. When there is
Lukas> no more speech, the sound device goes into xrun state,
Lukas> which should not be a problem but is apparently not
Lukas> handled well by all drivers and I suppose it causes
Lukas> the strange sounds at the end of some utterences. To
Lukas> fix this, one would have to call snd_pcm_drain() at
Lukas> the point where no more sound data is available. I
Lukas> have not yet had time to find a good way to achieve
Lukas> this. Also, there seem to be some issues with this
Lukas> function on some machines, i.e. it sometimes blocks
Lukas> indefinitely. The solution I am considering would add
Lukas> a eci-mark after the last utterence before a "d"
Lukas> command and thus the callback function would be called
Lukas> again after the last utternce of that block has been
Lukas> sent to the sound device and we could call
Lukas> snd_pcm_drain from there.
Lukas>
Lukas> About sluggishness, I think it mainly shows at low
Lukas> speech rates with certain special characters. For
Lukas> example, set the speech rate to 50 and it "[" quickley
Lukas> a few times. Now do the same thing with "w". It seems
Lukas> that with "w", succeeding utternces cancel previous
Lukas> ones, wile with "[" this is not the case.
Lukas>
Lukas> Anyway, those were just some of my observations. I
Lukas> hope I will find time soon to thry to implement the
Lukas> xrun-fix. If anyone has any ideas on how to do this
Lukas> cleverly, I would be very interested to hear it.
Lukas>
Lukas> Best regards, Lukas
Lukas>
Lukas> Tim Cross writes ("IBM ViaVoice and Alsa"):
>> I've just had an interesting experience which may help
>> others and answer some of the questions regarding issues
>> which have come up concerning ViaVoice.
>>
>> I'm running Debian testing and on the weekend did an
>> upgrade which included an upgrade to the Alsa utilities
>> and Debian's sound-core package. There was no kernel
>> upgrade. I'm running kernel 2.6.15
>>
>> After the upgrade, I found ViaVoice was not operating
>> correctly. In fact, it was now speaking with a distinct
>> stutter and sounded like it was trying to say everything
>> twice.
>>
>> I removed the .asoundrc file I had (which was pretty much
>> the same as the example Raman provides). This pretty much
>> solved the problem, except at the end of speaking a chunk
>> of text, there was an irritating "blah" sort of sound -
>> like a bit of text being cut off before it could complete
>> speaking.
>>
>> I then decided to try the OSS version of the driver rather
>> than the alsa version. This doesn't have any stuttering or
>> repeated text and no cut off bit of repeated text at the
>> end of text blocks. However, when typing, it is *a lot
>> more sluggish* than when using the alsa driver. However,
>> the driver itself is a lot more stable. The current alsa
>> driver dies on me quite a bit, but he OSS version rarely
>> dies - its just sluggish when typing and a bit less
>> responsive with respect to interruption of speech.
>>
>> I suspect the problem with the alsa version of the driver
>> is that I need to tweak my .asoundrc settings. So, its
>> probably time to go to the alsa web site and start to
>> learn how to use the .asoundrc file. A brief scan of this
>> gives me the impression this could take a bit of learning
>> - it seems to be quite complex/large. Not sure when I will
>> get to it.
>>
>> If anyone has a good working version of a .asoundrc file
>> for a system running a SoundBlaster Live card, I'd
>> appreciate a copy to see if it works better than the very
>> basic one I have.
>>
>> At any rate, this would seem to provide some clues as to
>> why some users have reported that ViaVoice is sluggish and
>> doesn't keep up when typing i.e. is likely due to usiing
>> the Alsa OSS emulation layer rather than native Alsa
>> support. Also, it would seem the settings in your
>> .asoundrc file may affect how well the native alsa version
>> works.
>>
>> Tim
Lukas>
Lukas> -----------------------------------------------------------------------------
Lukas> To unsubscribe from the emacspeak list or change your
Lukas> address on the emacspeak list send mail to
Lukas> "emacspeak-request@xxxxxxxxxxx" with a subject of
Lukas> "unsubscribe" or "help"
--
Best Regards,
--raman
Email: raman@xxxxxxxxxxx
WWW: http://emacspeak.sf.net/raman/
AIM: emacspeak GTalk: tv.raman.tv@xxxxxxxxxxx
PGP: http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman
IRC: irc://irc.freenode.net/#emacs
-----------------------------------------------------------------------------
To unsubscribe from the emacspeak list or change your address on the
emacspeak list send mail to "emacspeak-request@xxxxxxxxxxx" with a
subject of "unsubscribe" or "help"
Emacspeak Files |
Subscribe |
Unsubscribe | Search