Dan Muresan wrote:
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
Maybe its a bad idea.
:-)
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)
Let me put it this way:
a) When I designed libsndfile over 10 years ago, I never dreamed
anybody would try this.
b) In the 10 years libsndfile has been around and the probably
hundreds of applications it has been used in, noone has suggested
that it would be a good idea if libsndfile could do this.
To me that suggests that either you have a completely unique
problem to solve or that they are other solutions to your
problem that other people use to get around the same problem.
My guess is that your problem is not completely unique.
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
writes via some sf_command parameter.
It does. You can read any number of frames
from 1 through to as many
frames as the file contains.
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.
I accept good quality, clean patches with tests for the functionality
you are adding. Wherever possible, they should be cross platform.
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.
Modifying libsndfile to do fread/fwrite style buffering would be
relatively easy. Again, patches accepted.
I just
checked, and the address you used to post this email to the LAU
list are not subscribed to the libsndfile-users list. Thats why the list
is rejecting your email.
That's exactly the problem: I subscribed about two weeks ago, received
a confirmation,
Was that a confirmation or a request for confirmation? Joining a
mailing list usually involves:
a) Send a request to join.
b) Receiving a "confirm that you want to join" message.
c) Sending "confirm that you want to join".
d) Receiving a "yes, you are mow a member" message.
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...
All other complaints of this sort that I have received have been
from people who couldn't figure out the subscribe procedure or
joined from one email address and sent mail to the list from
another.
Cheers,
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/