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

2018-01-04 Thread Chris Barrett 
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 
wrote:

> 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

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

2017-12-13 Thread Richard Ash 
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

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

2017-12-13 Thread 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  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

2017-12-13 Thread 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

[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

2017-12-13 Thread Brian Willoughby 
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