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

[Chris Barrett]

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

decoder:
[29.009735] HandleChanDataMsg, start: 1
[29.009773] SetAudioTimer, total: 1200, holdoff: 585
<process_single_frame called here>
[29.009792] read_callback, size: 146
[29.009809] error_callback, status: 0
[29.009821] read_callback, size: 146
[29.009834] read_callback, size: 146
[29.009844] read_callback, size: 146
[29.009855] read_callback, size: 146
... <calls read_callback forever>

I can send out some of the code fragments if needed.

Thanks,
Chris

On Tue, Dec 12, 2017 at 4:44 PM, Brian Willoughby <brianw at audiobanshee.com>
wrote:

> Hi Chris,
>
> Have you tried the Standard C libflac option? Not that I have anything
> against the C++ flavor, but I've only ever worked with the C API, to keep
> things simple. Sorry for the brief response, but I wanted to reply quickly.
>
> Brian
>
>
> On Dec 12, 2017, at 1:51 PM, Chris Barrett <cbarrett.colo at gmail.com>
> wrote:
> > I'm trying to use libflac++ on a live internet audio stream.  I don't
> see anything mentioned in the documentation that suggests this should not
> be possible, so I hope I'm not chasing down the wrong path (two weeks in).
> >
> > The encoder seems to be working fine and creates data for the
> write_callback, which I have coded to packetize that data and send it
> across the network.
> >
> > The question is how the decoder at the receiver should operate.
> Ideally, when a packet arrives, it can be fed to the decoder.  When the
> decoder has enough data for a new uncompressed frame, it returns one.
> >
> > But the decoder API does not seem setup for this type of synchronous
> operation.  When a packet arrives, I'm trying to call process_single_frame
> and then supply the packet data in the read_callback.  It takes the data
> but always calls the read_callback again for more data.  It does call
> error_callback (status == 0) once, but never write_callback.  So, I'm
> guessing that the packet does not have enough data for a frame.
> >
> > So, I tried queueing write_callbacks at the encoder before packetizing
> it and sending it.  It seems like encoder init causes three write_callbacks
> that make up the metadata, and then each call to process causes one
> write_callback that is presumably the frame data.  The documentation states
> that one cannot rely on this, but I can't see any other choice.  Just to be
> safe, I let the metadata and the first four frames queue up before sending
> it.  Still the decoder asks for more data when I call process_single_frame
> with this data and never calls write_callback.  I don't have the decoder
> meta callback installed, but could try that to test if it is at least
> decoding the metadata.
> >
> > Any help is greatly appreciated.
> >
> > Thanks,
> > Chris
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20171213/c0a8005a/attachment.html>