Re: [linux-audio-dev] LAAGA - main components

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] LAAGA - main components
From: Jim Peters (jim_AT_aguazul.demon.co.uk)
Date: Tue May 01 2001 - 21:41:33 EEST


Paul Davis wrote:
> [ I have made the effort to not respond to any of your personal
> attacks here. It doesn't help anyone to do that. ]

Some respect for my effort and ideas is all I ask.

> I agree with everything you've said here. However, both implicitly and
> explicitly you seem to want add support for non-in-process clients. My
> point about such things are they already supported by several
> different sound servers, and its not clear to me that its a sensible
> strategy to try and support both kinds of clients with the same
> server. they work so differently.

Stefan was talking about the need to have interoperability between
LAAGA/AES/whatever and aRts and so on, so supporting out-of-process
clients is necessary, even if it's just to connect to aRts. Also, all
those plugins will have to get their data out somehow given that they
can't write to disk or anything. I agree it is up to them, but we
might as well provide some example code or a library to help them -
and it would be useful to establish a good reliable recommended
method. Also, the method employed by individual plugins impacts
strongly on the overall behaviour of the critical process, so we'd
better recommend the right method. Also, in general external apps are
going to want to output sound whilst the critical process is running,
and this data will have to be relayed to that process somehow.

Anyway, it was leading on naturally from the previous discussion, so I
don't see any problem with discussing this.

At least we've firmed up several of the concepts surrounding this
whole thing. From what you've said, I am now much clearer about the
need for minimising system calls in the critical process, and taking
great care about the relation between that process and external
processes. I've not had to code an extreme low-latency application,
so this is new information for me.

> >Okay, this is something. In your experience with your low-latency
> >process, could we get away with making one write(2) call at the end of
> >the main loop in order to wake these other processes ?
>
> there's no way to know how long the write(2) call might block for, or
> if it will block at all. so in general, no, its not OK. if it blocks
> for more than the time-to-next-audio interrupt, we lose. it might work
> most of the time. it might not.

If we write the device driver, then it won't block. All it's going to
do is wake a bunch of processes. I don't know the specifics for doing
this in the kernel, but can't we be fairly certain that we will return
to the same process (our critical process) without being rescheduled,
especially as it's RT_FIFO ?

I'm trying to make constructive suggestions here.

Personally, if I'm going to write an app, I'd be writing a plugin to
go in the critical process, with another process outside dealing with
the shared memory buffers. I don't care if it has a 100ms delay so
long as my buffers are big enough to cope, because all the
time-critical stuff would be in the plugin. The external process
would just be GUI, front-end handling, data preloading from disk and
data saving to disk. All of this can have 100ms delay without
problem.

So I don't care about this 20ms delay. However, I can appreciate that
some people might - especially people who have written fairly tight
sound servers or whatever that need to be connected up. For this
reason I've been putting in the effort to try and work out how we can
make this fly as close to the ground as possible.

Perhaps it is not necessary to bother with this. Still, I feel that
if this really is going to be a killer low-latency plugin server,
these kinds of issues need to be dealt with, not least to minimise the
load on that server due to communication with other processes.

> >Well, shared memory is *very* fast, so even if we can't wake the
> >external processes right away, we're still saving system time that
> >would otherwise have been spent copying data in and out of a whole
> >list of buffers, which is what would happen if we used sockets or
> >pipes or whatever.
>
> Abramo has pointed out that the pcm_shm and aserver components to
> alsa-lib *already* do this. Nothing new needs to be written to use
> this, applications that already use alsa-lib don't need modifying, and
> thanks to his work on libaoss, even OSS API-based applications can use
> it to, with a little help from LD_PRELOAD.

I've rechecked the LAD archives, concerned that I might have missed
some critical post from Abrama explaining pcm_shm and aserver, but I
couldn't find it. With no info, I can't be certain that these will be
suitable, but I'd be very happy if they are, and if we indeed need to
write no additional code. What would make me even happier would be if
the `aserver' turns out to be close to what we're discussing - inside
ALSA would certainly be a very good place for this to be. But we
don't know any of that yet.

> So there isn't any work needed to support this kind of thing. The
> question remains, as Kai showed very clearly a couple of days back, do
> we support only in-process clients, only out-of-process clients, or both?

Our main target is in-process clients. But we have to support
out-of-process clients for interoperability with everything else
that's out there.

> With in-process clients, what do we do about GUI's? If I understand
> your suggestions and Kai's correctly, that would be down to the client
> in question: how it and its GUI communicated would be a private
> affair. Did I understand this correctly?

My personal opinion is that how the plugin and GUI communicate is a
private affair, but we should recommend particular methods and provide
example code at the very least. This is due to the detrimental effect
of certain means of communication on the critical process - you
yourself provided most of this information, Paul, from your experience
with low-latency.

Next question - given that the requirements on the critical process
itself are clearer now (minimum or zero system calls, for instance),
and transfer of data in and out of that process is necessary, what
should we recommend to plugin-writers ?

My suggestion is to use shared memory, because this involves no costly
system calls or library calls once it is all set up and running. The
only issue then is how to handle an external process that wishes to
wait on a shared memory buffer. I have made three suggestions, none
of which have met any favourable response so far:

- The external process sleeps for a estimated period. Paul indicates
  that this means a worst-case 10ms delay, so latencies under 20ms for
  the external process are probably not feasible with this method.
  This does have the advantage, though, of not requiring *any* system
  calls at all in the critical process. Also, I don't think I'm going
  to be needing 20ms latencies in external processes. Anyone ?

- The external process sleeps, and the critical process wakes it with
  a signal sent to a process group (using kill). This costs one
  system call in the critical process, and several in the external
  process (for changing the signal handlers around).

- We write a special device driver (a bit like a named pipe), and any
  external process waiting for a shared memory buffer sleeps on this
  device. The critical process writes a byte to this device (or does
  an ioctl or something) at the end of the main loop, indicating to
  the device driver to wake up all the processes sleeping on it. This
  costs a system call in the critical process.

My favourite is the first, because there is no cost in the critical
process, but if external processes are going to require better
performance than this, we need another solution. But, are they going
to require better performance ?

Okay, that was my solution. If anyone else can think of a
low-overhead way of doing this, please speak up.

Even if code already exists in ALSA to do this, they would have been
working with the same issues. If they have a better solution, perhaps
now is the time to mention it ?

Jim

-- 
 Jim Peters         /             __   |  \              Aguazul
                   /   /| /| )| /| / )||   \
 jim_AT_aguazul.      \  (_|(_|(_|(_| )(_|I   /        www.aguazul.
  demon.co.uk       \    ._)     _/       /          demon.co.uk


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue May 01 2001 - 22:20:59 EEST