> To me that suggests that either you have a completely unique > problem to solve or that they are other solutions to your > problem that other people use to get around the same problem. > My guess is that your problem is not completely unique.
Certainly not unique. My guess is that nobody worried about a (possibly small) performance penalty, and instead used simpler strategies -- or they weren't using sndfile in the first place. Consider this: for any request size you choose, NOT cancelling could double your latency in the worst case if you're streaming from a slow NFS server. Now, I've been able to implement my strategy by storing fd's and using sf_open_fd() as necessary. I.e. after a thread is cancelled in the middle of I/O (rendering the SNDFILE invalid), I re-open fd's using sf_open_fd(). This begs a question -- is it possible to "reset" the SNDFILE less dramatically? E.g. would a seek back to offset 0, or a pair of seeks, or some other trick also reset the data structures? If not, it might be nice to add a sf_reset() function or a SF_RESET sf_command() parameter. >> On second thought, though, this proposal could not possibly work >> without a userspace (libsndfile) cache, because read() might return >> incomplete frames, which would need to be processed in a later call. > > Modifying libsndfile to do fread/fwrite style buffering would be As I wrote above, and as Paul noticed, the virtual I/O layer (which I did not initially notice) is a good solution for this... Best, Dan _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev