Re: [w3c/FileAPI] Define chunk size for `ReadableStream` created by `blob::stream()` (#144)

> However in step 4., I'm assuming that my wasm module will only ever need a buffer that's 0x10000 bytes in length.

The WASM module will need to handle to last bytes of the file anyway, therefore defining a chunk size for `blob::stream()` cannot be guaranteed to be any particular size due to 

> the chunk can be smaller, but only if it is the last amount of data being returned by the file.

particularly where the input is not always the same file.

Encountered a similar case where the value (`Uint8Array`) from `ReadableStream` can be any arbitrary `length` during the read, with the last read having a `length` of the remainder of the file.

There is also an edge case where if Disable cache is checked at Network tab at DevTools at Chromium operations that slice and splice the input into specific `length` can have unexpected results, i.e., the file is not sliced to the desired size https://bugs.chromium.org/p/chromium/issues/detail?id=1063524#c1. 

FWIW, the solution that am currently using https://github.com/guest271314/AudioWorkletStream/blob/master/audioWorklet.js#L10 to handle input to `AudioWorkletProcessor` from a `ReadableStream`, where the `value` is a `Uint8Array` that needs to be passed to `Uint16Array` (requires a `length` having a multiple of `2`), meaning it is necessary to `slice()` and `splice()` input, carry over the remainder until the next value is read and prepend the carried over values to the next `Uint8Array` until the `length` is a multiple of `2`. In `AudioWorkletProcessor` usies `Float32Array`s for input and output and where if the `Float32Array` set has a `length` _less_ than  `128` glitches and gaps in playback are observable due to the remainder of `Float32Array` being filled with `0`'s, or alternatively, when `length`  set is _greater_ than `128` a 

```RangeError: offset is out of bounds```

is thrown - which happens to occur when Disable cache is checked at Network tab at DevTools.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/144#issuecomment-602259884