[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Search]
viavoice running smoothly (was Re: Error: Could not load libibmeci.so)
- To: emacspeak@xxxxxxxxxxx
- Subject: viavoice running smoothly (was Re: Error: Could not load libibmeci.so)
- From: "Robert D. Crawford" <rdc1x@xxxxxxxxxxx>
- Date: Sun, 28 May 2006 07:16:37 -0500
- Delivered-To: priestdo@xxxxxxxxxxx
- Delivered-To: emacspeak@xxxxxxxxxxx
- In-Reply-To: <17528.35713.307887.664431@xxxxxxxxxxx> (Lukas Loehrer'smessage of "Sat, 27 May 2006 19:25:21 +0200")
- 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: <rdc1x@xxxxxxxxxxx>
- Resent-Date: Sun, 28 May 2006 08:16:54 -0400 (EDT)
- Resent-From: emacspeak@xxxxxxxxxxx
- Resent-Message-ID: <9HRgXB.A.RVD.2SZeEB@xxxxxxxxxxx>
- Resent-Sender: emacspeak-request@xxxxxxxxxxx
- User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.4 (gnu/linux)
Lukas Loehrer <listaddr1@xxxxxxxxxxx> writes:
> first the easy stuff. If the beep tool from the beep package does no
> longer work, One way to restore the beep is to use the beep script
Thanks. The script did the trick.
Concerning the viavoice, it is now running very well. In probably what
amounts to 6 or 7 hours of use over the last day, I have had only one
crash and no echo problems. To test the issue of overlap after
something else accesses the sound device, I went to the sounds directory
and did
aplay *.wav
and am suffering no ill effects.
> Anyway, what you have to do is choose a buffer size that is small, I
> would say at most 100ms. Mine is 4096 frames. Add some printfs to
> atcleci.cpp to see what sizes for buffer_size and chunk_size are used.
Since I do not know anything about c++, I took the trial and error
approach. I started with the value you mentioned above and initially
decremented it by 256. Things progressively got worse doing this, so I
started incrementing the value by 1024 until I got a value that worked
for me. I did the same for the period size and the period time. Here
are the values I was left with:
pcm.dmixer {
type dmix
ipc_key 1024
slave {
pcm "hw:0,0"
format s16_LE
period_time 0
period_size 512
buffer_size 8192
rate 44100
I left a bit of context for anyone reading this in the future. Note
that the value of period time is still 0. I am not sure what this
variable is for, but changing it did bad things.
Here is the output of aplay -l | head 1
card 0: I82801DBICH4 [Intel 82801DB-ICH4], device 0: Intel ICH [Intel
82801DB-ICH4]
BTW, the aplay on my system does not give the card id in the first line
of output, and the head command requires a dash before the argument.
> Note that when testing different settings in the .asoundrc file, the
> changes only take effect after all processes have closed the sound
> device.
This was the case for me as well.
A question that might not be able to be answered is whether or not this
is an issue that can be solved in the atcleci.cpp file. While this
tweaking is not such a big deal for knowledgeable users, and only a
little bit of a problem for users like me who will plunge head-first
into the water without knowing how deep it is, there is a whole class of
users that will not take the time to mess around with the settings.
This issue will also be a problem with projects like Oralux where it
will be impossible to adjust the settings.
Just some thoughts. Thanks to everyone that helped see me through to
resolution.
rdc
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Robert D. Crawford rdc1x@xxxxxxxxxxx
-----------------------------------------------------------------------------
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