[flac-dev] Windows file buffering

lvqcl lvqcl.mail at gmail.com
Thu Dec 10 08:58:56 PST 2015

Erik de Castro Lopo wrote:
> lvqcl,
> Would you be able to have alook at this one? I think its
> Windows related:
>     https://sourceforge.net/p/flac/feature-requests/114/

The relevant changes are
<http://git.xiph.org/?p=flac.git;a=commitdiff;h=6a6207b52a86b1d7980a5233e297c0fc948bed7d> and

the current code:

#ifdef _WIN32
      * Windows can suffer quite badly from disk fragmentation. This can be
      * reduced significantly by setting the output buffer size to be 10MB.
     setvbuf(file, NULL, _IOFBF, 10*1024*1024);

LRN <lrn1986 at gmail.com> wrote:

> The commit mentioned in the feature request should not cause such
> behaviour, as it only does short-lived operations (opens a file, does
> stuff, closes the file immediately after) and is clearly distinguishing
> between disk files and pipes (which is how you, presumably, stream data to
> other processes for whatever reasons).
> I don't claim that FLAC doesn't do buffering, as the OP described, just
> that this commit is unlikely to be the cause.

Maybe you mean some other commit? For example,
<http://git.xiph.org/?p=flac.git;a=commitdiff;h=d66f6754bf94bc8ba23d3579d0b5650cd380c9f0> ?
Because setvbuf() should definitely change libFLAC behaviour regardless of files/pipes/etc.

The attached patch *should* resolve the issue. libFLAC will call setvbuf(file, ...)
only if GetFileType(...file...) == FILE_TYPE_DISK.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: buffering.patch
Type: application/octet-stream
Size: 615 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20151210/c3bffdd5/attachment.obj 

More information about the flac-dev mailing list