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

[Brian Willoughby]

I don't have time to look into this, at the moment. Hopefully, someone else on the list can lend a hand.

It's been about ten years since I wrote any new code using libFLAC, so it would take me a while to help find any problems with your code. Perhaps the holidays will afford some time.

Brian


On Dec 13, 2017, at 8:12 AM, Chris Barrett <cbarrett.colo at gmail.com> wrote:
> Thanks Brian.  I converted everything to libFLAC and got the same results.
> 
> [snip]
> 
> 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
>> >
>>