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>
Brian Willoughby
2017-Dec-13 20:21 UTC
[flac-dev] using libflac++ on a live internet stream
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 >> > >>
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 bytesI 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
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>