On Wed, 13 Dec 2017 09:12:43 -0700 Chris Barrett <cbarrett.c...@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 _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
