IPB

Welcome Guest ( Log In | Register )

23 Pages V  « < 15 16 17 18 19 > »   
Closed TopicStart new topic
IETF Opus codec now ready for testing, That's CELT 0.11
m45t3r
post Sep 22 2012, 02:41
Post #401





Group: Members
Posts: 22
Joined: 14-January 12
Member No.: 96431



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.
Go to the top of the page
+Quote Post
sluggy
post Sep 22 2012, 16:55
Post #402





Group: Members
Posts: 59
Joined: 22-June 12
Member No.: 100900



CDBurnerXP has just added opus support for burning audio cds, which is great news smile.gif
Go to the top of the page
+Quote Post
saratoga
post Sep 22 2012, 23:20
Post #403





Group: Members
Posts: 5156
Joined: 2-September 02
Member No.: 3264



QUOTE (lvqcl @ Sep 21 2012, 14:35) *
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.
Go to the top of the page
+Quote Post
jensend
post Sep 23 2012, 00:00
Post #404





Group: Members
Posts: 149
Joined: 21-May 05
Member No.: 22191



QUOTE (lvqcl @ Sep 21 2012, 12:35) *
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.
Go to the top of the page
+Quote Post
lvqcl
post Sep 23 2012, 01:06
Post #405





Group: Developer
Posts: 3467
Joined: 2-December 07
Member No.: 49183



QUOTE (saratoga @ Sep 23 2012, 02:20) *
Probably borrow the neat looking one from speex if i ever get around to it.
QUOTE (jensend @ Sep 23 2012, 03:00) *
the Xiph "Speex resampler," which is also used in opus-tools

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

QUOTE (jensend @ Sep 23 2012, 03:00) *
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.
Go to the top of the page
+Quote Post
saratoga
post Sep 23 2012, 01:49
Post #406





Group: Members
Posts: 5156
Joined: 2-September 02
Member No.: 3264



QUOTE (lvqcl @ Sep 22 2012, 20:06) *
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.
Go to the top of the page
+Quote Post
maikmerten
post Sep 23 2012, 09:30
Post #407





Group: Members
Posts: 219
Joined: 12-February 02
Member No.: 1312



QUOTE (lvqcl @ Sep 21 2012, 19:35) *
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)?
Go to the top of the page
+Quote Post
Soap
post Sep 23 2012, 12:43
Post #408





Group: Members
Posts: 1017
Joined: 19-November 06
Member No.: 37767



QUOTE (maikmerten @ Sep 23 2012, 03:30) *
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.
Go to the top of the page
+Quote Post
maikmerten
post Sep 23 2012, 13:42
Post #409





Group: Members
Posts: 219
Joined: 12-February 02
Member No.: 1312



QUOTE (Soap @ Sep 23 2012, 11:43) *
QUOTE (maikmerten @ Sep 23 2012, 03:30) *
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 smile.gif
Go to the top of the page
+Quote Post
C.R.Helmrich
post Sep 23 2012, 13:58
Post #410





Group: Developer
Posts: 694
Joined: 6-December 08
From: Erlangen Germany
Member No.: 64012



QUOTE (saratoga @ Sep 23 2012, 02:49) *
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.
Go to the top of the page
+Quote Post
LordWarlock
post Sep 23 2012, 16:07
Post #411





Group: Members
Posts: 120
Joined: 21-August 05
Member No.: 24044



I have bumped into this pdf, hermite doesn't look that efficient to me.
Go to the top of the page
+Quote Post
saratoga
post Sep 23 2012, 19:26
Post #412





Group: Members
Posts: 5156
Joined: 2-September 02
Member No.: 3264



QUOTE (C.R.Helmrich @ Sep 23 2012, 08:58) *
QUOTE (saratoga @ Sep 23 2012, 02:49) *
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
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
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.
Go to the top of the page
+Quote Post
IgorC
post Sep 24 2012, 16:52
Post #413





Group: Members
Posts: 1581
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



