search for: lpc_restore_signal

.... I've tested this some and am reasonably confident of it. It seems to provide a decent performance improvement for decoding. -- Brady Patterson (brady@spaceship.com) Give us the Destruct-O-Beam! -------------- next part -------------- ; $Name$ $Revision$ $Date$ .text .align 2 .globl _FLAC__lpc_restore_signal_asm_ppc_altivec_16 .globl _FLAC__lpc_restore_signal_asm_ppc_altivec_16_order8 _FLAC__lpc_restore_signal_asm_ppc_altivec_16: ; r3: residual[] ; r4: data_len ; r5: qlp_coeff[] ; r6: order ; r7: lp_quantization ; r8: data[] ; see src/libFLAC/lpc.c:FLAC__lpc_restore_signal() ; these is a PowerPC/Alti...

...av Lichvar's patch from Jan/Feb 2003 (that was posted here), which I retrieved and hand-merged from the archives. I made a few minor changes to that, too, and managed to reduce it by a few ops (nothing major). I can repost both his patch and mine on top of it, too. I also have some alternate lpc_restore_signal implementations (in C) I can extract and post (don't really have a clean changeset), but I haven't been able to get lpc-enabled FLACs to play at normal speeds, yet. I'll try to find some time in the next few months and learn enough asm tricks to make this one faster for the ARM. Help...

This patch adds flac_restrict to share/compat.h and adds it to arguments of ...lpc_compute_residual...()/...lpc_restore_signal...() functions. As a result, FLAC__lpc_compute_residual_from_qlp_coefficients_wide_intrin_sse41() now offers no advantage for 64-bit compiles and was removed from x86-64 part of stream_encoder.c -------------- next part -------------- A non-text attachment was scrubbed... Name: restrict.patch Type...

thanks for the patch. also, if you have miroslav's patch again a more updated version of bitbuffer.c that would be great. I have been meaning to get around to applying it for a long time. btw how are you playing it on the ipod? not sure how to help out with lpc_restore_signal(). there are x86 and PPC versions of the routines in CVS that might be good references. it is basically a multiply-accumulate loop but you have to be careful about overflow. an ARM7 version of this function would help the speed on several other FLAC-supported devices. Josh --- Eric Wong <er...

...hese must be zero because we can only get here if we got to the end of the buffer */ > > btw how are you playing it on the ipod? With a modified version of Music Player Daemon (MPD, www.musicpd.org). http://www.ipodlinux.org/MPD has more info about it. > not sure how to help out with lpc_restore_signal(). there are > x86 and PPC versions of the routines in CVS that might be good > references. it is basically a multiply-accumulate loop but you > have to be careful about overflow. an ARM7 version of this > function would help the speed on several other FLAC-supported > devices. T...

The #endifs are mismatched, and my builds were failing because lpc_restore_signal* weren't getting declared. I've also commented the endifs to make them easier to match. Also, is there any reason #ifdefs for FLAC__HAS_NASM and FLAC__CPU_IA32 are separate and nested the way they are and not combined like this?: #if defined(FLAC__CPU_IA32) && defined(FLAC__HAS_...

This lpc_restore_order was partially inspired by Miroslav's affd, though my (not very great) ARM asm version resembled this, as well. The other two reduce CPU array indexing overhead in loops a little. Additionally, a request for help: My not very optimized lpc_restore_signal is at the below URL, I couldn't get the ldm* instructions to work as advertised, even though I've talked to several ARM asm hackers who said they looked right. I can use the fp as a regular register since since I'm compiling without it. Comments within should explain what I'm...