Re: [flac-dev] using libflac++ on a live internet stream
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 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
Re: [flac-dev] using libflac++ on a live internet stream
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 [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 ... I can send out some of the code fragments if needed. Thanks, Chris On Tue, Dec 12, 2017 at 4:44 PM, Brian Willoughby 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 > 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
Re: [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 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 > 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 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
Re: [flac-dev] using libflac++ on a live internet stream
On Wed, 13 Dec 2017 09:12:43 -0700 Chris Barrett 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 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev