OK. If you look back, this whole round of discussions was a consequence of me saying "VIO in sndfile is ALSO good because...". I didn't think it was really such a big deal in the first place: VIO is already there, and I was able to accomplish my programming goals.
> 1) there's a reason to use value A > 2) there's a different reason to use value B > 3) there's no measurable difference in performance between A and B, > and thus the choice between 1+2 must be made on some other grounds There is no choice to be made though. Sndfile doesn't have a userspace cache, but does have a VIO layer that can be used by maniacs who want to milk the last bit of performance (like me, possibly impairing performance by premature optimization), or by those who need to simulate in userspace a network driver. If we were to talk counter-factually, no, I wouldn't want Eric to not write the VIO layer that is present in sndfile at least after 1.0.21... > discarded. The ghosts of thousand dead standards will back me up on > this one. The situation you're describing, i.e. a "dead" standard still applicable to the given platform, and thus able to mislead developers, isn't so common, I believe. > Variations of less than about 500 bytes made no statistically > significant difference to measured throughput. I agree that the memcpy() cost is probably hardly measurable on a PC. It might be measurable on a DSP though, or on a dedicated chip. So..., > Sure, but its because we care about performance, not standards or > "rules". And I measured it first. We might be at cross-purposes. My idea was to design the ideal standards-compliant player and write the "perfect" code, for once (and make sure that the libraries involved allow me to do it) -- Dan _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
