similar to: Updated MDCT callback patch

From: Thorvald Natvig <slicer at users.sourceforge.net> --- celt.pc.in | 2 +- configure.ac | 2 ++ libcelt/Makefile.am | 12 ++++++------ tests/Makefile.am | 2 +- tools/Makefile.am | 4 ++-- 5 files changed, 12 insertions(+), 10 deletions(-) diff --git a/celt.pc.in b/celt.pc.in index 98cc008..67a830b 100644 --- a/celt.pc.in +++ b/celt.pc.in @@ -10,5

Dear all In the paper section describes how CELT and SILK had implemented a look/up head delay of (2.5ms), (5ms) respectively , could you explain me> 1) those values are fixed. 1) how you guarantee those values independent of the architecture's performance. Thanks so much On Tue, Apr 18, 2017 at 10:05 AM, Diego Alejandro Parra Guzman < daparrag at correo.udistrital.edu.co>

Dear Experts, Can anybody please direct me to proper MDCT theory reference which will help me understand the code better? I'm trying to optimize MDCT for a embedded platform. So need good understanding about theory behind & implementation. Thanks in advance for your time. Warm Regards, Mahantesh -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

http://en.wikipedia.org/wiki/Modified_discrete_cosine_transform is an OK place to start. On Mon, Jul 8, 2013 at 7:33 AM, Mahantesh Belakhindi <girishec28 at gmail.com>wrote: > Dear Experts, > > Can anybody please direct me to proper MDCT theory reference which will > help me understand the code better? > > I'm trying to optimize MDCT for a embedded platform. So need

Hi, Attached is the first version of the DCT callback. It's still a bit WIP, but now you have something to refer to when I'm rambling :) Best Regards, Thorvald -------------- next part --------------

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

...as promised. This describes the mdct used in my d.m.l patch. I think it is the same as the Lee fast-dct. I typed it in a kind of pseudo-TeX, 'cause the ascii art would kill me. Hope you can read TeX source; if not, ask someone who can to make a .ps/.gif/.whatever of the TeX output, and put it on a webpage or something. I'm to lazy to do it (and besides, I don't have access to TeX,

Hello Timothy, Just FYI, Phil at ARM is still looking into why mdct is failing.. will keep you posted. In the mean time, do you want me to disable NE10 for mdct_forward and re-submit the patchset so we may make progress? Regards, Vish On 30 April 2015 at 09:33, Viswanath Puttagunta <viswanath.puttagunta at linaro.org> wrote: > > On 29 April 2015 at 17:22, Timothy B. Terriberry

Hello opus-dev, Can we please have review on RFCv2? We have quite a few optimizations (Eg: ifft/mdct_backwards, fixed point fft/ifft mdct_forward/backward etc) that are in my pipeline that depend on this patch series being accepted. Regards, Vish On 4 February 2015 at 12:21, Viswanath Puttagunta <viswanath.puttagunta at linaro.org> wrote: > Changes from RFC PATCH v1: > - passing

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 =

Hi vorbis-dev! I'm working with Pattara in the oggonachip project, and wondering about the implementation of mdct.c as hardware. According your recomendations about using the floating point version, I would say, we have to implement the integerized version of mdct as a core, and use the fpu only to round the input values. By doing that, you think the result would be still acceptable? How

Hi, I have a doubt regarding MDCT window size for OggVorbis decoder. Can the MDCT window size vary from 64 samples to 8192 samples? Specification says that "legal frame sizes are powers of two from 64 to 8192 samples" . Is this same as MDCT window size? Please help me out.. Regards, shikha <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage:

Good catch! I think gcc is just unable to make use of restrict for anything useful. Apparently your compiler does, so could you benchmark both patches below and see if it makes a difference in terms of speed. If it's worth it, I can keep the restrict and add the odd case handling, but if not I'll just remove the restrict. Thanks, Jean-Marc On 21/02/14 05:54 PM, Marcello Caramma

Hello Jean-Marc, **Resending.. not sure why subject got removed earlier** Below are the results that show test_unit_dft passes, but test_unit_mdct fails (only for nfft=480, 960, 1920) Note: Tested on BeagleboneBlack(Cortex-A8) fixed point on branch [1] ./test_unit_dft nfft=32 inverse=0,snr = 88.394372 nfft=32 inverse=1,snr = 93.896470 nfft=128 inverse=0,snr = 89.185895 nfft=128 inverse=1,snr =

Hi, Can someone tell me which MDCT and invMDCT equation uses? I implemented the invMDCT one given in eusipco.corrected.ps file (handed out by Monty way back) and it produces different time domain samples. I tried both the FFT method and the slow way directly from the equation and couldn't reproduce the results from the original code. This leads me to believe that the forward MDCT used in

Hi, as we are trying to implement MDCT in hardware, we are caring now about the "n" (size of input and output vectors to and from MDCT). As I have looked in the code, this "n" is chosen from the Ogg/Vorbis stream data in info.c:_vorbis_unpack_info() which means this "n" can vary aribitrarily (as the power of 2) depending only on the value got from song data? or is

Optimize opus decode (float only) use case using ARM NE10. Mainly effects opus_ifft and ctl_mdct_backward and related functions. Work based on previous Encode optimization using ARM NE10 library. TBD: Add commit id of upstream Encode NE10 optimization patch so that users have reference of how to enable this optimization Signed-off-by: Viswanath Puttagunta <viswanath.puttagunta at

Optimize opus decode (float only) use case using ARM NE10. Mainly effects opus_ifft and ctl_mdct_backward and related functions. Work based on previous Encode optimization using ARM NE10 library. TBD: Add commit id of upstream Encode NE10 optimization patch so that users have reference of how to enable this optimization Signed-off-by: Viswanath Puttagunta <viswanath.puttagunta at

Hi, Can you apply this change to the MDCT test and run it again. See if more (all) sizes pass. Given the results, I strongly suspect an overflow. Jean-Marc On 08/05/15 01:21 PM, Viswanath Puttagunta wrote: > Hello Jean-Marc, > > Below are the results that show test_unit_dft passes, but > test_unit_mdct fails (only for nfft=480, 960, 1920) > Note: Tested on