When decoding flac, the min size is 16384. When such level is reached in streambuf, a decode for a single audio frame is made. That triggers the flac callback mechanism to call the following code to get data
This is fine as long as that callback returns enough data for flac to decode. It's unlikely to have frames of more than 16k. Now, should that happen, the callback is going to hammer us. It's fine on high CPU systems as the stream thread will find time to acquire more bytes and ultimately fill the streambuf, but that's not great. For lower CPU, that can be a deadlock
Now, I've observed that all the time for OggFlac and I'm pretty sure it's because the flac decoder tries to acquire a full Ogg page which easily can be larger than 16kB.
I've solved the issue by simply giving back CPU to the system in that callback
if (!end && !bytes) usleep(100 * 1000);
I don't know if you want a PR as this is less likely to happen on typical squeezelite targets.
When decoding flac, the min size is 16384. When such level is reached in streambuf, a decode for a single audio frame is made. That triggers the flac callback mechanism to call the following code to get data
This is fine as long as that callback returns enough data for flac to decode. It's unlikely to have frames of more than 16k. Now, should that happen, the callback is going to hammer us. It's fine on high CPU systems as the stream thread will find time to acquire more bytes and ultimately fill the streambuf, but that's not great. For lower CPU, that can be a deadlock
Now, I've observed that all the time for OggFlac and I'm pretty sure it's because the flac decoder tries to acquire a full Ogg page which easily can be larger than 16kB.
I've solved the issue by simply giving back CPU to the system in that callback
I don't know if you want a PR as this is less likely to happen on typical squeezelite targets.