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

> 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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Jun 14 12:15:03 2011