<div dir="ltr">Following up on this thread to conclude and help others who may search the list in the future.  I was able to get streaming to work.  There were some things I got wrong on the integer format of the input samples to the encoder - that was my oversight.  But, there is one thing that might need to be improved with the library to cause less confusion.<div><br></div><div>On the decoder, I am using FLAC__stream_decoder_process_single.  This calls the read callback as expected.  I was returning the bytes to be decoded for the one frame and returning FLAC__STREAM_DECODER_READ_STATUS_CONTINUE, because it was just one frame and the stream was continuing.  What actually needs to be returned is FLAC__STREAM_DECODER_READ_STATUS_END_OF_STREAM...I guess because it means "that is all the bytes for this frame" in this context.  It doesn't seem intuitive and took me quite some time to figure out.  Possibly there needs to be another value added to this enum that can be used specifically for the single frame decode case.  Not sure.</div><div><br></div><div>Thanks,</div><div>Chris</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 13, 2017 at 3:04 PM, Richard Ash <span dir="ltr"><<a href="mailto:richard@audacityteam.org" target="_blank">richard@audacityteam.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, 13 Dec 2017 09:12:43 -0700<br>
Chris Barrett <<a href="mailto:cbarrett.colo@gmail.com">cbarrett.colo@gmail.com</a>> wrote:<br>
<br>
> Thanks Brian.  I converted everything to libFLAC and got the same<br>
> results.<br>
><br>
> Here is some debug output<br>
> encoder:<br>
> [34.270050] FLAC encoder set succeeded<br>
> [34.271183] write_callback, frame: 0, samples: 0<br>
> [34.271282] write_callback, frame: 0, samples: 0<br>
> [34.271313] write_callback, frame: 0, samples: 0<br>
> [34.271351] FLAC encoder initialization succeeded<br>
> [34.356251] write_callback, frame: 0, samples: 4096<br>
> [34.441582] write_callback, frame: 1, samples: 4096<br>
> [34.526905] write_callback, frame: 2, samples: 4096<br>
> [34.612213] write_callback, frame: 3, samples: 4096<br>
> [34.697556] write_callback, frame: 4, samples: 4096<br>
> [34.697594] SendChanDataMsg: 146<br>
> [34.782898] write_callback, frame: 5, samples: 4096<br>
> [34.782936] SendChanDataMsg: 12<br>
> [34.868168] write_callback, frame: 6, samples: 4096<br>
> [34.868210] SendChanDataMsg: 12<br>
><br>
> The audio is silence, so I believe there is a high compression ratio<br>
> ((4096 x 5) + metadata) -> 146 bytes<br>
<br>
</span>I think this is your problem - the encoder is being so effective on<br>
digital silence input, that it isn't filling it's output buffer and so<br>
isn't pushing the packet out. If you send real audio (or even LSB<br>
dither noise) then it will fill the buffer and get going.<br>
I seem to remember a thread on this list complaining about this<br>
behaviour at some point in the past, to which the eventual work-around<br>
was mixing in some dither noise to digital silence stop the frames<br>
getting tiny.<br>
<span class="HOEnZb"><font color="#888888"><br>
Richard<br>
</font></span></blockquote></div><br></div>