search for: 120ms

...\ match ip src 10.10.10.1 \ match ip dst 10.10.10.10 \ flowid 1:2 tc qdisc add dev eth0 parent 1:2 handle 2: sfq perturb 10 Small pings are ok - <10ms, here is output for 65500 byte pings: Pinging test [10.10.10.1] with 65500 bytes of data: Reply from 10.10.10.1: bytes=65500 time=120ms TTL=64 Reply from 10.10.10.1: bytes=65500 time=120ms TTL=64 Reply from 10.10.10.1: bytes=65500 time=120ms TTL=64 Reply from 10.10.10.1: bytes=65500 time=120ms TTL=64 Ping statistics for 10.10.10.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-secon...

Thanks Jean-Marc and Benjamin for the answers. One follow-up question. If I use a repacketizer as Jean-Marc suggested by combining two 60ms frames to form a 120ms frame, without extracting individual frames and using a new TOC, I would need to have a "de-packetizer" that does the exact opposite of repacketizer. De-packetizer would need to separate this 120ms frame into two 60ms frames and feed them individually to the decoder. In other words, the...

Hi Jean-Marc, A simpler question. How does opus_encode() generate packets of 20ms (SILK-only or Hybrid)? Concatenating two 10ms frames or doing it straight with just one 20ms frame?

...e libopus encoder's opus_encode() method is documented as "Encodes an Opus frame". Does that mean that it always produces a single Opus frame (i.e. the number of frames in the TOC byte will always be 0)? It's not clear from the documentation, but the fact that it cannot produce a 120ms Opus packet makes me wonder if that was the intention and any multi-frame Opus packets must formed outside the libopus encoder (e.g. the Repacketizer). If that's not the case and opus_encode() can produce multi-frame Opus packets, why is it limited to 60ms Opus packets? Kevin O'Connor Int...

...n-Marc > Regards, > > Chris -----Original Message----- From: opus-bounces at xiph.org > [mailto:opus-bounces at xiph.org] On Behalf Of Jean-Marc Valin Sent: > Friday, October 25, 2013 7:19 AM To: O'Connor, Kevin; opus at xiph.org > Subject: Re: [opus] libopus API question - 120ms encoding > > The general ideao of opus_encode() is indeed to encode a single > frame. However, there is an exception for 40 and 60 ms because only > one mode (SILK-only) has this frame size. The original code would > automatically force SILK-only mode on 40 and 60 ms, but that was &...

Is there a reason why opus_repacketier_cat is limited to 120ms packets? It seems 120ms frames can only be combination frames, that is, only constructed by combining smaller frames of the same config. If this is true, then why stop at 120ms and not support longer packets? Regards, -- Daniel. -------------- next part -------------- An HTML attachment was scrub...

On Fri, Dec 19, 2014 at 9:03 PM, Timothy B. Terriberry <tterribe at xiph.org> wrote: > Daniel K wrote: >> true, then why stop at 120ms and not support longer packets? > > https://tools.ietf.org/html/rfc6716#section-3.2.5 > > "...the audio duration contained within a packet MUST NOT exceed 120 ms..." If you're wondering why the limit exists, there are a number of reasons... e.g. the overhead is already n...

...e that I have a great deal of files in my 'netlogon' directory which is why the problem is so apparent for me. sysvolreset takes approx 5+ minutes to complete. Tracing out samba-tool shows that the slowdown is caused by the samba function 'set_nt_acl'. This function takes approx 120ms to run, which when multiplied up by a few thousand files (2,000 in my case) you very quickly end up in minutes. running samba-tool using cProfile ('python2.7 -m cProfile /usr/bin/samba-tool ntacl sysvolreset') gives the following results: http://pastebin.com/98rYXRxe As you can see the...

Hi,all I have tested AEC on files, it works well.I have some files,one is echo file, others are echo-added files(an origin file adding echo at different delay,such as 20ms,40ms...120ms,140ms).AEC do wonderfully on those files except echo added at 140ms-delay. But ,when i use AEC in my voip project, it does feebly. Who can give me some hints why caused this.How long can sound be picked up by mic after it plays out.This is the main problem to align echo.Give me a hint. Best rega...

Hi Felicia, A few comments: > - /* CELT can only support up to 20 ms */ > subframe_size = st->Fs/50; > - nb_subframes = frame_size > st->Fs/25 ? 3 : 2; > + nb_subframes = frame_size/subframe_size; This will use six 20ms frames to make a 120ms packet, even for SILK-only mode where frames can be up to 60ms. For SILK, two 60ms frames would be a more efficient way to encode a 120ms packet. Also FEC, if enabled, would be 3 times as effective. Similarly, two 40ms SILK frames would be more efficient than four 20ms SILK frames. - /* Can...

...VoIP can tolerate a fair amount of latency; latency over about 100ms is heard as a perceptible delay resulting in a connection that appears to be half duplex. Jitter, on the other had, is the real enemy. Jitter is the variation in packet timing, for example, packet A arrives in 80ms, packet B in 120ms, and packet C in 70ms. The jitter for this scenario would be 120ms-70ms = 50ms. Of course the jitter time is only half of the story, the number of packets that are "outliers" in the RTP stream will also have an impact. Typical jitter measurements are stated as "average jitter" w...

Anyone notices that using sfq qdisc adds latency compared to pfifo? With "sfq perturb 10" ping latency is around 100-120ms, while with "pfifo limit 3" drops to ~10-30ms (qdiscs belong to htb class). I''m missing something or is this expected? { $TC_CLASS parent 1:1 classid 1:20 htb prio 0 rate 900kbit ceil 1000kbit burst 7k $TC_QDISC parent 1:20 handle 200: {pfifo limit 3} | {sfq perturb 10} } ___...

...count code "c" set to 1. Regards, Chris -----Original Message----- From: opus-bounces at xiph.org [mailto:opus-bounces at xiph.org] On Behalf Of Jea= n-Marc Valin Sent: Friday, October 25, 2013 7:19 AM To: O'Connor, Kevin; opus at xiph.org Subject: Re: [opus] libopus API question - 120ms encoding The general ideao of opus_encode() is indeed to encode a single frame. However, there is an exception for 40 and 60 ms because only one mode (SILK-only) has this frame size. The original code would automatically forc= e SILK-only mode on 40 and 60 ms, but that was suboptimal for mode swit...

...s using an echo tail length of 100ms and frame size of 20ms. Using this setting, I found that the echo cancellation does work, but it is too aggressive and cause the actual voice to get attentuation as well, resulting in audio distortion that sounds like audio drop. Increase the echo tail length to 120ms made the voice attentuation issue less severe, but resulted in much of the echo remaining in the audio. Does anyone have any advise on what I can look at and what parameters I can tweak to try to improve the Speex Echo Cancellation performance? I already using 1.2rc1. Thanks. regards, KS --20c...

...recevied so the AEC is always performed on raw PCM16 8KHZ ? 2) The audio is moved in 32ms (512 byte) chunks and the reading and writing to the AEC code will be done by separate threads at regular 32 ms intervals. 3) Occasionaly audio is dropped if it has become delayed but a jitter buffer of 120ms is in use. People at different distances from the server will have a slightly different round trip time. Do you think if using a large tail or something we can get near perfect AEC? The same as you get with a hands free phone perhaps? Does it still sound like worth a try? Is Speex AEC as...

...gt; - /* CELT can only support up to 20 ms */ >> > subframe_size = st->Fs/50; >> > - nb_subframes = frame_size > st->Fs/25 ? 3 : 2; >> > + nb_subframes = frame_size/subframe_size; >> >> This will use six 20ms frames to make a 120ms packet, even for >> SILK-only mode where frames can be up to 60ms. For SILK, two 60ms >> frames would be a more efficient way to encode a 120ms packet. Also >> FEC, if enabled, would be 3 times as effective. Similarly, two 40ms >> SILK frames would be more efficient than...

Hi,

...ms */ > >>> > subframe_size = st->Fs/50; > >>> > - nb_subframes = frame_size > st->Fs/25 ? 3 : 2; > >>> > + nb_subframes = frame_size/subframe_size; > >>> > >>> This will use six 20ms frames to make a 120ms packet, even for > >>> SILK-only mode where frames can be up to 60ms. For SILK, two 60ms > >>> frames would be a more efficient way to encode a 120ms packet. Also > >>> FEC, if enabled, would be 3 times as effective. Similarly, two 40ms > >>> SILK...

...s moved in 32ms (512 byte) chunks and the reading and > writing to the AEC code will be done by separate threads at regular > 32 ms intervals. You're free to do the processing/blocking as you like. > 3) Occasionaly audio is dropped if it has become delayed but a jitter > buffer of 120ms is in use. That'll cause problems. > People at different distances from the server will have a slightly > different round trip time. Do you think if using a large tail or > something we can get near perfect AEC? The same as you get with a > hands free phone perhaps? No. You may h...

...omments: > > > - /* CELT can only support up to 20 ms */ > > subframe_size = st->Fs/50; > > - nb_subframes = frame_size > st->Fs/25 ? 3 : 2; > > + nb_subframes = frame_size/subframe_size; > > This will use six 20ms frames to make a 120ms packet, even for > SILK-only mode where frames can be up to 60ms. For SILK, two 60ms > frames would be a more efficient way to encode a 120ms packet. Also > FEC, if enabled, would be 3 times as effective. Similarly, two 40ms > SILK frames would be more efficient than four 20ms SILK f...