You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On ChromeOS, using the Linux subsystem the cpal library seems to work correctly and records audio. However if I request buffer size smaller than 1024 (I used 480 and 960 for single-channel, 48 kHz 10 ms or 20 ms chunks) I receive buffers of the requested size that result in incorrect audio when played back (the audio is shorter than expected, higher pitched and has artifacts). After much investigation it seems like those are 1024-buffers truncated to the requested size and the truncated data is lost (instead of being passed in the next callback invocation). Requesting buffers of size 480 leads to ~0.5x audio length, and 960 is almost okay (with just some artifacts), which led me to the 1024 bytes conclusion. If requested BufferSize is >= 1024 then all the audio data is received correctly.
In such cases it would be nice for cpal to report the minimal buffer size as 1024, as opposed to 1.
This is not reproducible on my other Linux machines, and I have no clue which layer of the stack is responsible for truncation.
The text was updated successfully, but these errors were encountered:
On ChromeOS, using the Linux subsystem the cpal library seems to work correctly and records audio. However if I request buffer size smaller than 1024 (I used 480 and 960 for single-channel, 48 kHz 10 ms or 20 ms chunks) I receive buffers of the requested size that result in incorrect audio when played back (the audio is shorter than expected, higher pitched and has artifacts). After much investigation it seems like those are 1024-buffers truncated to the requested size and the truncated data is lost (instead of being passed in the next callback invocation). Requesting buffers of size 480 leads to ~0.5x audio length, and 960 is almost okay (with just some artifacts), which led me to the 1024 bytes conclusion. If requested BufferSize is >= 1024 then all the audio data is received correctly.
In such cases it would be nice for cpal to report the minimal buffer size as 1024, as opposed to 1.
This is not reproducible on my other Linux machines, and I have no clue which layer of the stack is responsible for truncation.
The text was updated successfully, but these errors were encountered: