similar to: libFLAC internals

I think I've gotten FLAC__lpc_restore_signal() about as good as I'm going to get it. Here's what I have: -a new file, lpc_asm.s, which has the assembly routines -changes to cpu.h, cpu.c, and stream_decoder.c to enable them -changes to configure.in to support the new cpu stuff -a preliminary Makefile.am -maybe something else I'm forgetting Now automake complains that configure.in

On Fri, 21 Feb 2003, Jason Lunz wrote: > Try oprofile. It's more accurate than gprof, and it doesn't require you > to recompile the source you're profiling. That looks like a nice piece of software, but it appears to be specific to Linux-x86, so I don't think it will be much help in profiling Altivec code. :) -- Brady Patterson (brady@spaceship.com) Do you know Old

On Fri, 21 Feb 2003, Miroslav Lichvar wrote: > No, 1 <= order <= 32. There is -l option :). Indeed. For some reason I decided to debug an optimized build, which for some reason was showing order being off by a factor of 4. Thus it appeared that order%4 == 0 in that case, when actually it wasn't. Needless to say I've turned off optimization for the time being, which I should

Here's what I listed in that email. Merging doesn't appear to be necessary. If you have any build problems, let me know. Note that my detection code is Darwin-specific. It's a BSD call (sysctl()), so a change to the platform-detection macros should enable it to work on other BSDs. However, I don't know what that would be, and I couldn't determine any safe way to do the check

On Thu, 27 Jan 2005, John Steele Scott wrote: > That looks fine to me as well. However, the best solution is something which > Luca suggested a few months ago, which is to use the functions defined in > altivec.h. These are C functions which map directly to Altivec machine > instructions. I am willing to help out, but I don't find the current lpc_asm.s > very easy to follow, and

On Thu, Feb 20, 2003 at 05:46:50PM -0600, Brady Patterson wrote: > I'm working on Altivec versions of some of the libFLAC functions. I figured > the best candidates would be those that had MMX/SSE/3dnow versions, and I > picked FLAC__lpc_restore_signal() to do first, since it's relatively simple. > > In stepping through some runs, it appears that 'order' mod 4 is

In case you cut and paste this, I think Matt meant argv[3] to be --tag=artist=%artist -- Brady Patterson (brady@spaceship.com) Do you know Old Kentucky Shark? On Sun, 25 May 2003, Matt Zimmerman wrote: > flac -o %o --tag=title=%artist --tag=album=%album --tag=title=%song > --tag=tracknumber=%track %f

finished hooking up the altivec stuff so it works in ProjectBuilder. I ran a test, doing a 'flac -t' on 400MB of files compresses at level 5. the runtime dropped from from 180 sec to 105 sec! once I get the latest autotools on my ibook I'll try and get asm compilation to work that way. Josh --- Josh Coalson <xflac@yahoo.com> wrote: > OK, checked it all in (only minor

Hi, I have been playing with Altivec, and I rewrote a couple of the routines in assembly. Looking at the archives, I noticed that there may already be some effort on this. Anyways... Right now, I have two routines working. They need to be cleaned up, made relocatable, and documented; otherwise, they seem to work fairly well. I see an overall ~27% speed improvement when encoding with the

--- Matt Zimmerman <mdz@debian.org> wrote: > On Tue, Jul 30, 2002 at 09:04:38PM -0500, Brady Patterson wrote: > > > The patch I submitted only reads AIFF files. I'm about to start > the patch to > > write AIFF files. > > > > To do so, we need a command-line option to specify AIFF. My > inclination is to > > add an option: > > > >

I've had this a long time but haven't submitted it yet. I've tried to mirror the ia32 setup, so there should be a new subdirectory src/libFLAC/ppc . The first two attachments go there. The third is a context diff for src/libFLAC/Makefile.am . I have some more modified files, which I figured I'd submit after the above are checked in and working for somebody other than me. If you

Hi. I want to add some code to flac and am having trouble building it out of cvs. I've had several problems, most of which were pretty easy to work around or had already been discussed here. But this one has me stumped (though I am admittedly new to autoconf, automake, and libtool). Here's the problem. autoconf does not see any definition for AC_PROG_LIBTOOL. There is such a

--- Brady Patterson <brady@spaceship.com> wrote: > > Brady, I would say for now, your proposal is fine. I am going > > to move flac to getopt soon... > > > > Matt, that would be cool if you wanted to take on the audiofile > > support. I have actually been waiting to ask you for that, > > waiting until I got the getopt support done, and the new > >

I always use --prefix, and it gets put in the right place (<prefix>/include/FLAC/assert.h), which I'm sure sheds no new light on this. I'd still like to know why FLAC__ASSERT() is necessary. K&R is very clear that the preprocessor is to remove calls to assert() if NDEBUG is defined. (Some compilers, including gcc, implicitly define NDEBUG when optimizing, but of course it can

brady@spaceship.com said: > Finally, in a more general context, is there an easy way to build for > profiling, or do I have to edit the makefiles? I'm using gcc and > gprof. Try oprofile. It's more accurate than gprof, and it doesn't require you to recompile the source you're profiling. Jason

Thanks. I was worried about the assembler invocation but it looks like you solved that problem. Smooth build on my pbook (G4, 10.2.8, gcc-3.3, ac-2.59, am-1.6.3). Only problem was lack of check for docbook-to-man; my patch is attachments 1-2. Not so smooth on my imac (G3, 10.2.8, gcc-3.3, ac-2.52, am-1.6.1; that's what came with the last 10.2-compatible dev tools). First problem: typo in

Okay, I deleted most of this thread, so I was waiting for another message to respond to, so unfortunately this will be out of place in the thread. This is in response to Miroslav's idea about variable block sizes. I may be a bit out of my league here as I'm just starting to look at how the actual encoding gets done. But it seems to me that you could make a decent guess about when

--- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > On Thu, Oct 17, 2002 at 09:51:02AM -0500, Brady Patterson wrote: > > ... But it seems to me that you could make a decent guess > > about when something "new" happens based on the second derivative > of the signal > > (where the first derivative is the difference between a given > sample and the

The patch I submitted only reads AIFF files. I'm about to start the patch to write AIFF files. To do so, we need a command-line option to specify AIFF. My inclination is to add an option: -ff { raw | wav | aif } In some sense, "-ff" is silly since it probably stands for "format format". Still, I think it's better than just "-f", since the first

Let me pass this on to the dev group. I haven't seen this but I never install to /usr. I would think that it should still end up in /usr/include/FLAC/assert.h... maybe automake is handling the file specially because of the name? Josh --- Kyle Sallee <cromwell@kublai.com> wrote: > It's installation overwrites /usr/include/assert.h > which is isntalled by glibc, thus causing