similar to: SPEEX_SET_USER_HANDLER once again

hello, i switched to use the encoder.processData() and encoder.getProcessedData() of jspeex. however it looks to me like a memory leak ... memory usage is increasing very fast and there is no visible stop ... after about five minutes java.lang.OutOfMemory occurs. I think it must be the jspeex component, because before i added jspeex to my app usage was constant at about 5mb. is it possible

Hi, I think what happened is that you did not write the "message" length. With user-callbacks, you also need to say how large the message. The size is in bytes and encoded in 4 bits. Besides, you're probably the first one to use user-callbacks. BTW, why didn't you want to use Ogg. It's much simpler to use and overhead can be made minimal anyway. Jean-Marc Le ven

Jean-Marc wrote: >I think what happened is that you did not write the "message" length. >With user-callbacks, you also need to say how large the message. The >size is in bytes and encoded in 4 bits. I wonder what is correct. Inside speex the documentation was written that the size in byte is encoded within 5 bit. I changed the code in both ways, but it doesn't work

Le ven 07/11/2003 à 13:37, Norman Biehl a écrit : > Jean-Marc wrote: > > >I think what happened is that you did not write the "message" length. > >With user-callbacks, you also need to say how large the message. The > >size is in bytes and encoded in 4 bits. > > I wonder what is correct. Inside speex the documentation was written > that the size in byte

>I guess you'll need to somehow trace what's happening. > >> >Besides, you're probably the first one to use user-callbacks. >> >> Oh, I feel honoured. :-) >> >> Why does it contain this feature if nobody uses it? I think it's a good >> and very flexible feature (if it works :-)). > >I thought it could be useful in some cases,

Hello, When I decode a recoded sound encoded by speex, it has too much noise. The noise is "slightly" reduced if I set the quality to 10. How do I get rid of this noise? The code is as follows. For encoding . state = speex_encoder_init ( &speex_nb_mode ); tmp = 7; speex_encoder_ctl ( state, SPEEX_SET_MODE, &tmp); // set quality tmp = 10; speex_encoder_ctl ( state,

In bits.c\speex_bits_pack there is logic to reallocate the bits buffer. In that section there is a call to speex_memset_bytes which appears to wipe out all the old bytes. I found when I encoded a multi-frame message that needed less than the default 2000 bytes for bits->chars, everything worked fine. However, when I encoded a longer message that triggered the realloc code in speex_bits_pack,

Hi, i have some code that gives me a "warning: Buffer too small to pack bits" mesage. looking at the libspeex source/bits.c i see the warning in a a function named speex_bits_pack. i'm not using this function. can someone tell me where this may be coming from since i've had a similiar problem before and had that fixed. i can't seem to pinpoint this one. thanks Greg

Hi, Jean-Marc Valin wrote: > Not sure I understand your question. Change the order of what within what? In cb_search, we iterate nb_subvect times over a codebook, finding nb_subvect codebook entries to quantize the excitation signal. After finding these nb_subvect codebook entries, they're written into the stream: /*save indices*/ for (i=0;i<nb_subvect;i++) {

Hello, just to make sure I haven't gotten anything wrong: In cb_search.c (function split_cb_search_shape_sign) after all that searching nb_subvect CB entries are being written into the stream. These are all taken from the same codebook. If I wanted to, I could just change their order, couldn't I? Because important is only the linear combination of them all together, which I keep

Hi, I'm moving my "metadata" which accompanies some of the speech packets into the speex bits. However, as usual, I'm a bit confused. The manual (PDF from current SVN), section 5.10 (bottom of page 21) states that: "Finally, applications may define custom in-band messages using mode 13. The size of the message in bytes is encoded with 5 bits, so that the decoder can

i don't think so. this is my current code: for(i=0; i<samples;i++){ /*only get max 320 bytes at a time so bits can handle*/ Client->raw_audio[i] = *input++; Client->temp_audio[i] = Client->raw_audio[i]; Client->session_File[ndx] = Client->temp_audio[i]; ndx+=1; } speex_bits_reset(&ebits);

> -----Message d'origine----- > De : Jean-Marc Valin [mailto:jean-marc.valin at usherbrooke.ca] > Envoy? : dimanche, 14. juin 2009 20:46 > ? : Stephane Lesage > Cc : speex-dev at xiph.org > Objet : Re: [Speex-dev] Resampler saturation > > Just to make sure I understand, the two patches you sent are > two different ways to fix the problem, with the only >

Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20060719/1f7ff5c0/signature.pgp

Jean-Marc Valin wrote: >>Heh. I guess after playing with different jitter buffers long enough, >>I've realized that there's always situations that you haven't properly >>accounted for when designing one. >> >> > >For example? :-) > > I have a bunch of examples listed on the wiki page where I had written initial specifications:

Hi all, recently I tried to add cover art to flac files and have dfficulties in doing so. FLAC__Metadata_Chain *chain = FLAC__metadata_chain_new(); if(0 == chain) return; if(!FLAC__metadata_chain_read(chain, filename)) return; FLAC__StreamMetadata *picture = FLAC__metadata_object_new(FLAC__METADATA_TYPE_PICTURE); FLAC__Metadata_Iterator *iterator = FLAC__metadata_iterator_new(); if(0 ==

another optimization you can do for packing bits together... the original one is : ------------------------------------------------------------------------------------------------------------- void speex_bits_pack(SpeexBits *bits, int data, int nbBits) { int i; unsigned int d=data; if (bits->bytePtr+((nbBits+bits->bitPtr)>>3) >= bits->buf_size) { //remain

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: maleout12may.wav Type: audio/wav Size: 95884 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20050524/57112d0c/maleout12may-0001.bin

Hi Jean-Marc, Hi Jim, I have also seen some problems with the 1.1.8 release on the C55x. So far I have boiled down the issues to the following: 1) We need our own "fixed_xx.h" header file. I don't know why, and haven't had time to investigate, but there is a definite improvement when I use the attached fixed_c55x.h file which has turned all the maths into inline functions.

Jean-Marc Valin wrote: >>OK, I'm actually about ready to start working on this now. >> >>If people in the speex community are interested in working with me on >>this, I can probably start with the speex buffer, but I imagine >>there's going to be a lot more work needed to get this where I'd like >>it to go. >> >> > >And where