QUOTE (m45t3r @ Sep 21 2012, 22:09) *
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.

Go to the top of the page
+Quote Post
m45t3r
post Sep 25 2012, 01:13
Post #414





Group: Members
Posts: 22
Joined: 14-January 12
Member No.: 96431



QUOTE (IgorC @ Sep 24 2012, 12:52) *
QUOTE (m45t3r @ Sep 21 2012, 22:09) *
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).

This post has been edited by m45t3r: Sep 25 2012, 01:15
Go to the top of the page
+Quote Post
saratoga
post Sep 25 2012, 01:59
Post #415





Group: Members
Posts: 5156
Joined: 2-September 02
Member No.: 3264



Arguing about current Opus is pretty silly since just replacing the fixed point operations with their corresponding ARM instructions would massively increase performance.
Go to the top of the page
+Quote Post
brat-h
post Sep 25 2012, 15:28
Post #416





Group: Members
Posts: 3
Joined: 24-January 12
Member No.: 96664



Well, could someone "optimize" window's build of opus-tools for processors without SSE-instructions support?
Go to the top of the page
+Quote Post
jensend
post Sep 25 2012, 20:33
Post #417





Group: Members
Posts: 149
Joined: 21-May 05
Member No.: 22191



QUOTE (brat-h @ Sep 25 2012, 08:28) *
Well, could someone "optimize" window's build of opus-tools for processors without SSE-instructions support?
How many people are really
  1. using Windows on processors which don't support SSE- none of which have been made in over a decade
  2. likely to be tech-oriented enough/ enough of early-adopters to use opus-tools rather than waiting for more mainstream GUI encoding programs
  3. in a situation where they really care about performance?
Seems like an inconsistent triad to me.
Go to the top of the page
+Quote Post
brat-h
post Sep 26 2012, 11:43
Post #418





Group: Members
Posts: 3
Joined: 24-January 12
Member No.: 96664



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)
Go to the top of the page
+Quote Post
saratoga
post Sep 26 2012, 16:08
Post #419





Group: Members
Posts: 5156
Joined: 2-September 02
Member No.: 3264



QUOTE (saratoga @ Sep 24 2012, 20:59) *
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.

QUOTE (brat-h @ Sep 26 2012, 06:43) *
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.
Go to the top of the page
+Quote Post
lvqcl
post Sep 26 2012, 17:35
Post #420





Group: Developer
Posts: 3467
Joined: 2-December 07
Member No.: 49183



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).
Go to the top of the page
+Quote Post
NullC
post Sep 26 2012, 18:17
Post #421





Group: Developer
Posts: 200
Joined: 8-July 03
Member No.: 7653



QUOTE (saratoga @ Sep 26 2012, 08:08) *
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.

Go to the top of the page
+Quote Post
lvqcl
post Sep 26 2012, 19:03
Post #422





Group: Developer
Posts: 3467
Joined: 2-December 07
Member No.: 49183



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.
Go to the top of the page
+Quote Post
Dukers
post Sep 26 2012, 23:20
Post #423





Group: Members
Posts: 22
Joined: 29-July 07
Member No.: 45724



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...
Go to the top of the page
+Quote Post
lvqcl
post Sep 27 2012, 15:38
Post #424





Group: Developer
Posts: 3467
Joined: 2-December 07
Member No.: 49183



Last time I tried to compile opus mlp_train.c was unnecessary for en- and decoder.
Go to the top of the page
+Quote Post
The Sheep of DEA...
post Oct 3 2012, 09:13
Post #425





Group: Developer
Posts: 175
Joined: 16-April 06
Member No.: 29596



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.

This post has been edited by The Sheep of DEATH: Oct 3 2012, 09:15


--------------------
Copy Restriction, Annulment, & Protection = C.R.A.P. -Supacon
Go to the top of the page
+Quote Post

23 Pages V  « < 15 16 17 18 19 > » 
Closed TopicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 22nd December 2014 - 05:37