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
<http://git.xiph.org/?p=flac.git;a=commitdiff;h=e8632477774f56b4fe7ccab525cad2ceab244b8a>
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);
#endif
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