> It's probably a Good Thing (TM) that libsndfile doesn't do its
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
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
Yes, that's exactly how my implementation works. My ringbuffer is
divided in fragments.
> quantised to the same value. The syscall overhead becomes
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
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
It might be an interesting idea to do new requests in parallel with
cancelled ones, but this requires another layer of ringbuffer / memory
Linux-audio-dev mailing list