search for: srams

Hi, I'm using the Speex codec on my Blackfin-based board, and plain-C performance is pretty poor. Decoder is OK (something 25 MIPS for wide-band). But Encoder is not (wide-band quality 8, complexity 1): - 162 MIPS with Analog-Devices lib - 128 MIPS with 1.2beta2 (faster but not working) I don't worry that much, as it's not the optimized version, and everything is running in SDRAM.

Jean-Marc Valin skrev: > Ghost Wolf a ?crit : >> Hello Mailing List, >> I am a Speex supporter and user that would really like to know how much >> memory Speex uses to decode a 8kHz, 16kHz and 32kHz (primarily the 8kHz) >> and is it possible to use a 1kBytes of RAM to decode a 8kHz stream? (I >> was thinking of the possibility of using a ATmega168 to decode Speex)

From: Harald Finn?s > You seem to know what you're talking about, Seems v. Knows is a whole new ballgame. But I have been deploying SCSI on Linux since 1993 (Advansys, now owned by LSI, was the first vendor to formally support Linux), SCSI RAID on Linux since 1997 (large ICP-Vortex), through 3Ware's original FPGA ASIC designs in the AccelATA and Escalade 5000 series in 1999+. For a

Sorry for an OT post, but given the recent discussions here re raid, I was wondering if anyone had any info on the ITE 8212 RAID controller (GigaRAID) This is a PATA HW RAID as found on the GigaByte GA-8I915P-PRO motherboard. (I can see an IC on the board labeled GigaRAID. Their manual claims that is has it's own CPU). I am not using it because I have SATA, but I am still curious about

Thanks! The new are of xmega3 architecture, which is already included. So this should be simple. Where is the information about ISR-vector table, SRAM addresses and so on stored? -- Wilhelm Am 04.03.20 um 11:03 schrieb Dylan McKay: > Hey Wilhelm, > > This should be possible by editing the 'AVRDevices.td' [1]TableGen > definitions to add an entry for the newer chip types.

Some things to check. Do you compile with VAR_ARRAYS? If not, you can probably reduce the size of the managed stack. In terms of data RAM, everything should fit into SRAM easily. I've done some massive wideband RAM reduction in 1.2beta2. If it's not working on Blackfin, then we'd need to investigate that first. Depending on whether you're using all the bit-rates, you might want to

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). > > 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

Hi people, As I said before: I did the IDCT to run on the FPGA. My friends from university did the Reconstruction routines running on the FPGA. I'm helping with the LoopFilter, and it is almost there. (all VHDL) I did a small profiling of the libTheora running on a Altera Stratix II device: The processor used was the NIOS II with 8Kb of data and instruction cache, branch prediction and

Robin Getz a ?crit : > On Tue 19 Feb 2008 11:14, Voss, Stefan, AEAV22 pondered: >> I'm trying to integrate your speex codec on our custom Blackfin board and >> without uCLinux. I am using ADI-supplied VisualDSP++ IDE and corresponding >> toolchain. My question is: Is there anybody who ported speex with enabled >> BFIN_ASM to VisualDSP++ ? > > Nope - two

Am 04.03.20 um 11:16 schrieb Dylan McKay: > > The new are of xmega3 architecture, which is already included. So this > should be simple. > > Where is the information about ISR-vector table, SRAM addresses and so > on stored? > > > At the moment, this is not implemented in LLVM; these details are left > to the frontend. Clang/compiler-rt does not

Amit Ashara wrote: > 1. Since the stream I am working with is a mono channel, what should be > the advised page_segments to use. I am using an embedded system so > keeping the flash and SRAM usage are vital for the development. The number of channels has no impact on this at all. > 2. In the OpusTag the is the libopus a mandatory field? Yes.

Hi everyone, I'm looking into setting up a SATA hardware raid, probably 5 to use with CentOS 4. I chose hardware raid over software mostly because I like the fact that the raid is transparent to the OS. Does anyone know of any SATA controllers that are well tested for this sort of usage? From what I can tell from googling, this is more or less where RHEL stands: Red Hat Enterprise Linux

Theora hardware with LEON3 is runinng!!! My video was too slow, then I discovered that the problem was on LINUX! I don't exactly, but I suppose that the time of LINUX Call systems (like fread()) is the problem. If I don't use the linux (like is done on NIOS), I can to decode much faster than the time of exibition! Now we have two points on software (the hardware is the same,

> >Actually, you're the first I know using the VisualDSP++ toolchain :-) > I guess that's because speex has pretty big memory footprint. So developers that integrate speex tend to have plenty of RAM and once one has plenty of RAM he could install biggish OS. And between biggish OSes for Blackfin the most popular choice is uCLinux. And ucLinux works best with gnu tools. Something

> -----Message d'origine----- > De : Jean-Marc Valin [mailto:jean-marc.valin at usherbrooke.ca] > Envoy? : dimanche, 14. juin 2009 20:46 > ? : Stephane Lesage > Cc : speex-dev at xiph.org > Objet : Re: [Speex-dev] Resampler saturation > > Just to make sure I understand, the two patches you sent are > two different ways to fix the problem, with the only >

I'm considering implementing Opus as the codec for an embedded ARM-based battery powered audio system. In the interest of battery life and board footprint I'd like to specify the smallest CPU that can do the job. In some quick testing on Cortex-A8 (a very different core, but at least ISA compatible and hopefully fairly similar to M4 for things like cycle counts and code size) I saw

I am interested in using Speex in an embedded system built around an ARM microcontroller. I have seen other posts indicating that Speex can run in real-time on some iPAQ PDA's, but these are using a StrongARM 166MHz processor. I'm looking more at the chips from Atmel (SAM7), Philips (LPC2xxx), and TI (TMS 470), which are ARM7TDMI with on-chip SRAM and flash, running at speeds of 33 to

> 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,

Hello Mailing List, I am a Speex supporter and user that would really like to know how much memory Speex uses to decode a 8kHz, 16kHz and 32kHz (primarily the 8kHz) and is it possible to use a 1kBytes of RAM to decode a 8kHz stream? (I was thinking of the possibility of using a ATmega168 to decode Speex) //P?r, Sweden

> ok, that is not good for my plans... > Is there any thing in the the 8kB of RAM that is always the same (lookup > table etc.) or did you already think of that? I told you the RAM requirements. The lookup tables are already counted as ROM. Basically, just one decoded frame already takes 320 bytes. Add the excitation memory and you've already blown the budget. > I'm curios