similar to: Porting Vorbis lib on Ti DSP ? How to ?

Actually, we have a integerized version of the vorbis libraries that are available, royalty free, with a simple attribution requirement. These libraries are 100% C code and run faster than real time on a cirrus 7312-74mhz processor (arm core). My guess is they should run at about 20-30% cpu utilization on a strongarm/200. Monty has this same code, but his version doesn't play b4 content real

--- Bernd Löhr <B.Loehr@hermstedt.de> wrote: > Hi, > > I am using the FLAC encoder and decoder lib in it's integer only > version (FLAC__INTEGER_ONLY_LIBRARY) on a PPC405 system. > > I encounter complete different behaviour when setting random playback > > positions while decoding different flac encoded files. > If they have been encoded on a PC,

Hi, I wonder if there is specific requirement or restriction for the decoder in order to be consider "Vorbis" compliant (or let's say, to be a "correct" vorbis decoder). I am experimenting with integerized libvorbis and the decoder delivers the audio data as following, (and compare with the floating point version below). $ tail audioout-int.txt 0290670 025e 085c 02cf 0895

Hi there. Just a little status update how that integerization is coming along. I am trying to limit myself to 32 bit arithmetics. That means not using any __int64 or long long datatypes at any point. I have now replaced all steps up to including the estimation of the LPC filter coefficients with integer code. That is about a quarter of the total work completed, I would say. One problem that i

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

hello, I have recently compiled speexenc for WinCE/StrongARM SA-1110-processor. It seems to run with no errors, however the encoding time is very slow - 10 seconds of speech takes aprox 3 minutes to encode. Even though the target architecture is significantly less powerfull than a standard PC, I am trying to figure out why it is this slow. Does speex use floatpoint calculations? The input raw

A few months ago, there was some discussion about adding fixed-point support for iPAQ's StrongARM to Ogg Vorbis (whether and how it's possible, that is). Has anybody tried this yet ? Gregor --- >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-dev-request@xiph.org'

Hello, I may be stupid, but I cannot find any data on how "expensive" the Vorbis Decoder is. Looking for an embedded solution I am interested in how many "MIPS" you need to decode a MONO audio stream at reasonable quality (44 kHz, approx. 100 kbps?) Can it be done in a microcontroller, or do I need ultra-expensive DSPs to do it? Thanks for hints Jens --- >8 ---- List

Hi Vorbis, Now I get libvorbis-rc3 + integerized mdct_backward + integerized window running. The sound output is ok. Now we have to go further on possible optimization of the code in order to have the music played realtime on our chip (LEON-Sparc). There are 2 possible ways: 1.Make everything integer, remove all floating point usage. Then we can remove FPU and can run the chip at higher

Hello, I have used "MDCT_INTEGERIZED" version of mdct and the resulting bitstream is absolutely silent. Do I have to make some other changes to the source code to get it working? I mean some int->float or float->int conversion before/after call a mdct function. Thanks Rado --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage:

Hi, I'm trying to determine how the frequency data that is passed to the MDCT, and output time domain data obtained from the MDCT, is changed when setting #define MDCT_INTEGERIZED For instance, the trig array, for a size 256 window begins 1.000000 0.000000 0.998795 -0.049068 0.995185 -0.098017 if INTEGERIZED is set, then it begins 16384 0 16364 -803 16305 -1605 which is simply a left shift

Since two people have asked me to open the source code on my work-in-progress Integer Speex project, I have put it up onto my site www.openacm.org as a download in the project tree. the suggested directory structure is as follows, i.e. the speex source folder should be on the same directory level as the sphinx filder. peex-1.0.1 (ideally the folder from within the SpeexACM source archive)

I see the following in arch.h #elif defined (TI_C6X_ASM) #include "fixed_c6x.h" But there does not seem to be a header file by that name in the 1.1.2 distribution. dave

On 29/08/16 03:54 PM, David Boles wrote: > I see the following in arch.h > > #elif defined (TI_C6X_ASM) > #include "fixed_c6x.h" > > But there does not seem to be a header file by that name in the 1.1.2 distribution. The file's in Git, but it's not included in the distribution right now. I don't think it's been tested since CELT version 0.3 or

I did find it using my browser search. I am not sure where the "Git" is. It looks like many of the macros that use the TI intrinsics are commented-out. #if 0 +#include "dsplib.h" + +#undef MAX16 +#define MAX16(a,b) _max(a,b) ... Once my development has commenced (still in the study phase). I will be trying it. dave -----Original Message----- From: Jean-Marc Valin

Hi Jamey, Really cool to see Speex being ported to the C55xx and I'd be glad to integrate the changes required in Speex (and the style's fine with me). Here are a couple comments on the patch you sent (I looked at it, but haven't compiled). 1) The changes you made to the pack un unpack functions would only work if the 16-bit chars are "big endian" (relative to the two bytes

Jean-Marc Valin wrote: >Hi Jamey, > >Really cool to see Speex being ported to the C55xx and I'd be glad to >integrate the changes required in Speex (and the style's fine with me). >Here are a couple comments on the patch you sent (I looked at it, but >haven't compiled). > > > Cool. >1) The changes you made to the pack un unpack functions would only

> I have the encoder and decoder running now and have verified that the > encoder is bit-exact wrt to the fixed-point code running on x86 for the > same 30-second audio sample. Encode and decode together run in > real-time for 8KHz data, complexity=3, on 120MHz C5509 when code and > data are all in on-chip SRAM. I have not tested the wideband codec yet. Cool! Just curious,

Jean-Marc Valin wrote: >Well, I guess the first thing to look is whether your DSP can actually >do either 16x32=>48 or 16x32=>32 (keeping the MSBs), which is what the >smulwb does on ARM. If that's the case, you can gain a lot of speed (use >one instruction for 16x32 instead of three). Otherwise, replacing the >32x32 multiplies by 16x16 is probably a good thing. >

Jean-Marc Valin wrote: >>One thing I've noticed so far in the filter_mem2 code is the calls to >>SATURATE(x, 805306368). 805306368 is 0x30000000. I was expecting that >>to be on a bit boundary, say 0x3fffffff? In which case the arithmetic >>saturation logic could be used. >> >> > >I don't think it would make that big of a difference,