similar to: who needs documentation?

> You didn't send unsubscribe messages to the lists, so what's left? Right: > you sent HTML emails! Come to think of it, you just did it again. :^) Actually, he didn't. He sent a multipart message, with a "text/html" section and an equivalent message in "text/plain". Other than a little extra bandwidth, I don't think anyone minds multipart messages.

In mdct.c there's some functions including some-point butterfly. In 32-point and 16-point there are calling of smaller-point function everytime twice on each half of data. When I looked on it I found that's just linear algebra. So it can be rewritten to matrix multiplication. Some one can say: there's optimization on in register working. But imagine there's one calling 32-point,

Hi, Keep up the good work! The file sizes of Theora's output is amazing! I have just joined the list, and would like to contribute to the

Sorry for starting another topic, this is actually a reply to Segher's post on Sun Oct 22 on the 'mdct question' topic. I wasn't subscribed properly and so I didn't get email confirmation and thus can't add to that thread. So Segher, if the equation is indeed what you say it is, then replacing mdct_backward with this version should work, but it doesn't. Am I applying

libvorbis does not currently have any simd/vectorization. Following patches add generic framework for simd/vectorization and on top, add ARM-NEON simd vectorization using intrinsics. I was able to get over 34% performance improvement on my Beaglebone Black which is single Cortex-A8 based CPU. You can find more information on metrics and procedure I used to measure at

Hi Perhaps I'm missing somthing, but i can't find the most interesting documentation (about MDCT trnasform and structur of packets). Maybe someone can show me the right location? bye <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org'

I did composition of butterfly8 and butterfly16 and I found, that these functions are well decomposed - decomposition doesn't lower computional speed. On the other hand the same can be done with butterfly8 - decomposition to butterfly4 (further decomposition is not possible) but there's no reason to do this. I think little improvement can be done by inlining them. Compiler and processor

I tracked down the bug to an incorrect use of restrict. I would not consider this a compiler bug: we are lying to the optimizer by telling it that a pointer is restrict when in fact it isn't. This can be fixed like so: diff --git a/celt/mdct.c b/celt/mdct.c index 1634e8e..fa5098c 100644 --- a/celt/mdct.c +++ b/celt/mdct.c @@ -276,8 +276,8 @@ void clt_mdct_backward(const mdct_lookup *l,

Hello Vorbis folks, I'm one of the FFTW authors (www.fftw.org), and a few days ago I was playing with our codelet generator for fun and modified it to spit out hard-coded MDCTs of small sizes. The code (at jdj.mit.edu/~stevenj/mdct_128nr.c) for 256 samples (128 outputs) seems to be almost twice as fast as the Vorbis MDCT code for that size on my 2.2GHz P-IV (gcc 3.2.2 and flags "-O1

Thread-split from the vorbis-mailing list ("Vorbis determined to be as good as MPC at 128 kbps!") <p>On Sun, 30 May 2004, Segher Boessenkool wrote: [Steven So] SS>> If iTunes AAC can encode castanets with much less pre-echo at SS>> ABR 128 kbps, then hopefully there will be an imaginative SS>> (and non-patented) way of doing this in Vorbis without the SS>>

Dear all I'm working on the implementation of the MDCT for the processor ARM-Cortex-M4 I'm trying to replicate the behavior of the MDCT for several overlapped values however I realized that current implementation of the MDCT is very close to the theory only in case in which we have and overlap exactly equal to N/2 where N is the size of the input vector as is shown in the examples for

After a few experiments, I found that both alternatives are very similar, and 2~5% slower compared to the following: diff --git a/celt/mdct.c b/celt/mdct.c index 1634e8e..e490c3b 100644 --- a/celt/mdct.c +++ b/celt/mdct.c @@ -277,7 +277,7 @@ void clt_mdct_backward(const mdct_lookup *l, kiss_fft_scalar *in, kiss_fft_scala it in-place. */ { kiss_fft_scalar * OPUS_RESTRICT yp0 =

I am attempting to port CELT to the TI C5515 DSP. I am compiling/assembling/linking with Code Composer Studio 4. I have enabled the TI_55 specific optimizations in my config.h file per this <http://lists.xiph.org/pipermail/celt-dev/2008-December/000033.html> post. However, I am getting several "undefined symbol" linking errors that do not make sense to me. According to the error

Hello All, I extended the libNE10 optimizations for float towards mdct_backwards/opus_ifft. I am able to get about 14.26% improvement for Decode use case now on my Beaglebone Black. Please see [1] for measurements. Questions 1. Since this patch needs to go in after Encode [2] patch) should I submit this as patch series? 2. Since Jonathan Lennox posted intrinsics cleanup [3] patch, should

Hi I have gone through the document available in the net regarding the Vorbis encoder /Decoder. Based on that i have prepared a understanding document on the encoder/decoder block. I would like to know whether my understanding of the coder is OK. If there are any other additional block /information pl. provide me with the same. Thanks and regards S.Padmashri <HR NOSHADE> <UL>

My ogg library is located in /home/warren/local. So when I configure and compile the vorbis module on my linux box using configure --with-ogg-prefix=/home/warren/local make I get the following error during the make: gcc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0.0\" -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -I. -I. -I../include -O20 -ffast-math -mno-ieee-fp -D_REENTRANT

Hi, I'm currently working on a paper describing Ogg Vorbis. It is not finished yet. Mostly the decoder is being described. If you have any comments, please send them to me. See: http://www.turbocat.net/~hselasky/math/vorbis/files/ Then I have a question about the function "bark_noise_hybridmp()" which is used in the encoder. Can someone describe what the function does in

Hi all, The decoder is down 30% execution time, identical bit output. Didn't get the mdct yet; 1024 point mdct is a bit much to brute-force, and I'm not going to hand-unroll the whole thing either (the machine- unrolled version produced a 1.5M executable; understandably, it wasn't very fast. Still waiting for processors with 1.5M L1 code caches ;-) Slowest parts now are: -- mdct --

Changes from RFC PATCH v1: - passing arch parameter explicitly - reduced stack usage by ~3.5K by using scaled NE10 fft version - moved all optimization array functions to arm_celt_map.c - Other cleanups pointed out by Timothy Phil, As you mentioned earlier, could you please address all compile and linker errors/warnings coming out of Ne10 library? You can find my working Ne10 repo at [1] You

Changes from RFC PATCH v3 - Just rebased on tip - For all else, please see notes from RFC PATCH v3 at http://lists.xiph.org/pipermail/opus/2015-March/002902.html - latest wip opus tree/branch https://git.linaro.org/people/viswanath.puttagunta/Ne10.git branch: rfcv4_final_fft_ne10 Viswanath Puttagunta (1): armv7(float): Optimize encode usecase using NE10 library Makefile.am