Re: [Flac-dev] liboggflac1 soname

2005-01-24 Thread Josh Coalson
--- Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
 On Mon, 10 Jan 2005, Ralph Giles wrote:
  As such it's an incompatible change, for which you should also
  zero the 'age' field. So 1.1.1-beta1 should have been 2:0:0,
  not 2:0:1.
 [...]
  Yes, I agree. The numbering is all about coexisting installs of the
 
  various versions.
 
 Ok.  I need to know what to do about this... is 1.1.2 with fixed
 sonames
 just around the corner?  What should we do to fix sonames in Debian?

OK, I am going to do a 1.1.2 earlier than I wanted in order to
fix this.  anyway there are some bug fixes and speedups that will
be of benefit.

because of the mess and since there have been API changes and
additions in both libFLAC and libOggFLAC since 1.1.1 I plan on
bumping all the libtool numbers as follows: current++, revision=0
age=0.  if this will cause problems please let me know.

I'll try to get this ready as soon as possible.

Josh




__ 
Do you Yahoo!? 
All your favorites on one personal page – Try My Yahoo!
http://my.yahoo.com 
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev


Re: [Flac-dev] liboggflac1 soname

2005-01-24 Thread Ralph Giles
On Mon, Jan 24, 2005 at 05:43:04PM -0800, Josh Coalson wrote:

 because of the mess and since there have been API changes and
 additions in both libFLAC and libOggFLAC since 1.1.1 I plan on
 bumping all the libtool numbers as follows: current++, revision=0
 age=0.  if this will cause problems please let me know.

That should resolve the issues. Thanks.

 -r
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev


Re: [Flac-dev] libFLAC bitbuffer optimizations

2005-01-24 Thread Josh Coalson
Eric, I finally got around to your patches after Miroslav's.
the first one (the memcpy/memset replacement) I had problems
with, one because the buffers can overlap so I had to use
memmove (is this usually assembly in libc too?) and also the
endpoints looked wrong, for my full patch see below. speedup
for me was around 3%

the second patch got another 2%.  a question though, why do
you have:

+  *(++vals);

in two places instead of just ++vals; ?

Josh


Index: bitbuffer.c
===
RCS file: /cvsroot/flac/flac/src/libFLAC/bitbuffer.c,v
retrieving revision 1.55
diff -u -r1.55 bitbuffer.c
--- bitbuffer.c 25 Jan 2005 02:37:08 -  1.55
+++ bitbuffer.c 25 Jan 2005 02:39:52 -
@@ -228,11 +228,27 @@

/* first shift the unconsumed buffer data toward the front as much
as possible */
if(bb-total_consumed_bits = FLAC__BITS_PER_BLURB) {
-   unsigned l = 0, r = bb-consumed_blurbs, r_end = bb-blurbs +
(bb-bits? 1:0);
+#if FLAC__BITS_PER_BLURB == 8
+   /*
+* memset and memcpy are usually implemented in assembly
language
+* by the system libc, and they can be much faster
+*/
+   const unsigned r_end = bb-blurbs + (bb-bits? 1:0);
+   const unsigned r = bb-consumed_blurbs, l = r_end - r;
+   memmove(bb-buffer[0], bb-buffer[r], l);
+   memset(bb-buffer[l], 0, r);
+#elif FLAC__BITS_PER_BLURB == 32
+   /* still needs optimization */
+   const unsigned r_end = bb-blurbs + (bb-bits? 1:0);
+   unsigned l = 0, r = bb-consumed_blurbs;
for( ; r  r_end; l++, r++)
bb-buffer[l] = bb-buffer[r];
for( ; l  r_end; l++)
bb-buffer[l] = 0;
+#else
+   FLAC__ASSERT(false); /* ERROR, only sizes of 8 and 32 are
supported */
+#endif /* FLAC__BITS_PER_BLURB == 32 or 8 */
+
bb-blurbs -= bb-consumed_blurbs;
bb-total_bits -= FLAC__BLURBS_TO_BITS(bb-consumed_blurbs);
bb-consumed_blurbs = 0;




__ 
Do you Yahoo!? 
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev