Re: [LAU] cancelling I/O with libsndfile

From: Dan Muresan <danmbox@email-addr-hidden>
Date: Tue Jun 14 2011 - 00:57:30 EEST

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)

> 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.

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
> to be and then only read enough frames so that you can interrupt between

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
> 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, 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
> is really a development question).

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.

-- Dan
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Tue Jun 14 04:15:03 2011

This archive was generated by hypermail 2.1.8 : Tue Jun 14 2011 - 04:15:03 EEST