Support for Buffered Audio Data #2265
Open
+1,453
−394
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request adds the CLI flag
--buffered
, which allows the audio data to be loaded on-demand through an I/O buffer instead of all at once at the beginning. This provides an alternative resolution to the problem addressed in #2256. The default memory limit is dictated here, but shouldn't matter much since it's not a bottleneck.Support for buffered input also paves the way towards real-time tasks (#2): the changes were directly adapted from kentslaney/realtime-whisper, which already supports live PCM data. In order to keep the PR from being any larger than it already is, changes were limited to the minimum motivating feature. I'm making a PR instead of keeping it as a wrapper because it reuses/refactors large chunks of
transcribe
, which the current scoping makes inaccessible for patching.The buffered version will perform almost exactly the same set of operations, with a small (vanishing) difference in the preprocessing output. The log mel spectogram is clamped below to have a maximum range of 8. The original
transcribe
method computes the upper bound from the entire file's spectogram, while the buffered version clamps the values relative to the maximum in the chunks processed so far. I have done some regression testing to confirm that the refactored (non-buffered) solution will make the same calls as the existing one.I realize this is a rather large PR. Please let me know if these changes are outside the scope of the repo or if there's anything I can do to make it easier to review.