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

Dan Muresan danmbox at gmail.com
Tue Jun 14 07:49:40 UTC 2011

> Err, if you're worried about latency, why are you streaming from
> a slow NFS server?

The point was that NOT cancelling introduces extra latency
unnecessarily, and short requests introduce CPU overhead. I gave the
NFS example to preempt the "hard disks are really fast" objection that
some people are always tempted to make...

For the given example, if the NFS server can stream at even 110% of
the playback speed without jitter, you can still achieve glitch-free,
continuous  playback with as low a *skip* latency as the CPU (and
chosen request size) permit. *If* you can cancel active requests, that
is -- otherwise you need to double that latency.

And yes, I actually do stream from a fileserver (over NFS) myself quite often.

>> be nice to add a sf_reset() function or a SF_RESET sf_command()
>> parameter.
> What problem does that fix? Do you even know if there is a problem?

The problem of a SNDFILE becoming invalid after a cancelled I/O. Yes,
there is a problem -- valgrind reports nasty memory errors (and
eventually I get a segfault) if I don't re-open the SNDFILE.

[ If you meant I should test the sf_seek() trick first -- I doubt that
testing a few sf_seek()s on a few FLAC files will reliably establish
whether sf_seek() really does reset all encoder and decoder structure
under all circumstances. Especially since you said you weren't sure
yourself. ]

-- Dan

More information about the Linux-audio-dev mailing list