On 10.12.2015 19:58, lvqcl wrote: > LRN 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> > ? Yes, that is exactly what i meant.
> > The attached patch *should* resolve the issue. libFLAC will call > setvbuf(file, ...) > only if GetFileType(...file...) == FILE_TYPE_DISK. That patch looks correct. That said, i'm not sure why there's setvbuf() in the first place. I mean, the code to de-fragment the output file already exists (the aforementioned d66f675), so why buffering? Was it proven empirically that buffering is required? Or am i looking at this backwards and that code was added later than setvbuf()? -- O< ascii ribbon - stop html email! - www.asciiribbon.org
signature.asc
Description: OpenPGP digital signature
_______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
