Hi Erik -- please CC me so I can reply (I don't receive messages from
LAU directly). I'm quoting manually here:
> > I'm trying to cancel an ongoing sf_* I/O operation (from another
I don't think so... Issuing large requests, then cancelling as needed
gives a process the lowest possible latency for unpredictable seeks
(caused e.g. by user commands), while keeping CPU usage low (by
avoiding syscall and context switching overhead)
> Reading one frame at a time sounds like a bad idea too.
1 frame at a time was an extreme example. The point was that
libsndfile doesn't employ a user-space cache, but direct system calls.
Reading 10, 100 or 480 frames at a time will still incur syscall
overhead (== CPU usage), and progressively larger cancel latencies.
> > libsndfile. It would be nice if libsndfile could allow short reads and
I meant "short reads" in kernel-speak sense: read(2) can return a
number of bytes less than the number requested when interrupted by a
signal (if SA_RESTART is disabled). My proposal was to add a
sf_command() parameter that disables the looping behavior of sf_read()
on EINTR, and makes it return exactly as many frames as the first
read() call manages to get.
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. I
discovered the virtual I/O in sndfile, and that seems more
appropriate. So I withdraw my proposal.
> Basically you could define how fine grained you want you interruption
That was exactly the strategy I originally described as inadequate,
due to syscall overhead (in the absence of userspace caching)...
> I just checked, and the address you used to post this email to the LAU
That's exactly the problem: I subscribed about two weeks ago, received
a confirmation, and sent a message at that time (which received no
bounces, but no replies either). Now, the mailserver somehow forgot
about me and is rejecting my messages. Or something...
> libsndfile questions here (or better yet, the LAD list since this
You're right -- I've realized right after hitting "Send". Please feel
free to respond on LAD (but please CC me). I am replying on LAU this
one time to clear up the issues that were already brought up, since my
original message seemed confusing.
Linux-audio-user mailing list