Hi all,
We recently decided to get a professionally recorded set of prompts for
our asterisk based IVRs and received these as the following:
Bit Rate: 1536Kbps
Sample Size: 16bit
Channels: Stereo
Sample Rate: 48kHz
Format: PCM
I use Wavepad to convert it to:
Bit Rate:64Kbps
Sample Size: 8bit
-ql; done
S.
-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Neeraj Chand
Sent: Monday, June 06, 2011 7:12 PM
To: asterisk-users@lists.digium.com
Subject: Re: [asterisk-users] Pops clicks at the end of sound
Un-top-posting...
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Neeraj
Chand Sent: Monday, June 06, 2011 7:12 PM
We recently decided to get a professionally recorded set of prompts for
our asterisk based IVRs and received these as the following:
[snip]
The problem I have
On Jun 6, 2011, at 10:51 PM, Steve Edwards asterisk@sedwards.com wrote:
Sox has a bunch of obtuse (IMNSHO) commands. There may be one that could
automagically trim the pop for you.
The argument is question is the trim command. If the OP wishes to find an
automagic method, they would
On Jun 6, 2011, at 10:51 PM, Steve Edwards asterisk@sedwards.com
wrote:
Sox has a bunch of obtuse (IMNSHO) commands. There may be one that
could automagically trim the pop for you.
On Mon, 6 Jun 2011, Sherwood McGowan wrote:
The argument is question is the trim command. If the OP wishes
Kevin P. Fleming wrote:
Matt Roth wrote:
We have no hardware timing device on the box (no Zap hardware) and
are using the 2.6 kernel as the timing source. Digium tech support
told us this is better than ztdummy, which we were using before. We
experienced the same problems then, as well.
Matt Roth wrote:
That advice about not loading ztdummy came from our paid support,
including the bit about Asterisk falling back to the kernel for timing
if no other source is available. It's concerning to me, to say the
least, that we are paying for misinformation. We are now running
Kevin P. Fleming wrote:
On 2.6 kernels, ztdummy can use either the kernel ticks (jiffies) for
timing, or the hardware realtime clock (RTC). By default it uses the
RTC when built against kernel headers for 2.6.13 or newer; it can be
manually configured to use the RTC for older kernels. The RTC
Matt Roth wrote:
We have no hardware timing device on the box (no Zap hardware) and are
using the 2.6 kernel as the timing source. Digium tech support told us
this is better than ztdummy, which we were using before. We experienced
the same problems then, as well. Could a lack of a hardware
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tuesday 19 August 2003 19:18, Michael Manousos wrote:
Could you provide some more details on the configuration
and your system setup?
Configuration of OpenH323 channel driver
-
Version: 0.5.5
Listening on
Hi Tais,
Could you provide some more details on the configuration
and your system setup?
Michael.
Tais M. Hansen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
Using inAccess Networks chan_oh323, I'm experiencing some clicks or pops, how
can I fix that?
- --
Regards,
Tais M. Hansen
I had a very similar problem with chan_oh323. I suspect that it was my
underpowered, overtaxed machine that was causing lost interrupts somewhere.
At the risk of starting another flamewar, you might want to try chan_h323
instead. It fixed the audio problems for me.
Your mileage may vary.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Monday 18 August 2003 16:29, Wade Weppler wrote:
I had a very similar problem with chan_oh323. I suspect that it was my
underpowered, overtaxed machine that was causing lost interrupts somewhere.
The system it's running on isn't doing anything
13 matches
Mail list logo
