similar to: Benchmarks on Pi

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

I wanted to roughly benchmark how the different version of libopus performed at each complexity level for a 6kbit/s output opus file. This was conducted on a Raspberry Pi so it is a constant hardware platform. This was done on an early Pi so only 256MB RAM but it was never used up so should not make a difference. I compiled the three final versions of each major release of libopus so that was

Christian, I will give 64kbit/s a try and post the figures. My own project is voice only and requires low bitrate so was hoping that it was just the way I was compiling and not an actual regression in speed for SILK. The raspberry PI is quite a cheap and handy reference platform though the ARM side is fairly underpowered but has a great GPU. It also has no audio in which is a pain for playing

I have just started trying Opus with a view to using it in a project. I am interested in embedded hardware and tried it on the Raspberry Pi using the raspbian distro. The version of libopus in the repos is 0.9.14. I installed this and tried encoding 2 minutes of speech from a librevox recording. It managed this at a respectable pace for complexity 10: Skipping chunk of type "LIST",

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

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

Resampling to 48khz speeds them both up but the disparity is about the same: 2.609 to 3.69. Best Regards, Stuart Marsden On 17 December 2013 17:04, Stuart Marsden <stuartmarsden at finmars.co.uk>wrote: > Christian, > > Complexity 0, 6kbps: > > 0.9.14 Speed 5.204 > 1.1 Speed 5.218 > > A slight win on that run but they vary enough to say about the same. At >

On Mon, Dec 16, 2013 at 5:03 AM, Stuart Marsden <stuartmarsden at finmars.co.uk> wrote: > I have just started trying Opus with a view to using it in a project. I am > interested in embedded hardware and tried it on the Raspberry Pi using the > raspbian distro. > > The version of libopus in the repos is 0.9.14. I installed this and tried > encoding 2 minutes of speech from a

Hi Stuart, you are compressing it at 6kbit/s. Then, then SILK mode is probability used and the Silk mode is much faster than CELT. Do you also some figures at 64kbit/s? It is strange that Opus 1.1 got slower in the Silk mode - may the speech/voice selection adds some overhead. I would be interested in seeing the performance of the 64 kbit/s in both Opus 1.0 and Opus 1.1. With best

I thought I would run the same benchmarks on my PC that I have been running on my Pi. This is a very different beast as it is a i7-4770 with 4 cores (8 with hyperthreading) and 16GB RAM. This is a bit academic as any x86 PC in the last 10 years can encode very quickly and unless you are converting a huge catalogue you will not notice a small change in speed. That being said I wanted to see if

Hi I'm having a problem compiling opus-tools-0.1.7. Version opus-tools-0.1.6 seems to compile OK. I've tried with opus-1.0.3 and opus-1.1-beta. The errors are like this:- "undefined reference to `sqrtf'" etc. This OS is Peppermint Three, similar to Ubuntu 12.04. It uses:- gcc --version gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 Google says it's maybe something to do

Hi, I have found differences in quality between opus_demo and opusenc/opusdec. I used for both applications the same raw pcm file,16 bit,48khz,litle endian. i use libopus 1.1-beta and opus-tools-0.1.7. The command for opus_demo is: opus_demo audio 48000 1 64000 -cvbr -framesize 10 in.pcm out.pcm For opusenc/dec: opusenc --raw --raw-chan 1 bitrate 64 -cvbr --framesize 10 in.pcm in.opus

Hi all, I am a developer for embedded system and totally new to Opus and open source audio codec. I'm now using Microchip dsPIC33 to develop a decoder for Opus. I am now using sources of libopus. The first question is for calling opus_decode(), do I need to skip the header bytes of an opus file before I can input the file data to opus_decode()? Or will libopus handle this automatically?

Hello all, Sorry for the delay (got really sick last week). Attached are updated patches for libopus, libopusenc, opusfile and opus-tools. Note that the patches for libopusenc, opusfile and opus-tools are dependent on the patch for libopus. Please let me know if you have any additional followup comments or questions. Cheers, Drew -------------- next part -------------- An HTML attachment was

Hi Drew, I think the libopusenc patch is better, but there's still a few issues left: 1) The static MAX_PACKET_BUFFER_SIZE value is still problematic because if you link libopusenc with a new version of libopus that supports higher order projection or just more projection channels for order 3, then you will overflow the buffer. I think what you'd want is a _ope_opus_header_get_size() call

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?

OK, so at the link : https://uloz.to/!yyVrCY2Y8sn1/devil-s-elbow-opus-7z (https://uloz.to/%21yyVrCY2Y8sn1/devil-s-elbow-opus-7z) (change the language to English by clicking at the flag at the right upper side of the web page or just simply click at "Stáhnout pomalu" - it may take some time as the file is 55 MB+ and the download service is free) there is 7zip archive with 5 music

Move demixing matrix defines to opus_define to better determine availability of Projection API. Allows libopusenc, opusfile and opus-tools to much more easily determine availability of Projection API. Cheers, Drew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20180307/110f7aaf/attachment.html>

Attached is an updated patch based on Jean-Marc and Mark's comments. :) Cheers, Drew On Tue, Mar 20, 2018 at 9:20 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > On 03/20/2018 11:51 AM, Drew Allen wrote: > > Just to confirm, I would use opeint_* for all the > > OpusGenericEncoder-related functions? > > Correct. Or you can also use oge_ if you like. Just