similar to: Encoder crash in multithreading processing

Hi, We are testing CELT 0.7.1 on an iPod touch and it seems we are already reaching the CPU limit of the machine for a 1 channel both directions stream. The CELT README says that the code should be compiled with fixed-point support, but it it not clear how it has to be used later on. We currently use celt_encode_float/celt_decode_float functions. Can we still use them with the fixed point version

Is this a common warning? The decoder doesn't return an error on it, but I see it a lot in my test application on windows. It is non existent on my linux box. I haven't tried mingw yet. please note that I'm using visual studio 2008 w/the vcproj that Bjoern Rasmussen made for 0.5.2 (w/some file references removed) at the moment and it is giving a lot of C4554 warnings

Hi all, I''ve added some critical section methods to the Windows::Synchronize module in the windows-pr library (in CVS). Looking at the RUBY_CRITICAL macro from rubysig.h, it basically looks like this (in pure Ruby): def RUBY_CRITICAL(&block) critical_section = [0].pack(''L'') InitializeCriticalSection(critical_section)

--- libcelt/Makefile.am | 6 +- libcelt/bands.c | 26 +++++++++- libcelt/bands.h | 2 +- libcelt/celt.c | 23 +++----- libcelt/pgain_table.h | 133 ------------------------------------------------- libcelt/quant_pitch.c | 117 ------------------------------------------- libcelt/quant_pitch.h | 44 ---------------- 7 files changed, 37 insertions(+), 314

--- libcelt/bands.c | 43 ++++++++++++++++++++++++------------------- libcelt/bands.h | 6 ++---- libcelt/celt.c | 6 ++---- 3 files changed, 28 insertions(+), 27 deletions(-) diff --git a/libcelt/bands.c b/libcelt/bands.c index d0c3498..315cce8 100644 --- a/libcelt/bands.c +++ b/libcelt/bands.c @@ -247,23 +247,6 @@ void compute_pitch_gain(const CELTMode *m, const celt_norm_t *X, const

As part of my effort to replace our hand-rolled mutexes with std::mutex and std::recursive_mutex, I found that many of the tests were failing on Windows after doing the replacement. One of the reasons was due to the use of a mutex in lib\Support\CrashRecoveryContext.cpp. If this mutex is an std::recursive_mutex or std::mutex, tests fail. If this mutex is a windows CRITICAL_SECTION, the tests

> (PS, if you do use threads, protect speex_jitter_put/get with a mutex > (CRITICAL_SECTION I believe they're called in Win32Speak) -- calling put > and get at the exact same time from different threads leads to "features") I've never tested this, but I designed the jitter buffer to work from two threads even without using a mutex. This would work as long as there is

Hi everyone, I've just changed the API for CELT, but at least there's a good reason for that. It's now possible to use the same mode data for both mono and stereo. So here's the change: - The celt_mode_create() function has a "channels" parameter - The celt_encode_create() and celt_decoder_create() functions now have an additional "channels" parameter. - I

Hi I minor issue I noticed when I passed an invalid 'channels' parameter to celt_encoder_create() is that celt_encoder_init() doesn't free the CELTEncoder ('st' parameter) when 'if (channels < 0 || channels > 2)' evaluates to true. Seems celt_encoder_init() should do like this instead: CELTEncoder *celt_encoder_init(CELTEncoder *st, const CELTMode *mode, int

Thank you for a very good explanation which shed light on some of the questions that I had after reading the source code. Reading your text however, I wonder if I'm perhaps missing an important point on the proper use of the jitter buffer: ... > Now, clearly, if early_ratio is high and late_ratio is very > low, the buffer is buffering more than it needs to; it will > skip a frame

Good Day, dear wine users :) . I am the developer of program, which must work under Wine and Windows. it has two threads, and these threads use one function to add text to Rich text box. When they try to add texts in parallel, a mixed text appear. So I decided to use critical section. When main thread tries to add text, the text adds perfectly, but when the second thread tries to add text - it

# make make all-recursive make[1]: Entering directory `/tmp/celt-0.7.0' Making all in libcelt make[2]: Entering directory `/tmp/celt-0.7.0/libcelt' /bin/sh ../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -s -O3 -march=i686 -fvisibility=hidden -W -Wstrict-prototypes -Wall -Wextra -Wcast-align -Wnested-externs -Wshadow -Wno-parentheses

Hi guys, I'm currently working on a CELT implementation for FMOD, and one of the things we want to do is have all memory required allocated beforehand. This is before we have any information about what sounds will be played. We would like to create all of our CELTDecode instances up front. Because celt_mode_create() requires a sample rate and number of channels passed in, this

Hi, I was checking complexity modes of CELT 07.1 encoder. If i got it correctly everything is driven by pitch_available variable set in celt_encoder_create function. By default it's set to 1 hence high complexity mode is used all the time. I tried to disable it and although i couldn't hear any particular difference in the decoded audio quality, the cycle count of the encoder dropped

The Wine development release 1.7.21 is now available. What's new in this release (see below for details): - Support for critical sections in the C runtime. - Unicode data updated to Unicode 7.0. - Support for interlaced PNG encoding. - Initial stub for the Packager library. - Various bug fixes. The source is available from the following locations:

>> (PS, if you do use threads, protect speex_jitter_put/get with a mutex >> (CRITICAL_SECTION I believe they're called in Win32Speak) -- calling put >> and get at the exact same time from different threads leads to "features") > > I've never tested this, but I designed the jitter buffer to work from > two threads even without using a mutex. This would

> Thank you for a very good explanation which shed light on some of the > questions that I had after reading the source code. > > Reading your text however, I wonder if I'm perhaps missing an important > point on the proper use of the jitter buffer: > > ... >> Now, clearly, if early_ratio is high and late_ratio is very >> low, the buffer is buffering more than

Hello, The way you describe how the jitter buffer should be implemented makes me wonder: How does the jitter buffer works when there is no transmission? Let's say my "output" thread gets a speex frame from the jitter buffer every 20ms. What happen when there is no frame that arrived on the socket? No frames at all for a pretty long time (ie many seconds). This is my case because I

Got this today. Please take a look and let me know what you think. - Dan ---------- Forwarded message ---------- From: Kevin Burge <kevin.burge at systemware.com> Date: Dec 7, 2006 6:45 AM Subject: win32-service problems with patch To: djberg96 at gmail.com Hi Daniel, Thanks for win32-service. In the process of using it for running a reliable-msg (drb) server and clients, I had some

The Wine maintenance release 3.0.5 is now available. What's new in this release (see below for details): - Various bug fixes The source is available from the following locations: https://dl.winehq.org/wine/source/3.0/wine-3.0.5.tar.xz http://mirrors.ibiblio.org/wine/source/3.0/wine-3.0.5.tar.xz Binary packages for various distributions will be available from: