Re: [LAU] cancelling I/O with libsndfile

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: <linux-audio-user@...>
Date: Monday, June 13, 2011 - 9:57 pm

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.

-- Dan
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAU] cancelling I/O with libsndfile, Dan Muresan, (Mon Jun 13, 11:43 am)
Re: [LAU] cancelling I/O with libsndfile, Dan Muresan, (Mon Jun 13, 9:57 pm)
Re: [LAU] cancelling I/O with libsndfile, Erik de Castro Lopo, (Tue Jun 14, 12:12 am)
Re: [LAU] cancelling I/O with libsndfile, Dan Muresan, (Tue Jun 14, 6:46 am)
Re: [LAU] cancelling I/O with libsndfile, Paul Davis, (Tue Jun 14, 12:17 am)
Re: [LAU] cancelling I/O with libsndfile, Dan Muresan, (Tue Jun 14, 6:29 am)
Re: [LAU] cancelling I/O with libsndfile, Erik de Castro Lopo, (Mon Jun 13, 11:56 am)