Re: [LAU] cancelling I/O with libsndfile

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/
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user