linuxaudio.org

Dan Muresan wrote:
> Hi Erik -- please CC me so I can reply (I don't receive messages from

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

quoted text
>

> 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

quoted text
> 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

quoted text
> > 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

quoted text
> 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-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev