Displaying 20 results from an estimated 300 matches similar to: "[PATCH 1/3] Make FLAC__clz_soft_uint32 static."
2008 Mar 14
2
bitreader optimizations
Hi,
attached are patches that improve decoding speed a bit. The first
patch improves the bit scan macro used for decoding unary values, the
second one adds a GCC inline assembly for bswap and the third patch
replaces the read_rice_block function.
In my testing it turned out to be even faster than the _ia32_bswap
function. If the code produced by MSVC is faster as well, I'd suggest
to remove
2012 May 04
0
[PATCH] Optimize FLAC__bitreader_read_rice_signed
---
src/libFLAC/bitreader.c | 445 +++++++++++------------------------------------
1 files changed, 105 insertions(+), 340 deletions(-)
diff --git a/src/libFLAC/bitreader.c b/src/libFLAC/bitreader.c
index ae515a0..7ae086d 100644
--- a/src/libFLAC/bitreader.c
+++ b/src/libFLAC/bitreader.c
@@ -755,379 +755,144 @@ FLAC__bool FLAC__bitreader_read_rice_signed(FLAC__BitReader *br, int *val, unsig
}
2008 Mar 17
0
bitreader optimizations
On Fri, Mar 14, 2008 at 07:36:31PM +0100, Miroslav Lichvar wrote:
> attached are patches that improve decoding speed a bit. The first
> patch improves the bit scan macro used for decoding unary values, the
> second one adds a GCC inline assembly for bswap and the third patch
> replaces the read_rice_block function.
The third patch has a bug causing reading past input buffer, attaching
2004 Dec 28
2
libFLAC bitbuffer optimizations
Pulled from my Arch archive, this following patch seems to have made
quite a difference in getting my ARM7TDMI chip to play FLAC (compression
levels 0-2) on my ipod. I don't have benchmarks with hard numbers, but
playing with skips vs playing without skips is a fairly noticeable
difference.
memcpy and memset on uClibc are optimized in asm for the ARM7TDMI in
uClibc. Other hardware/libc
2004 Sep 10
4
bitbuffer optimizations
Ok, here is a patch waiting for new CVS :). It works fine for me, but
please check it before commiting...
--
Miroslav Lichvar
-------------- next part --------------
--- src/libFLAC/bitbuffer.c.orig 2003-01-30 17:36:01.000000000 +0100
+++ src/libFLAC/bitbuffer.c 2003-01-30 21:53:18.000000000 +0100
@@ -51,6 +51,25 @@
*/
static const unsigned FLAC__BITBUFFER_DEFAULT_CAPACITY = ((65536 - 64) *
2012 May 09
1
[PATCH 2/2] bitmath: Finish up optimizations
This patch adds support for other compilers and systems
including MSVC, Intel C compiler etc..
---
src/libFLAC/bitmath.c | 48 -------------
src/libFLAC/bitreader.c | 54 ++-------------
src/libFLAC/include/private/bitmath.h | 120 ++++++++++++++++++++++++++++++---
3 files changed, 116 insertions(+), 106 deletions(-)
diff --git a/src/libFLAC/bitmath.c
2013 Mar 03
5
Fwd: flac 1.3.0pre1 prelease
Johnny Rosenberg wrote:
> Maybe a stupid question, but I was born stupid and I have walked that
> path ever since, so: Is there a changelog?
The only changelog is the git changelog. I will be writing a real
changelog to go in the actual release tarball before the official
release.
The git changelog is available here:
https://git.xiph.org/?p=flac.git;a=summary
or in any git clone of
2008 Jun 14
1
[Flac] Ogg Codecs 0.80.15035
Hi all,
I've made a test release for Ogg DirectShow Codecs.
You can find it here:
http://www.xiph.org/dshow/uploads/Main/oggcodecs_0.80.15035.exe
The problem is that I get a HEAP Corruption detected at:
void FLAC__bitreader_free(FLAC__BitReader *br)
{
FLAC__ASSERT(0 != br);
if(0 != br->buffer)
free(br->buffer);
The call stack is:
>
2008 Jun 14
1
Ogg Codecs 0.80.15035
Hi all,
I've made a test release for Ogg DirectShow Codecs.
You can find it here:
http://www.xiph.org/dshow/uploads/Main/oggcodecs_0.80.15035.exe
The problem is that I get a HEAP Corruption detected at:
void FLAC__bitreader_free(FLAC__BitReader *br)
{
FLAC__ASSERT(0 != br);
if(0 != br->buffer)
free(br->buffer);
The call stack is:
>
2017 Jan 19
4
[PATCH] Fix cppcheck warnings
---
src/libFLAC/bitreader.c | 4 ++--
src/libFLAC/bitwriter.c | 4 ++--
src/plugin_xmms/plugin.c | 2 +-
src/share/utf8/charset.c | 1 +
src/test_libFLAC++/encoders.cpp | 8 ++++----
src/test_libFLAC/decoders.c | 4 ++--
src/test_libFLAC/encoders.c | 8 ++++----
7 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/src/libFLAC/bitreader.c
2005 Jan 01
2
libFLAC bitbuffer optimizations
Josh Coalson <xflac@yahoo.com> wrote:
> thanks for the patch.
No prob :)
> 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.
This is Miroslav's patch, from the mailing list post I dug up in the archives:
--- orig/src/libFLAC/bitbuffer.c
+++
2012 Apr 05
1
[PATCH] remove unnecesary typedef in bitwriter.c
---
src/libFLAC/bitwriter.c | 31 +++++++++++++++----------------
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/src/libFLAC/bitwriter.c b/src/libFLAC/bitwriter.c
index 651440d..7da4b15 100644
--- a/src/libFLAC/bitwriter.c
+++ b/src/libFLAC/bitwriter.c
@@ -43,12 +43,11 @@
/* Things should be fastest when this matches the machine word size */
/* WATCHOUT: if you change this
2013 Mar 03
3
Fwd: flac 1.3.0pre1 prelease
Ben Allison wrote:
> There's a more few issues for compiling on MSVC. I put together a patch.
>
> Here's a quick rundown:
> * must use __inline keyword with static inline functions (bitmath.h)
If you include "share/compath.h" you will get a inline #defined as __inline
when _MSC_VER is defined. I'd prefer a single diffinition of that in one
place and one place
2012 Nov 06
0
[LLVMdev] [PATCH] basic reading reloc visitor for x86_64 ELF
On Mon, Nov 5, 2012 at 5:17 PM, Eric Christopher <echristo at gmail.com> wrote:
> For llvm-dwarfdump we need to handle relocations inside the debug info
> sections in order to successfully dump the dwarf info including strings.
> Nick sent out a partial patch that did this not too long ago and I've taken
> it and gone in a bit of a different direction, but kept the same basic
2012 Nov 06
2
[LLVMdev] [PATCH] basic reading reloc visitor for x86_64 ELF
For llvm-dwarfdump we need to handle relocations inside the debug info
sections in order to successfully dump the dwarf info including strings.
Nick sent out a partial patch that did this not too long ago and I've taken
it and gone in a bit of a different direction, but kept the same basic
architecture.
In place of applying the relocations to the data we've read from disk I'm
keeping
2012 Apr 07
1
[PATCH 2/2] Update and improve autotools build
- INCLUDES is deprecated, and CPPFLAGS is an user-defined
variable, use the proper AM_CPPFLAGS instead
- Remove FLAC__INLINE definition, providing proper
replacement for MSVC compilers.
- Detect if we have C99 's lround and provide a replacement
for windows...
---
configure.ac | 32 ++++++++--------------------
examples/c/decode/file/Makefile.am
2008 Jun 14
0
[Flac] Ogg Codecs 0.80.15035
Cristian Adam wrote:
> Hi all,
>
> I've made a test release for Ogg DirectShow Codecs.
> You can find it here:
> http://www.xiph.org/dshow/uploads/Main/oggcodecs_0.80.15035.exe
>
> The problem is that I get a HEAP Corruption detected at:
>
> void FLAC__bitreader_free(FLAC__BitReader *br)
> {
> FLAC__ASSERT(0 != br);
>
> if(0 != br->buffer)
2002 Aug 06
3
hard to believe speed difference
First, I love R and am grateful to be using this free and extremely
high quality software.
Recently I have been comparing two algorithms and naturally I
programmed in R first. It is so slow that I can almost feel its pain.
So I decided to do a comparison with Java. To draw 500,0000 truncated
normal, Java program takes 2 second and R takes 72 seconds. Not a
computer science major, I find it hard
2004 Sep 10
3
1.0 source candidate
On Fri, Jul 20, 2001 at 08:14:55PM -0700, Josh Coalson wrote:
> --- Matt Zimmerman <mdz@debian.org> wrote:
> > On Fri, Jul 20, 2001 at 10:51:11PM -0400, Matt Zimmerman wrote:
> >
> > > This version seems to work at least partially on ia64. I am able
> > to encode my
> > > usual test WAV file now, but I still get a segfault during the
> >
2012 Nov 05
25
[PATCH] IOMMU: don't disable bus mastering on faults for devices used by Xen or Dom0
Under the assumption that in these cases recurring faults aren''t a
security issue and it can be expected that the drivers there are going
to try to take care of the problem.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -625,6 +625,18 @@ static void parse_event_log_entry(struct