similar to: BUG report

Although I've never used ARM's compiler, I admit I'm very surprised that it's not compatible with the NEON intrinsics. Given that and M. Zanelli's speed tests, it seems clear that M. Zanelli's code is the way to go. I look forward to its inclusion in the opus GIT. --John On 6/10/2013 1:00 PM, opus-request at xiph.org wrote: > Date: Mon, 10 Jun 2013 10:36:34 +0100

I have to admit that I am impressed by your results -- making 1.1 look slower than 1.0 is by no means an easy task. On the other hand, it's a great tutorial on how not to use Opus, so for the benefit of everyone, this is a summary of what we learned in this exercise: 1) When running on ARM, the fixed-point build is usually faster than floating point. This is true on the majority of ARM archs

Cliff, Yes it would be good, but very hard to get a figure for the quality. At 6kbps I assume it does not bother trying to figure what mode to use as at that rate it can only use SILK. When I run some other bitrates it may get a bit slower trying to decide whether it is voice or music. I started with low bit rate because I am only really interested in Voice and very low bit rate. I think there

It might be good to use the (uncompressed) samples on the opus page, as a common starting point? http://www.opus-codec.org/examples/ On Dec 21, 2013, at 9:43 AMEST, Stuart Marsden wrote: > I have run a few more test at different bitrates and 1.1 is looking even worse in terms of speed compared to previous versions. > > I have shared a google sheet which has the raw data and charts for

Hello Opus, I?d like to report a bug in the fixed point OPUS code: line 336 (or thereabouts), operand FIND_LPC_COND_FAC should be replaced with SILK_FIX_CONST(FIND_LPC_COND_FAC ,32), otherwise multiplication by zero typically occurs. please confirm. Cliff -------------- next part -------------- An HTML attachment was scrubbed... URL:

I have run a few more test at different bitrates and 1.1 is looking even worse in terms of speed compared to previous versions. I have shared a google sheet which has the raw data and charts for 6,16 and 32 kbps. Unfortunately you cannot show proper error bars on Google sheets but the standard deviation is in the data if you want to look. You can see that the profile for 1.1 is a lot different

Hi All, What would be interesting would be a plot of complexity versus subjective or object audio quality. I've not had a chance to look at the new analysis code in 1.1 so maybe in the case of a 6kbps compression you could clarify what decisions would it be making that would justify the extra complexity? Best Regards Cliff Parris -----Original Message----- From: opus-request at

Yes, yes, I can reproduce it now, but only on platforms that define a 16-bit int by default (SA_Q15 is an opus_int rather than opus_int32). What system are you compiling this for? On Tue, Nov 21, 2017 at 8:34 PM, Chandrakala Madhira < chandrakala.madhira at soctronics.com> wrote: > Hi Logan, > > Please find attached the input stream we are using testing. > > Thank you, >

Hi, We are looking at the VAD implementation used in opus. We are looking at the code where speech probability is calculated based on which SNR is estimated. Below is the part of the code I am talking about. /*********************************/ /* Speech Probability Estimation */ /*********************************/ SA_Q15 = silk_sigm_Q15( silk_SMULWB( VAD_SNR_FACTOR_Q16, pSNR_dB_Q7 ) -

Hi Chandrakala, Logan, Can you confirm that the attached patch fixes the overflow problem? Koen, can you confirm the fix makes sense? Cheers, Jean-Marc On 11/27/2017 12:10 PM, Logan Stromberg wrote: > Sorry, long holiday weekend in America. > I can say with pretty high certainty that there is an overflow occurring > and it is flipping smooth_coef_Q16 to be negative when it probably

Hello OPUS, It appears to me that multi-frame packets are not supported by opus_demo.c (e.g. 30ms packest containing 3 10ms frames), can you confirm. However RF6716 does support such packets. Thanks Cliff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20131121/56bab79a/attachment.htm

Sorry, long holiday weekend in America. I can say with pretty high certainty that there is an overflow occurring and it is flipping smooth_coef_Q16 to be negative when it probably shouldn't be. I had originally thought it was only an issue where it was overflowing the 15th bit but not the 16th, which might still preserve the intended value for operations that ignore the sign bit (in cases

We have found that it is possible to achieve a 30 to 50% reduction in MHz requirement for implementation of OPUS on Cortex M4 compared to the public version (v1.3 beta/v1.2.1). For the CELT configuration you mention (complexity 0, 16kHz, mono, 20ms) we are measuring a 4ms encode time and a 3ms decode time for that platform (32kbit/s). An important issue that I haven't seen much discussion

Hi, Can anyone let me know if this is a bug? Thank you, Chandrakala ----- Original Message ----- From: "Logan Stromberg" <loganstromberg at gmail.com> To: "Chandrakala Madhira" <chandrakala.madhira at soctronics.com> Cc: opus at xiph.org Sent: Wednesday, November 22, 2017 12:12:39 PM Subject: Re: [opus] Reg an issue with smoothing factor in VAD

Hello All, We have been doing an optimised port of OPUS to a ARM Cortex A9. We are currently measuring between 20 and 90 MCPS for our code running on a Panda board (single core), this covers all bit-rates,sample rates for stereo coding (encode + decode) under normal operation. As Marc says complexity can be controlled via the API with our higher figure corresponding to the default setting of

Just for fun, I tried to reproduce such an overflow. I turned on all debug macros, assertions, and checked arithmetic and then encoded 2 hours of mixed speech/audio with these parameters: Sample rate = 48000 Channels = 1 Application = OPUS_APPLICATION_AUDIO Bitrate = 24 KB/s Force Mode = MODE_SILK_ONLY Signal Type = OPUS_SIGNAL_AUTO Complexity = 10 Frame size = 480 samples (10ms) No errors came

Hi All, Cortex-M4 is a single issue CPU whereas A8 is dual issue so this is the main reason you are seeing a slow-down, use of NEON I would say is secondary, certainly for CELT. We (ESPICO) have done optimisation work on OPUS v1.1 and have ARM implementations about twice the speed of the 'off the shelf' version. Please contact me directly if you want to discuss further. Cliff

I'm using the dovecot-stable from 7/30, authenticating against an OpenLDAP server. From time to time, dovecot stops responding to new queries. It seems to be a self-correcting problem, lasting about 20 minutes. Here's how it starts: Aug 18 19:38:23 cliff dovecot: imap-login: Disconnected: Inactivity [150.253.42.12] Aug 18 19:38:36 cliff dovecot: pop3-login: Disconnected: Inactivity

Hi Jean-Marc, The original celt_fir() is a little bit messy. It has 2 branches chosen by #ifdef SMALL_FOOTPRINT. For floating-point, the 2 branches are identical (except the operation sequence of accumulating x[i] to sum, which is not a big deal). For fixed-point, the 2 branches are different. I separate them into 2 functions: the new celt_fir(), and celt_fir_permit_overflow() which is the

Hi It pretty works for 16 bits samples but not for 24 bits samples. In fact, I am going to implement opus on ADSP-21489 (DSP processor from Analog Devices), I compiled "celt directory" from opus 1.1 and used "opus_custom_demo.c". It hasn't any problem with 16 bits samples but when I use 24 bits samples , there is no output audio. opus_decoder will still generate 16 bits