Reply by sparafucile17●December 26, 20072007-12-26
>In a live audio streaming system, audio pops are caused by network
>packet delay. How to smooth the sharp decay, and what stuff should be
>filled in the empty buffer?
>
Are temporay mutes acceptable for your application? Sometimes you can
size them so that they are so small a human may not easily detect it.
For example keep a 100ms buffer between input and output and put a timer
on your input. Once you determine the input pack is late (you define
this) you can start appling a exponential mute (RC) to your outgoing
samples.
Since you have a 100ms in the pipe, you could adjust your rate so that it
is attentuated to -80dB (assuming a full-scale input) at around 50ms.
This time amount is key because anything less than ~30ms rate will be
preceived as a pop.
If the input packet comes back right after your mute is complete: you fill
the buffer back up and start your unmute process after the buffer is full
again. If you're lucky your packet delay is less than 50ms and the
amplitude will drop temporarily and go back up to unity and hardly anyone
will be able to distinguish that.
Worst case is a several-hundred-ms mute which is a little annoying but far
less discernable than a pop [my opinion].
Just an idea...
- Jeff
Reply by Jerry Avins●December 25, 20072007-12-25
Marcel Müller wrote:
> Hi,
>
> Jerry Avins schrieb:
>> Let the buffer get half full before you begin to empty it. If it
>> starts to fill up, empty it a bit faster. If it gets too empty, slow
>> the output down. A gradual change of a few percent will probably not
>> be noticed.
>
> I have to contradict. A few percent streching in the timeline /is/
> significantly audiable (one half-step is about 6%). You have to stay in
> a range of about +-1% (music a bit less, speech a bit more) to be
> non-audiable.
> But furthermore you won't get a significant amount of time by this
> method unless you have large buffer, what is not intended.
>
> However, introducing the derired latency from the beginnig is usually a
> good idea.
1% is about what I had in mind. That's about ten cents. Few people can
match pitch better than that. (1200 cents/octave.)
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply by Marcel Müller●December 25, 20072007-12-25
Hi,
Jerry Avins schrieb:
> Let the buffer get half full before you begin to empty it. If it starts
> to fill up, empty it a bit faster. If it gets too empty, slow the output
> down. A gradual change of a few percent will probably not be noticed.
I have to contradict. A few percent streching in the timeline /is/
significantly audiable (one half-step is about 6%). You have to stay in
a range of about +-1% (music a bit less, speech a bit more) to be
non-audiable.
But furthermore you won't get a significant amount of time by this
method unless you have large buffer, what is not intended.
However, introducing the derired latency from the beginnig is usually a
good idea.
Marcel
Reply by Ron N.●December 24, 20072007-12-24
On Dec 23, 8:22 pm, "Vladimir Vassilevsky"
<antispam_bo...@hotmail.com> wrote:
> "??" <iseelin...@gmail.com> wrote in message
>
> news:40d75fab-b655-4b84-87a2-318919e6a637@a35g2000prf.googlegroups.com...
>
> > In a live audio streaming system, audio pops are caused by network
> > packet delay. How to smooth the sharp decay, and what stuff should be
> > filled in the empty buffer?
>
> The common solution is replaying the last packet several times with the
> gradual decrease in the volume.
That would still allow a pop if the beginning and end of
the last packet have quite different amplitudes. If you
have a lot of extra processing capability, you could try
continuing the waveform forward using an LPC or phase vocoder
to essentially time stretch the last packet while doing
a gradual fade out. If that packet is already compressed
using some form of LPC or frequency domain encoding, then
your guesswork might already be partially accomplished.
But what if the audio contained in the last packet really
is some sort of "pop" sound?
IMHO. YMMV.
--
rhn A.T nicholson d.0.t C-o-M
Reply by Vladimir Vassilevsky●December 24, 20072007-12-24
"Jerry Avins" <jya@ieee.org> wrote in message
news:0JKdnSZfvPxBo_LanZ2dnUVZ_gCdnZ2d@rcn.net...
> Vladimir Vassilevsky wrote:
> > "??" <iseelinden@gmail.com> wrote in message
> >
> >> In a live audio streaming system, audio pops are caused by network
> >> packet delay. How to smooth the sharp decay, and what stuff should be
> >> filled in the empty buffer?
> >
> > The common solution is replaying the last packet several times with the
> > gradual decrease in the volume.
>
> Does that sound like a STUTT-TT-tt-tter?
>
Actually, the short replays sound like an echo in a metal pipe. There are
more sophisticated methods of extrapolation also (similar to what is used
for the pitch/speed shifting). The degradation is not very annoying till the
packet loss does not exceed 10% or so.
Vladimir Vassilevsky
DSP and Mixed Signal Consultant
www.abvolt.com
Reply by Jerry Avins●December 24, 20072007-12-24
Vladimir Vassilevsky wrote:
> "??" <iseelinden@gmail.com> wrote in message
> news:40d75fab-b655-4b84-87a2-318919e6a637@a35g2000prf.googlegroups.com...
>> In a live audio streaming system, audio pops are caused by network
>> packet delay. How to smooth the sharp decay, and what stuff should be
>> filled in the empty buffer?
>
> The common solution is replaying the last packet several times with the
> gradual decrease in the volume.
Does that sound like a STUTT-TT-tt-tter?
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
Reply by Jerry Avins●December 24, 20072007-12-24
何必 wrote:
> On Dec 24, 11:24 am, Jerry Avins <j...@ieee.org> wrote:
>> ?? wrote:
>>> In a live audio streaming system, audio pops are caused by network
>>> packet delay .
>> and other things
>>
>> How to smooth the sharp decay, and what stuff should be
>>
>>> filled in the empty buffer?
>> You should keep enough data on hand so there are no gaps.
>>
>> Jerry
>> --
>> Engineering is the art of making what you want from things you can get.
>
>> ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
>
> Well, that will cause longer delay, what can be done if I can't change
> the size of the buffer.
Let the buffer get half full before you begin to empty it. If it starts
to fill up, empty it a bit faster. If it gets too empty, slow the output
down. A gradual change of a few percent will probably not be noticed.
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply by Vladimir Vassilevsky●December 24, 20072007-12-24
"??" <iseelinden@gmail.com> wrote in message
news:40d75fab-b655-4b84-87a2-318919e6a637@a35g2000prf.googlegroups.com...
> In a live audio streaming system, audio pops are caused by network
> packet delay. How to smooth the sharp decay, and what stuff should be
> filled in the empty buffer?
The common solution is replaying the last packet several times with the
gradual decrease in the volume.
Vladimir Vassilevsky
DSP and Mixed Signal Consultant
www.abvolt.com
Reply by ●December 23, 20072007-12-23
On Dec 24, 11:24�am, Jerry Avins <j...@ieee.org> wrote:
> ?? wrote:
> > In a live audio streaming system, audio pops are caused by network
> > packet delay � � � � � � � �.
>
> � � � � � � � �and other things
>
> � � � � � � � � �How to smooth the sharp decay, and what stuff should be
>
> > filled in the empty buffer?
>
> You should keep enough data on hand so there are no gaps.
>
> Jerry
> --
> Engineering is the art of making what you want from things you can get.
Well, that will cause longer delay, what can be done if I can't change
the size of the buffer.
Reply by Jerry Avins●December 23, 20072007-12-23
?? wrote:
> In a live audio streaming system, audio pops are caused by network
> packet delay .
and other things
How to smooth the sharp decay, and what stuff should be
> filled in the empty buffer?
You should keep enough data on hand so there are no gaps.
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������