Skip to main content

Topic: IETF Opus codec now ready for testing (Read 233033 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • m45t3r
  • [*]
IETF Opus codec now ready for testing
Reply #400
Just started a page about Opus on Wiki: http://wiki.hydrogenaudio.org/index.php?title=Opus

It's still pretty rough but I will try to add more content as I learn how to edit MediaWiki.

  • sluggy
  • [*][*]
IETF Opus codec now ready for testing
Reply #401
CDBurnerXP has just added opus support for burning audio cds, which is great news 

  • saratoga
  • [*][*][*][*][*]
IETF Opus codec now ready for testing
Reply #402
how does Rockbox resample from Opus' 48kHz to its own 44.1?


Using the normal crappy linear resampler.  Integrating a better one is on my todo list.  Probably borrow the neat looking one from speex if i ever get around to it.

  • jensend
  • [*][*][*]
IETF Opus codec now ready for testing
Reply #403
how does Rockbox resample from Opus' 48kHz to its own 44.1?
Left in the middle of writing this and when I'd come back Saratoga had beaten me to it- Rockbox's built-in resampler uses linear interpolation. While this does mean that it's fast and has practically zero impact on battery life, it definitely has an impact on sound quality. Could be worse (zero-order-hold), and the problems may not be audible in many portable listening settings (esp. since an Opus file will have no frequency content above 20kHz), but there are much better resamplers that aren't that much slower. (Take a look at what SRC Comparisons has to say about the Xiph "Speex resampler," which is also used in opus-tools, versus a linear resampler.)

On most of the devices Rockbox supports, the hardware could natively play back sounds at all realistic/real-world rates. But the switching the hardware's output rate whenever a new sound played would be extremely onerous to code and support across all those devices. They chose to stick with the most common music rate and resample everything else to keep things simple.

(Rockbox devs seem short-staffed as it is, given all the different hardware they're trying to support. Their current release is being held up because they're encountering difficult-to-diagnose bugs with some devices' USB support, for instance.)

In IRC, one Rockbox dev (I forget who) mentioned that it would be fairly easy to build 48k-native versions of Rockbox if there were demand for them. For people who plan to go opus-only with their collection, this might be the best route.

  • lvqcl
  • [*][*][*][*][*]
  • Developer
IETF Opus codec now ready for testing
Reply #404
Probably borrow the neat looking one from speex if i ever get around to it.
the Xiph "Speex resampler," which is also used in opus-tools

Yeah, I already noticed that opus-tools uses slightly modified Speex resampling algorithm.

Take a look at what SRC Comparisons has to say about the Xiph "Speex resampler,"

I can see only the results of Speex@Quality 10 there, but probably this setting is too CPU-intensive for portable devices... However, the Speex manual states that even "quality 0 usually has a decent sound (certainly better than using linear interpolation resampling)". And this algorithm already has fixed-point version.

  • saratoga
  • [*][*][*][*][*]
IETF Opus codec now ready for testing
Reply #405
I can see only the results of Speex@Quality 10 there, but probably this setting is too CPU-intensive for portable devices... However, the Speex manual states that even "quality 0 usually has a decent sound (certainly better than using linear interpolation resampling)". And this algorithm already has fixed-point version.


Yeah I was thinking Q1 for most devices, and maybe Q4 for highend hardware.  That resampler looks a little painful, and there is no asm so gcc will likely make a mess of it.

I still wonder how that would compare to something like 2x oversampled cubic hermite though.  That can be done really efficiently, and should give pretty good results.

  • maikmerten
  • [*][*][*]
IETF Opus codec now ready for testing
Reply #406
how does Rockbox resample from Opus' 48kHz to its own 44.1?


Not being familiar with Rockbox I would like like to ask: why would Rockbox not just output at 48 kHz (except for devices that do not support 48 kHz)?

  • Soap
  • [*][*][*][*][*]
IETF Opus codec now ready for testing
Reply #407
Not being familiar with Rockbox I would like like to ask: why would Rockbox not just output at 48 kHz (except for devices that do not support 48 kHz)?


Because even during music playback Rockbox can make lots of other sounds (talking menus, key clicks, etc etc) and they would all need to be mixed and output at a common samplerate.
Creature of habit.

  • maikmerten
  • [*][*][*]
IETF Opus codec now ready for testing
Reply #408
Not being familiar with Rockbox I would like like to ask: why would Rockbox not just output at 48 kHz (except for devices that do not support 48 kHz)?


Because even during music playback Rockbox can make lots of other sounds (talking menus, key clicks, etc etc) and they would all need to be mixed and output at a common samplerate.


Ah, thanks, this makes sense

  • C.R.Helmrich
  • [*][*][*][*][*]
  • Developer
IETF Opus codec now ready for testing
Reply #409
I still wonder how that would compare to something like 2x oversampled cubic hermite though.  That can be done really efficiently, and should give pretty good results.

Is there an implementation of such a resampler in existence that you know of? Never heard/seen one and would like to learn how it works.

Chris
If I don't reply to your reply, it means I agree with you.

IETF Opus codec now ready for testing
Reply #410
I have bumped into this pdf, hermite doesn't look that efficient to me.

  • saratoga
  • [*][*][*][*][*]
IETF Opus codec now ready for testing
Reply #411
I still wonder how that would compare to something like 2x oversampled cubic hermite though.  That can be done really efficiently, and should give pretty good results.

Is there an implementation of such a resampler in existence that you know of? Never heard/seen one and would like to learn how it works.


I prototyped it quickly in matlab a while ago for the 48k to 44.1k case: 

Code: [Select]
function out = over2x(in)

in2x=upsample(in,2);

f = [0 17/96 33/96 1]; a = [1 1 0 0 ];
b = firls(7,f,a);

upsampled=filter(b, [1; zeros(length(b),1)], in2x);

out = herm(upsampled, 2*48000/44100 );


Code: [Select]
function outbuf = herm(inptr, delta)

insamps=length(inptr);
pos=4;
phases=pos;
outsamps=0;
c=0;
while (pos < insamps)
    c=c+1;
    x3 = inptr(pos-3);
    x2 = inptr(pos-2);
    x1 = inptr(pos-1);

    x0 = inptr(pos);
    
    frac = phases -floor(phases);

    %/* 4-tap Hermite, using Farrow structure */
    acc0 = (3 * (x2 - x1) + x0 - x3) / 2;
    acc0 = (acc0 * frac);
    acc0 = acc0 + 2 * x1 + x3 - ((5 * x2 + x0) / 2);
    acc0 = (acc0 * frac);
    acc0 = acc0 + (x1 - x3) / 2;
    acc0 = (acc0 * frac);
    acc0 = acc0 + x2;

    phases = phases +delta;
    pos = floor(phases);
    
    
    outsamps = outsamps+1;  
    outbuf(outsamps) = acc0;
end


Its a little ugly, but its basically ported straight over from some c code I found online for the hermite polynomial.  Basically, my ideas was that you could FIR oversample by 2x which would both eliminate ultrasonic noise and reduce the error in the polynomial fit. Since hermite polynomials are simple, and on armv5e and higher you can do an FIR tap in 2.5 cycles (ignoring memory latency anyway), the overall computational load is pretty low.  I did some quick testing and it indeed worked pretty well, much better then linear or conventional hermite.  Then I found the speex code, and spent a while looking into it and haven't had time to come back to this.

  • IgorC
  • [*][*][*][*][*]
IETF Opus codec now ready for testing
Reply #412
I did some tests with a earlier version of rockbox-opus (it should still be valid since there still no optimizations on code) on a Samsung Galaxy S II (http://www.hydrogenaudio.org/forums/index....st&p=805855, just for update I did compile using ARMv7 optimizations and NEON fpu, but didn't see any increase of performance, probably because Rockbox uses the integer version of Opus decoder) and it shows that optimizations would be really welcome. Opus on Rockbox simple use too many cycles even on a fast (1,2GHz) dual-core, ARMv7 processor, so while it's capable to decode even the highest bitrate sample with easy, it simple uses too many cycles and uses too much power (my CPU gets really hot when playing Opus files). My Sansa Clip+ was clearly using more power to play Opus files than Vorbis too.

Either way, Opus is designed for embedded devices in mind, so with properly optimizations maybe it will use less CPU to decode Opus than even MP3 on future.

While optimizations are clearly desired still Opus is perfectly usable on smartphones. Your report indicates that Opus 128 kbps consumes less than 5% of phone's CPU.
http://www.hydrogenaudio.org/forums/index....st&p=805855

The battery of my Samsung Galaxy II has lasted 15 hours and 33 minutes for playback of Opus 128 kbps at my average volume on 10 albums.
2-3 hours of playback per day is enough and I recharge the battery almost every day because other functions consume considerably more. A display already consumes 50-70% of battery.


  • m45t3r
  • [*]
IETF Opus codec now ready for testing
Reply #413
I did some tests with a earlier version of rockbox-opus (it should still be valid since there still no optimizations on code) on a Samsung Galaxy S II (http://www.hydrogenaudio.org/forums/index....st&p=805855, just for update I did compile using ARMv7 optimizations and NEON fpu, but didn't see any increase of performance, probably because Rockbox uses the integer version of Opus decoder) and it shows that optimizations would be really welcome. Opus on Rockbox simple use too many cycles even on a fast (1,2GHz) dual-core, ARMv7 processor, so while it's capable to decode even the highest bitrate sample with easy, it simple uses too many cycles and uses too much power (my CPU gets really hot when playing Opus files). My Sansa Clip+ was clearly using more power to play Opus files than Vorbis too.

Either way, Opus is designed for embedded devices in mind, so with properly optimizations maybe it will use less CPU to decode Opus than even MP3 on future.

While optimizations are clearly desired still Opus is perfectly usable on smartphones. Your report indicates that Opus 128 kbps consumes less than 5% of phone's CPU.
http://www.hydrogenaudio.org/forums/index....st&p=805855

The battery of my Samsung Galaxy II has lasted 15 hours and 33 minutes for playback of Opus 128 kbps at my average volume on 10 albums.
2-3 hours of playback per day is enough and I recharge the battery almost every day because other functions consume considerably more. A display already consumes 50-70% of battery.

Maybe but just consider the low-end phones that are based on older architectures (like ARM11, there still lots of devices using it). If rockbox-opus uses 5% of CPU on a high-end phone, on a low-end smartphone it would means 10% or even 15% of CPU time. It is sufficient to put the CPU on a higher energy state that would drains lots of battery. Just saying "forget the less powerful devices" isn't really realist considering all the differents devices around.

Anyway, these tests are made with the phone fully awake. It didn't really represents the reality, where the phone would go to a lower energy state, but it shows how Opus is really unoptimized compared to another similar codecs (e.g. that uses MDCT like Vorbis, AAC or even MP3).
  • Last Edit: 24 September, 2012, 08:15:00 PM by m45t3r

  • saratoga
  • [*][*][*][*][*]
IETF Opus codec now ready for testing
Reply #414
Arguing about current Opus is pretty silly since just replacing the fixed point operations with their corresponding ARM instructions would massively increase performance.

  • brat-h
  • [*]
IETF Opus codec now ready for testing
Reply #415
Well, could someone "optimize" window's build of opus-tools for processors without SSE-instructions support?

  • jensend
  • [*][*][*]
IETF Opus codec now ready for testing
Reply #416
Well, could someone "optimize" window's build of opus-tools for processors without SSE-instructions support?
How many people are really
  • using Windows on processors which don't support SSE- none of which have been made in over a decade
  • likely to be tech-oriented enough/ enough of early-adopters to use opus-tools rather than waiting for more mainstream GUI encoding programs
  • in a situation where they really care about performance?
Seems like an inconsistent triad to me.

  • brat-h
  • [*]
IETF Opus codec now ready for testing
Reply #417
I didn't mean actually OPTIMIZATION, but a build of opus-tools which would work without SSE (as opus-tools-0.1.3 did for example)

  • saratoga
  • [*][*][*][*][*]
IETF Opus codec now ready for testing
Reply #418
Arguing about current Opus is pretty silly since just replacing the fixed point operations with their corresponding ARM instructions would massively increase performance.


A few optimizations have gone in, bringing playback down to about 100MHz on a (slow) ARM7TDMI core.  More will probably follow.

I didn't mean actually OPTIMIZATION, but a build of opus-tools which would work without SSE (as opus-tools-0.1.3 did for example)


Probably a good idea to specify which CPU you actually have.  Non-sse CPUs are so ancient it may be somewhat difficult to find a suitable compiler. 

  • lvqcl
  • [*][*][*][*][*]
  • Developer
IETF Opus codec now ready for testing
Reply #419
Duron Spitfire, Athlon Thunderbird? 12 years ago they were very good.
Also, a good idea to specify an OS. E.g. MSVC 2010 doesn't support Win2000 (let alone Win98/Me).

  • NullC
  • [*][*][*]
  • Developer
IETF Opus codec now ready for testing
Reply #420
Probably a good idea to specify which CPU you actually have.  Non-sse CPUs are so ancient it may be somewhat difficult to find a suitable compiler.
What? no. There is no difficulty in this.  In fact, for x86 builds you have to go out of your way a build-time to enable SSE in Opus-tools.

I don't really think Ralph wants to build two separate windows binaries (or if he did they're probably be x86 vs x86_64, and the latter would have SSE as it's required there)... so I'll suggest that he just do the next 32bit windows builds without SSE.


  • lvqcl
  • [*][*][*][*][*]
  • Developer
IETF Opus codec now ready for testing
Reply #421
AFAIK Opus internal resampler is noticeably faster with SSE enabled, and most of audio files are still 44.1kHz. I'm not sure that disabling SSE is a good thing.

  • Dukers
  • [*]
IETF Opus codec now ready for testing
Reply #422
exp_analysis7 branch doesn't compile on MSVC. src\analysis.c, src\mlp.c, src\mlp_data.c, and src\mlp_train.c are missing from the solution file. And mlp_train.c depend on pthread. I know it's probably low priority, but anyway...

  • lvqcl
  • [*][*][*][*][*]
  • Developer
IETF Opus codec now ready for testing
Reply #423
Last time I tried to compile opus mlp_train.c was unnecessary for en- and decoder.

IETF Opus codec now ready for testing
Reply #424
Decoding complexity is a huge consideration when (properly) implementing a decoder on a mobile device.

That said, I locked my Evo LTE at its lowest speed (single-threaded 384MHz powersave), where it still managed to play my 64kbps test files (with full Beats Audio doing goodness-knows-what in the background, using the "Java"/non-native mixer). This was with a NEON build of VLC for Android running at high priority.

Good news, I suppose, especially since I can't bring myself to imagine that alpha-quality VLC-Android codebase is in any way optimized for Opus playback (half the GUI options don't work and the app crashes playing videos, changing settings, etc).

I also hear the PowerAmp guys are working on getting Opus into their player, which is one of the most popular third-party players in Android land.
  • Last Edit: 03 October, 2012, 04:15:45 AM by The Sheep of DEATH
Copy Restriction, Annulment, & Protection = C.R.A.P. -Supacon