similar to: multi stream decode

Hello Everyone, I am using the opus 1.1 multistream APIs to encode a 5.1 surround stream on the server, stream it to client, decode it and capture the pcm data. I noticed that there was severe corruption/attenuation on one of the channels(specifically Back/Rear Right). This would appear to be the last channel in the stream. I am attaching an image of the PCM dumps from the original and the one

I'm using seekable_stream_decoder, And., this is my write_callback. I'm not getting the required output. The PCM i get is not the proper music. Am I doing something wrong here? FLAC__StreamDecoderWriteStatus AFLACStreamPlayer::StreamWriteCb ( const FLAC__SeekableStreamDecoder *decoder, const FLAC__Frame *frame, const FLAC__int32 * const buffer[], void *client_data) { int Channels,

Sorry, I am newbie. Sample codes are from https://github.com/oneman/libflac/tree/master/examples/cpp. I used FLAC__stream_decoder_process_single function but it still gives exception. Maybe I could not control read callback, you're right. I will check it and write result in this thread. Thanks for help. 2013/7/1 Martijn van Beurden <mvanb1 at gmail.com> > I'll top-post this

Hi, I am using the JitterBuffer. Since there is not so much documentation I think I dont use it in a correct way. All the packets are recieved (I control the sequence numbers) but the JitterBuffer often tells me he has no packet. I am using it in the following way: I am not sure if I use the ticks correctly but I think it can be set to 20(msec). It is set as a Member in my class and i

Martijn, I don't use any metadata when encoding and decoding. When I call *FLAC__StreamDecoderStateString[FLAC__stream_decoder_get_state(m_decoder)] * * * it returns FLAC__STREAM_DECODER_SEARCH_FOR_METADATA enum value. Is it an error ? 2013/7/2 Burak Or?un ?zkablan <borcunozkablan at gmail.com> > Hi again, > > I can not solve problem. I want to mention my source code, so

Thanks for your reply Jean-Marc! this was what I had before. But I decided to restructure it since the thread that plays the sound is a callback from the sound hardware, more or less an interrupt handler. For me it seems more reasonable to waste some memory for to save the decompressed Packet. While I write this I begin to think that it is possible I decompress Packets that are never used

For some reason the attachment did not go through. Re-attaching. From: Mukund Raman Sent: Wednesday, April 01, 2015 6:12 PM To: 'opus at xiph.org' Subject: Opus multi-stream/surround: Audio corruption on decoded content Hello Everyone, I am using the opus 1.1 multistream APIs to encode a 5.1 surround stream on the server, stream it to client, decode it and capture the pcm data. I

Hi, I am using the speex 1.0.4 library from Windows. I have posted my problem before but didn't get a solution. I am doing an VOIP project in which i am recording sound and streaming it to the peer. I wanted to encode and decode wav files that brought me to this site. I am recording sound in the following format:- m_WaveFormatEx.wFormatTag = WAVE_FORMAT_PCM;

I'm getting garbled playback with decoded fragments and I'm hoping someone here can point me in the right direction to correcting the problem. Essentially I'm capturing audio from the microphone. I stream it over the net, but for testing purposes with this API I'm just grabbing the whole chunk and encoding / decoding it right away and then updating the sound buffer for

Hi, I am back. Thanks everybody for their suggestions. Finally I could get something out of the decoder that makes sense. But the problem is it is highly noisy and the voice is not very clear. Normally without using the codec I get good audible sound through the Microphone. I'm using Speex version 1.1.6. I've also used 1.0.4 beforehand and experienced the same problem with it. 1.

Hi, I have one rtp packet with multiple frame inside e.g 6 speex frames. I packed those frames manually by concating them into a buffer(memcpy at certain array index). Then at the other side, i decode them in a while loop using speex_decode_int(), and hoping that this function will decode one frame at a time. But when i inspected nbBits, it seemed all of 6 frames decoded at once. I guess the

Whoops, left this message in my outbox. I managed to fix the problem. Apparently I was only copying 160 bytes (Frame Size) back into the audio stream when I should have been copying 320 (chars <-> shorts confused me there). Hence why I could hear myself yet it was distorted. Half the wav was missing =) To answer some of the other questions here, for any insight into what I'm doing:

I can't be totally sure what 'short' is on your platform, but if it's (probably) 16-bits, it looks like you're treating the samples in buffer[] as packed 16 bit numbers. but all samples in buffer[] are 32-bit signed integers in host order, regardless of the bits-per-sample of the frame. so to get them down to shorts (assuming they'll fit), do like: FLAC__int32 *

Hi again, I can not solve problem. I want to mention my source code, so you may answer easily. This is decoder init stream function. *FLAC__stream_decoder_init_stream(m_decoder, decoderReadCallback, NULL, NULL, NULL, NULL, decoderWriteCallback, NULL, decoderErrorCallback, input_pile_array);* * * Then, callbacks * * /// \brief read callback function of decoder FLAC__StreamDecoderReadStatus

(Sorry about the delay -- currently attending ICASSP) Hi, Haven't looked at all the details, but what's clearly wrong is that you need to put the *compressed* packets in the jitter buffer and decode them only when you _get() them. Jean-Marc David Feurle wrote: > Hi, > > I am using the JitterBuffer. Since there is not so much documentation I > think I dont use it in a

On 02-07-13 11:01, Burak Or?un ?zkablan wrote: > I don't use any metadata when encoding and decoding. When I call > > *FLAC__StreamDecoderStateString[FLAC__stream_decoder_get_state(m_decoder)] > * > * > * > it returns > > FLAC__STREAM_DECODER_SEARCH_FOR_METADATA > > enum value. Is it an error ? There is always metadata in a FLAC stream, for example, the

David Feurle wrote: > Thanks for your reply Jean-Marc! > > this was what I had before. > But I decided to restructure it since the thread that plays the sound is > a callback from the sound hardware, more or less an interrupt handler. > For me it seems more reasonable to waste some memory for to save the > decompressed Packet. While I write this I begin to think that it is

Yes, I have tried plain wav data with file and stream functions of decoder and encoder. They work succesfully. You're right about FLAC can't find the first block in stream, because I didn't add any metadata in stream. The documentation of FLAC says that metadata callback function is optional for stream function of decoder, so I didn't need adding metadata. Actually, I am sure