similar to: Fixed vs. Floating Point primer. was: Implementing Vorbis in hard ware

> -----Original Message----- > From: owner-vorbis-dev@xiph.org [mailto:owner-vorbis-dev@xiph.org]On > Behalf Of Steve Underwood > Sent: Tuesday, January 23, 2001 10:58 AM > To: vorbis-dev@xiph.org > Subject: Re: [vorbis-dev] Fixed vs. Floating Point primer. was: > Implementing Vorbis in hardware > > > "Borgerding, Mark A." wrote: > > [...] > >

Hello! I would like to send some bugs and bugfix(es): 1. There is an encoding bug in the beta 3 (downloaded exe from the vorbis.com) and in the latest CVS (jan. 10.) too (compiled with MSVC 6.0): If the file contains some non-audible noise at the begin or at the end, the encoder/decoder makes some large clips in the output file, if the bitrate is 350kbit/s . If I use 256kbit/s or

Dear all, I am trying to calculate sample size for a clinical research, on the basis of generalized wilcoxon test or Tarone-Ware test. It seems SAS can do this job using it "POWER" procedure, but SAS is not available to me. I would be very grateful if you could let me know if any R package or other tools which could cope with this problem. Best Regards, Wang [[alternative HTML

Has anyone had any luck deploying rails apps in a Linux VM image on a production MS Server 2003 with IIS ? If so which image did you use a a base? I am currently using a Gentoo image and have installed ruby and rails but after performing a rails testapp and running webrick with ruby script/server I get a page timeout when trying to visit http://0.0.0.0:3000or http://127.0.0.1:3000 and I get no

Hi All, I have a powerware UPS 5110 connected to an openindiana server with the bcmxcp_usb driver and running nut 2.65 compiled and installed as root to avoid permission issues. On running the following debug code to test the UPS's communication it fails at the same time with the following error. ./bcmxcp_usb -u root -DDD -a 5110 ....... 2.523879 get_answer: (128 bytes)

Anyone have any idea if the any of the Sharc or TigerSHARC DSPs are powerful enough to do realtime Speex? <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 'speex-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed.

Another newbie question. I've written a function and saved the file as Xtabs.R, in a central place on a network so others will be able ot use the function, My question is how do i call this function? I've tried to chance the working directory, and tried to load it via; > library(Xtabs, lib.loc="//filer/common/technical/surveys/R_test") but neither seem to work? the function

They claim to max out at 1,800 MFLOPs And have a clock speed of up to 300 mhz. Jean-Marc Valin wrote: >Tell me how fast these chips are, I'll tell you if there's a chance... > > Jean-Marc > >Le jeu 18/12/2003 à 16:52, David Siebert a écrit : > > >>Anyone have any idea if the any of the Sharc or TigerSHARC DSPs are >>powerful enough to do realtime Speex?

> 3. I'm interested in the methodology for creating a fixed point > implementation and guaging how "good" it is relative to the floating > point golden standard My methodology at this stage is to get it working on the floating point DSP first and to gain recent experience in both Speex and the TI DSP range while I do so. Then I'll enter into serious discussions about

I've been following this kist for a while now and I suppose I had better introduce myself. This is going to be rather a long message, but that can't be avoided. My name is Andrew Baker and I work for a company called TeleDesign. We are based in the UK. http//www.teledesign.co.uk I have lots of experience with telecomms, a fair bit with VoIP, quite a bit (but rather less recent) with

Le ven 19/12/2003 à 09:38, David Siebert a écrit : > They claim to max out at 1,800 MFLOPs > And have a clock speed of up to 300 mhz. Are you kidding? Not only is this enough to encode/decode in real-time, but you can probably do ~50 channels (or more) at the the same time. Jean-Marc > Jean-Marc Valin wrote: > > >Tell me how fast these chips are, I'll tell you if

> > 4. I think the codec is portable to more fixed point embedded devices > > if you stick to C rather than C++ code. If you follow the TI XDAIS > > standard you'll wind up creating an object-oriented codec but you can > > do it all in C (Relocatable, re-entrant code, state structure, etc.). > > Who knows you might want to run it on an embedded DSP that

Salve, does sombody can say me if vorbis ogg run on this TI-chip? OMAP5910 Integrates a TMS320C55x™ DSP core with an ARM925 on a Single Chip Sampling today, the OMAP5910 processor integrates a TMS320C55x DSP core with a TI-enhanced ARM925 on a single chip for the optimal combination of high performance with low power consumption. This unique architecture offers an attractive solution to

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

1. Good Luck 2. Keep posting, we are interested in a fixed point version of speex and would try to colaborate. Our need isn't as immediate but if you set this up correctly we and (hopefully) others will try to collaborate. 3. I'm interested in the methodology for creating a fixed point implementation and guaging how "good" it is relative to the floating point golden standard

The attached file contains build files for TI's Code Composer Studio (CCS) for the C54x, C55x, and C6x DSPs. I had intended to post this a couple of months ago, but it took a long time to get around to doing the little bit of cleanup required. This is a file I/O loopback application suitable for running with the CCS simulators, for evaluating memory and MIPs requirements for these

Hi, I can see that there has been some effort to compile the SPEEX codec to operate on the TI c54x and c55x DSPs and I am wondering if anyone would be able to update the mailing list with their current MIPs and Memory resource requirements for their c54x and/or c55x compilation? The only estimate I was able to find in the mailing list archive was 42MIPs but I'm not sure if this is an

> Quoting Stephane Lesage <stephane.lesage at ateis-international.com>: > > Is this a bug ? Is it possible to fix it ? > > (I use version speex 1.2beta2, because newer versions just > don't work > > on my > > platform) > > This is probable the cause. 1.2beta2 was the first release to > include the resampler and it had many bugs. I suggest trying

Hi, Just a couple tips to reduce complexity. First, I think you'd get a good speedup by enabling the PRECISION16 switch (if it's not done already). This (very) slightly reduces quality, but means you convert a lot of "emulated" 16x32 multiplications into 16x16. There are also several routines that would benefit from platform-specific optimizations. There are already

Switch the 53c700 driver to only use non-coherent descriptor memory if it really has to because dma_alloc_coherent fails. This doesn't matter for any of the platforms it runs on currently, but that will change soon. To help with this two new helpers to transfer ownership to and from the device are added that abstract the syncing of the non-coherent memory. The two current bidirectional cases