[flac-dev] using libflac++ on a live internet stream

[Chris Barrett]

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.

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.

Thanks,
Chris



On Wed, Dec 13, 2017 at 3:04 PM, Richard Ash <richard at audacityteam.org>
wrote:

> On Wed, 13 Dec 2017 09:12:43 -0700
> Chris Barrett <cbarrett.colo at gmail.com> wrote:
>
> > Thanks Brian.  I converted everything to libFLAC and got the same
> > results.
> >
> > Here is some debug output
> > encoder:
> > [34.270050] FLAC encoder set succeeded
> > [34.271183] write_callback, frame: 0, samples: 0
> > [34.271282] write_callback, frame: 0, samples: 0
> > [34.271313] write_callback, frame: 0, samples: 0
> > [34.271351] FLAC encoder initialization succeeded
> > [34.356251] write_callback, frame: 0, samples: 4096
> > [34.441582] write_callback, frame: 1, samples: 4096
> > [34.526905] write_callback, frame: 2, samples: 4096
> > [34.612213] write_callback, frame: 3, samples: 4096
> > [34.697556] write_callback, frame: 4, samples: 4096
> > [34.697594] SendChanDataMsg: 146
> > [34.782898] write_callback, frame: 5, samples: 4096
> > [34.782936] SendChanDataMsg: 12
> > [34.868168] write_callback, frame: 6, samples: 4096
> > [34.868210] SendChanDataMsg: 12
> >
> > The audio is silence, so I believe there is a high compression ratio
> > ((4096 x 5) + metadata) -> 146 bytes
>
> I think this is your problem - the encoder is being so effective on
> digital silence input, that it isn't filling it's output buffer and so
> isn't pushing the packet out. If you send real audio (or even LSB
> dither noise) then it will fill the buffer and get going.
> I seem to remember a thread on this list complaining about this
> behaviour at some point in the past, to which the eventual work-around
> was mixing in some dither noise to digital silence stop the frames
> getting tiny.
>
> Richard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20180104/930077d7/attachment.html>