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 about network data transferring is good, there is no problem, i have tested so much and observed all data has transmitted at every time. I suspend that sync problem occurs from network latency. Do you have any idea about this? If read callback may sleep or process more than excepted time, does sync lost? 2013/7/2 Martijn van Beurden <mvanb1 at gmail.com>> 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 samplerate, > number of channels used, FLAC encoder version etc. This is called the > STREAMINFO block. This is the very first block of the stream. This state > tells that the decoder is still looking for that block. > > So it seems there's something wrong in the data transfer, as FLAC can't > find the first block in the stream. I can think of three things: there is > no data received at all (because there is something wrong with the > connection or because it isn't sent at all), the data transferred is > corrupted/transformed somewhere or there is something wrong in the process > of reading data from the network stream. > > Have you tried plain wav data first? That's a lot easier to troubleshoot, > you can make sure the problem is not in the network-related stuff. > > _______________________________________________ > flac-dev mailing list > flac-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > >-- Burak Or?un ?ZKABLAN Computer Science Engineer Mobile : 0 541 302 18 78 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20130702/2209c9df/attachment.htm
On 02-07-13 16:13, Burak Or?un ?zkablan wrote:> Yes, I have tried plain wav data with file and stream functions of > decoder and encoder. They work succesfully.Okay, so that's not the problem. Clear.> 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.There is metadata, whether you add it or not. I'm not talking about data you might add, like a title, tracknumber or trackname, but data that is in the STREAMINFO block. That is mandatory and added by the FLAC encoder, even if you don't specify any callbacks.> Actually, I am sure about network data transferring is good, there is > no problem, i have tested so much and observed all data has > transmitted at every time. I suspend that sync problem occurs from > network latency. Do you have any idea about this? If read callback may > sleep or process more than excepted time, does sync lost?Maybe, can't tell. I'm not really a programmer, I just know a little about the FLAC format, so at this point I can't help you anymore. Maybe someone else on this list.
The read callback can take as long as it wants (it's blocking, after all). It's almost definitely something wrong with your read callback code. Without the full source, it's hard to know exactly what. A few guesses, in no particular order. 1) Maybe you are reading in a loop and forgetting to increment the byte buffer pointer (continuously writing to the beginning of the buffer) 2) Maybe you are forgetting to set *bytes on output, or are writing an incorrect value 3) Maybe you are returning something other than FLAC__STREAM_DECODER_READ_STATUS_CONTINUE> 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 about network data transferring is good, there is no > problem, i have tested so much and observed all data has transmitted at > every time. I suspend that sync problem occurs from network latency. > Do you have any idea about this? If read callback may sleep or process > more > than excepted time, does sync lost?
Thank you so much for polite help Martijn.
Allison,
My read callback function is just ;
* /// \brief read callback function of decoder*
* FLAC__StreamDecoderReadStatus decoderReadCallback( const
FLAC__StreamDecoder *decoder, FLAC__byte buffer[], size_t *bytes, void
*callback_param)*
* {*
* // mutex lock*
* m_mutex.lock();*
*
*
* // copy buffer array to m_pile_array*
* if(input_pile_size > 0) {*
* memcpy(input_pile_array, buffer, input_pile_size);*
* *bytes = input_pile_size;// = 0;*
*
*
* // mutex unlock*
* m_mutex.unlock();*
*
*
* return FLAC__STREAM_DECODER_READ_STATUS_CONTINUE;*
* }*
*
*
* // mutex unlock*
* m_mutex.unlock();*
*
*
* return FLAC__STREAM_DECODER_READ_STATUS_ABORT;*
* }*
*
*
input_pile_array is encoded audio data from network, input_pile_size is
size of encoded data size. Both of them are transmitted over network from
client to server.
I haven't known that I should increment buffer pointer, I have always write
data at beginning of buffer. I think, error arise from increment?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/flac-dev/attachments/20130702/63daac16/attachment-0001.htm