search for: espico

.... 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 > From: Cliff Parris<cliff at espico.com> > Subject: Re: [opus] opus Digest, Vol 53, Issue 2 > To:<opus at xiph.org> > Message-ID: <A01D0618A28F4E51B5FE299E9394F171 at EspicoPC> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=original > > Hi All, > > Re...

...gt; > Stuart Marsden > > Tactical Communications Consultant > FinMars Consulting Ltd > UK: +441865589833 <tel:%2B441865589833> > Finland: +358453046287 <tel:%2B358453046287> > > > On 20 December 2013 17:20, Cliff Parris <cliff at espico.co.uk > <mailto:cliff at espico.co.uk>> wrote: > > 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 a...

...may be equivalent. So it is just something to be aware of. > > Best Regards, > > Stuart Marsden > > Tactical Communications Consultant > FinMars Consulting Ltd > UK: +441865589833 > Finland: +358453046287 > > > On 20 December 2013 17:20, Cliff Parris <cliff at espico.co.uk> wrote: > >> 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...

...complexity 10 with new complexity 5 which I understand may be equivalent. So it is just something to be aware of. Best Regards, Stuart Marsden Tactical Communications Consultant FinMars Consulting Ltd UK: +441865589833 Finland: +358453046287 On 20 December 2013 17:20, Cliff Parris <cliff at espico.co.uk> wrote: > 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 d...

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

...e equivalent. So it is just something to be aware of. > > Best Regards, > > Stuart Marsden > > Tactical Communications Consultant > FinMars Consulting Ltd > UK: +441865589833 > Finland: +358453046287 > > > On 20 December 2013 17:20, Cliff Parris <cliff at espico.co.uk> wrote: > 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 decis...

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 -----Original Message----- From: opus-request at xiph.org Sent: Thursday, November 06, 2014 8:00 P...

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:

Hi OPUS, The macro Silk_LSHIFT_SAT32( ) doesn?t generate the correct saturated 32 bit results, at least in some cases e.g: Silk_LSHIFT_SAT32( 0x4000, 17) = 0x7ffe000; Cliff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20130610/be3f808f/attachment.htm

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

Hello Opus, Just picked up the 1.1 release, build using VS2010 express using the prject files provided and found that the opus_demo application project was null. When I added opus_demo.c back I found it didn?t correctly work (v bad audio) at least for my test case of mono WB speech at 24kbps. Would you expect it to work ? Thanks Cliff -------------- next part -------------- An HTML attachment

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 All, Regarding cycle measurements for ARM/NEON, ARM no longer provide cycle accurate simulators. The method we use is to to make measurements on hardware via the PMU unit on the core itself. Note that if your running under Linux you may be 'allowed' to access the PMU directly but can access via it system calls. Typically you will need to make a series of measurements and average them.

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