14 Jun
2011
14 Jun
'11
1:42 p.m.
Hi Fons,
It's probably a Good Thing (TM) that libsndfile
doesn't do its
own buffering. First, the file system will do buffering, and if
I agree, I prefer the flexibility of implementing my own user-space
cache in an app-dependent way, too.
exactly this is organised will be application
dependent. Having
a third layer in between this and the system is not going to help.
For sure, two user-space caches add a useless extra layer of copying.
One way to organise the buffer is to divide it in
fragments
of say 1/4 second, and have the start offset of each one
Yes, that's exactly how my implementation works. My ringbuffer is
divided in fragments.
quantised to the same value. The syscall overhead
becomes
trivial for such a lenght. When you need new fragments, you
Yes, that's why I argued for long requests over short ones.
the actual read() call). The one you can't cancel
is no big
deal, just let it happen. It will take little time compared
And this is why I gave the NFS example earlier in the discussion...
What if it the data comes from the network, e.g. a streaming server
that has just 110% the bandwidth of the actual real-time playback? As
I said, in this case you almost double the latency if you can't cancel
the request.
It might be an interesting idea to do new requests in parallel with
cancelled ones, but this requires another layer of ringbuffer / memory
management.
-- Dan