New developments in the Opus audio codec
people.xiph.org
people.xiph.org
That is almost concerning, because even though it seems like overkill to gpu accelerate audio decoding (that the copy and latency overhead isn't worth it) I imagine it will require quite a bit of refactoring to make a SIMD decoder (or encoder). But that will be absolutely necessary to see Opus adoption as the web audio standard where mobile devices need every watt of energy savings possible.
It doesn't require extensive refactoring. There are patches to use SIMD that aren't merged yet— though pure C improvements have tended to be more important since NEON isn't available on all ARM parts.
Otherwise, I'm excited at the possibilities this provides when used in open source projects that utilize open protocols to deliver audio end-to-end (peer-to-peer) over the network.
edit: sorry, false alarm! that was something else. the site loads perfectly fine (and I am honestly happy about every site that does not differentiate between desktop and mobile clients but serves a readable, clearly structured, "static" page like that!).
edit 2: even the audio samples worked flawlessly. the accompanying displays not though.
(b/c i just have to have 40 tabs open, steam, and a mp3 player at all times)
It's not negligible to me, as I'm running a music server on a Raspberry Pi that needs to transcode audio, and the Pi can only transcode FLAC to Vorbis at 1.8x realtime. This makes it terribly sensitive to background tasks — anything else going on tends to prevent it from keeping up. So I'm quite glad you all are optimizing for ARM :)
Also, what optimisations have you got turned on (on the compiler). For a realtime system, it might make sense to turn them down, trading stream size for processing time.
Although ... rpi ugh. I often feel that device was an evil scheme to turn people off of arm. It is _remarkably_ slow for its cost and power consumption. For $100 you can have an arm device which is easily 32x faster for most DSP-ish stuff, and which draws similar power.
It's always a tradeoff between price, community size and compute power with these little things. Hell, even the ZipIt Z2 running a tiny little Freescale processor had a good community when it was new.
I can go and get a HardKernel O2 and have really good performance but there won't be that many people in the IRC channel to help me out when I have a device specific question.
The Raspberry Pi has captured such an audience that there's people everywhere who can help, as well as a huge amount of development going on.
The other advantage of the Raspberry Pi is that replacing the whole board is cheaper than buying the JTAG breakout for other devices (I'm looking at you, GlobalScale).
I'd love to talk with you further about the different devices around - I really do have a lot of them and I have more on the way. Support and communities for ARM devices seems to be really fragmented, and it's a shame.
I think my contact details are in my profile. Sorry for the rambling reply, it's late here.
At bitrates higher than about 64 kbps, CBR actually uses less CPU to encode than VBR. This is because the CELT layer was designed to be natively CBR (since for real-time communication you want strict rate control all the time), and VBR is achieved by varying the target CBR rate on a packet-by-packet basis (using additional analysis not required by CBR).
This was a major departure from codecs like Vorbis, which are natively VBR, and implement CBR by encoding at up to 16 different rates and picking the one closest to the actual target, or other codecs which use a "bit reservoir" to shift bits back and forth between frames (increasing delay due to increased buffering requirements).