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.c...@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 <bri...@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.c...@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 >> > >> _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
