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
Currently read_samples would do an fread(...) call for every frame, and IIUC each such call results in a read-syscall and user<>kernel switch. I wonder if it would speed up if a large buffer is first read and then encoded at once - the underlying libopus API seems to support encoding multiple frames at once.
Would it be faster to do this?
If so, maybe a bufsize option can be introduced or even a command line switch for a regime where whole input is read in-memory / or input is open as mmap.
Also every read_samples/wav_read call alloca-tes a buffer dynamically for every frame.
The text was updated successfully, but these errors were encountered:
vadimkantorov
changed the title
Encoding multiple frames at once as oppose to per-frame encoding
Encoding multiple frames at once as oppose to per-frame encoding to save user<>kernel switches resulting from many fread(...) calls
Dec 6, 2023
https://github.com/xiph/opus-tools/blob/master/src/opusenc.c#L1116-L1119 :
Currently
read_samples
would do anfread(...)
call for every frame, and IIUC each such call results in aread
-syscall and user<>kernel switch. I wonder if it would speed up if a large buffer is first read and then encoded at once - the underlying libopus API seems to support encoding multiple frames at once.Would it be faster to do this?
If so, maybe a bufsize option can be introduced or even a command line switch for a regime where whole input is read in-memory / or input is open as mmap.
Also every
read_samples
/wav_read
callalloca
-tes a buffer dynamically for every frame.The text was updated successfully, but these errors were encountered: