[LAD] [LAU] cancelling I/O with libsndfile

Dan Muresan danmbox at gmail.com
Tue Jun 14 07:09:11 UTC 2011


> 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



More information about the Linux-audio-dev mailing list