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 <lrn1...@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.
buffering.patch
Description: Binary data
_______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
