MP3Decoder: better handle indicating end of mp3 audio data to caller
The old formulation * wouldn't work if there were ID3 tags at the end * would choose whether to background-refill the inbuf based on a check before skipping to the next sync word, which could be incorrect. I think it was aspect "B" that ended up triggering the erroneous EOF problem fixed in the prior commit. This would depend on specific data sizes and offsets occuring in the file such that a read would be scheduled but then the buffer would be filled and left 100% full by find_sync_word(). It's just lucky(?) that a particular person produced such a file, and/or many files produced by Audacity have those characteristics.
This commit is contained in:
parent
1841af90e2
commit
df5f7bc765
@ -356,6 +356,11 @@ audioio_get_buffer_result_t audiomp3_mp3file_get_buffer(audiomp3_mp3file_obj_t *
|
|||||||
return GET_BUFFER_DONE;
|
return GET_BUFFER_DONE;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
self->samples_decoded += *buffer_length / sizeof(int16_t);
|
||||||
|
|
||||||
|
mp3file_skip_id3v2(self);
|
||||||
|
int result = mp3file_find_sync_word(self) ? GET_BUFFER_MORE_DATA : GET_BUFFER_DONE;
|
||||||
|
|
||||||
if (self->inbuf_offset >= 512) {
|
if (self->inbuf_offset >= 512) {
|
||||||
background_callback_add(
|
background_callback_add(
|
||||||
&self->inbuf_fill_cb,
|
&self->inbuf_fill_cb,
|
||||||
@ -363,8 +368,7 @@ audioio_get_buffer_result_t audiomp3_mp3file_get_buffer(audiomp3_mp3file_obj_t *
|
|||||||
self);
|
self);
|
||||||
}
|
}
|
||||||
|
|
||||||
self->samples_decoded += *buffer_length / sizeof(int16_t);
|
return result;
|
||||||
return mp3file_find_sync_word(self) ? GET_BUFFER_MORE_DATA : GET_BUFFER_DONE;
|
|
||||||
}
|
}
|
||||||
|
|
||||||
void audiomp3_mp3file_get_buffer_structure(audiomp3_mp3file_obj_t *self, bool single_channel_output,
|
void audiomp3_mp3file_get_buffer_structure(audiomp3_mp3file_obj_t *self, bool single_channel_output,
|
||||||
|
Loading…
Reference in New Issue
Block a user