Hi Josh,
As you know, I'm writing a FLAC ACM codec using libFLAC. The Audio Codec
Manager sends messages to the driver with blocks of data to be converted. I
think it will be much easier to decode the data if we could use
FLAC__stream_decoder_process_whole_stream() to process the first message,
not processing any data that don't make a whole frame, and then use
FLAC__stream_decoder_process_remaining_frames() to process all remaining
messages, again not processing any data that don't make a whole frame,
except for the last message. For doing that, a possible solution could be
permit the decoder in the state FLAC__STREAM_DECODER_ABORTED to respond
FLAC__stream_decoder_process_remaining_frames() like the state
FLAC__STREAM_DECODER_SEARCH_FOR_FRAME_SYNC. The new code in
FLAC__stream_decoder_process_remaining_frames() would be:
...
while(1) {
switch(decoder->protected->state) {
case FLAC__STREAM_DECODER_ABORTED:
case FLAC__STREAM_DECODER_SEARCH_FOR_FRAME_SYNC:
...
That's a suggestion, but any solution that permit us to continue a stopped
decoding will do the job. Maybe a new stopped state.
Another thing: Is there a reason for FLAC__stream_decoder_set_client_data()
and FLAC__stream_encoder_set_client_data() returning false if the state
isn't FLAC__STREAM_DECODER_UNINITIALIZED or
FLAC__STREAM_DECODER_UNINITIALIZED? I do not understand why is that, because
it has nothing to do with the encoding process (it's client data!).
Regards,
Daniel
--- Daniel Souza <danielrsouza@hotmail.com> wrote:> Hi Josh, > > As you know, I'm writing a FLAC ACM codec using libFLAC. The Audio > Codec > Manager sends messages to the driver with blocks of data to be > converted. I > think it will be much easier to decode the data if we could use > FLAC__stream_decoder_process_whole_stream() to process the first > message, > not processing any data that don't make a whole frame, and then use > FLAC__stream_decoder_process_remaining_frames() to process all > remaining > messages, again not processing any data that don't make a whole > frame, > except for the last message. For doing that, a possible solution > could be > permit the decoder in the state FLAC__STREAM_DECODER_ABORTED to > respond > FLAC__stream_decoder_process_remaining_frames() like the state > FLAC__STREAM_DECODER_SEARCH_FOR_FRAME_SYNC. The new code in > FLAC__stream_decoder_process_remaining_frames() would be: > ... > while(1) { > switch(decoder->protected->state) { > case FLAC__STREAM_DECODER_ABORTED: > case FLAC__STREAM_DECODER_SEARCH_FOR_FRAME_SYNC: > ... > That's a suggestion, but any solution that permit us to continue a > stopped > decoding will do the job. Maybe a new stopped state.hmm... I'm not too familiar with how ACM codecs work but it sounds analogous to the situation in the winamp or XMMS plugins. in that case I use an intermediate reservoir on the output, where I think in your case you would have to have one on the input. I have a hunch that just aborting and picking up again would not work because of the internal buffering in the stream decoder but I will look into it.> Another thing: Is there a reason for > FLAC__stream_decoder_set_client_data() > and FLAC__stream_encoder_set_client_data() returning false if the > state > isn't FLAC__STREAM_DECODER_UNINITIALIZED or > FLAC__STREAM_DECODER_UNINITIALIZED? I do not understand why is that, > because > it has nothing to do with the encoding process (it's client data!).umm... trying to remember... the answer is probably that there was a reason originally, but there isn't one now. I'll investigate that too. Josh __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com
--- Josh Coalson <xflac@yahoo.com> wrote:> --- Daniel Souza <danielrsouza@hotmail.com> wrote: > > Another thing: Is there a reason for > > FLAC__stream_decoder_set_client_data() > > and FLAC__stream_encoder_set_client_data() returning false if the > > state > > isn't FLAC__STREAM_DECODER_UNINITIALIZED or > > FLAC__STREAM_DECODER_UNINITIALIZED? I do not understand why is > that, > > because > > it has nothing to do with the encoding process (it's client data!). > > umm... trying to remember... the answer is probably that > there was a reason originally, but there isn't one now. > I'll investigate that too.OK, looking back on this, the reason is that all the data the client is supposed to set in the decoder instance, the instance expects to be set before starting decoding. in the case of client data, you are right, it really does not matter to the decoder if it changes later. it is more for the appearance of having a consistent policy for the client. it's easy to get around this in the client, but I'll keep it in mind for 1.1.x Josh __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com