similar to: bitpack error message

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);

hi, I tried to encode the voice data read from AudioQueue and then decode it. There was nothing but rhythm left, it sounds like robot's voice, but I cannot recognize any word. The app was compiled by XCode 4.1. Speex 1.0.5 and 1.2.rc1 gave the same result. When compiling speex 1.0.5, I added them to Xcode project, set the Header Search Paths, then compiled successfully. When compiling speex

Hi All, I'm very new to speex and in fact handling audio at all, it seems I have run in to a problem I seem unable to fix. I'm trying to take audio from a microphone using alsa, then encode it as speex and save to disk. I have been wondering if it has something to do with endian type, but speexenc and speexdec works fine. Currently I have the following setup: Platform:

While browsing the code I came across line 83 bitpack.c: *_ret=((ret&0xFFFFFFFFUL)>>(m>>1))>>(m+1>>1); Is there any reason why this is so convoluted? Maybe endianess or 64 bit issues? If I'm not mistaken it does exactly the the same as: *_ret = ret >> m; Cheers, Nils

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, Sorry! Marc Gimpel. I wrote it in a false thread before. It was my first time. :-) I have to write a small programm which should be able to record speeches and in addition synchronize the recorded speeches with measuring data. My idea is to record the speech in the normal way with speex and without ogg. If a sync message was received, i write a custom in-band messages using mode 13

Just got around to compiling RC3 under beos and came across an anomaly when using managed bitrates. I haven't changed the code for the beos encoder but I now get double the bitrates so vorbis_encode_init(&vi,mediaFormat.u.raw_audio.channel_count,(long)mediaFormat.u.raw_audio.frame_rate , -1, 128000, -1); now gives me vorbis files that average around 325 - 350. Is this now the correct

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

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

> -----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:

We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ is not set but one of features depending on it is. That's not a friendly way to report errors to hypervisors. Let's check, and fail probe instead. Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: Cornelia Huck <cornelia.huck at de.ibm.com> Cc: Wanlong Gao <gaowanlong at cn.fujitsu.com> Signed-off-by: Michael S. Tsirkin

We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ is not set but one of features depending on it is. That's not a friendly way to report errors to hypervisors. Let's check, and fail probe instead. Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: Cornelia Huck <cornelia.huck at de.ibm.com> Cc: Wanlong Gao <gaowanlong at cn.fujitsu.com> Signed-off-by: Michael S. Tsirkin

In short try calling speex_encode_int and speex_decode_int. The calls to speex_encode and speex_decode expects the data to be a floating point values. The data is passed by pointer and the compiler does not do the conversion. This is why you are getting the segfault on decode as the short is 16-bits and a standard float is 32-bits. Tom -----Original Message----- From:

From googling around, it seems that the ogg bitpacker has defined endianness, but I can't find anywhere that says which order it's in. Any help? The endianness of the 24 bit field in the OggPCM header should be specified. I was going to edit the wiki to specify it as network byte order, then realized that you may have standardized on something else in theora/vorbis already.

Michael Smith wrote: > libogg has two bitpackers; a little endian one and a bigendian one. ok, I didn't see it in the docs at http://www.xiph.org/ogg/doc/libogg/reference.html and didn't look in the header file first. My bad. Is it correct to state that the oggpack_* functions use little endian order, and the oggpackB_* functions use big endian order? Is it safe to mix calls to

Hi Tom, Thanks for your reply, I'm having a few difficulty's following you advise. You mention that I should be calling 'speex_encoder_int' & 'speex_decoder_int', I'm having problems finding these functions in the speex header. I am currenlty calling speex_encoder_init & speex_decoder_init in my test code, I have repeated the relevent bits of the example

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