Subject: Re: [linux-audio-dev] LADMEA Prototype
From: Paul Davis (pbd_AT_Op.Net)
Date: Fri Aug 17 2001 - 15:53:47 EEST
In message <CJEKIDIANBGFILNCOHJMGEPDCGAA.richard_AT_muse.demon.co.uk>you write:
>The problem is isomorphic to disk I/O only in that I/O happens - some
>exchange implementations might perform the lazy-writing for you.
So an exchange has properties above and beyond those of its clients
and the channels they declare? This gets a little confusing to me.
> Whether
>this happens or not, I don't see why LADMEA suffers from "related issues to
>do with MIDI timing". What are these? LADMEA allows the client to output the
>data the moment it has it (however it gets it). What could be better than
>that?
That assumes that there is a thread scheduled to run at that time that
will take care of delivering it to the relevant (kernel) device driver.
>If you don't allow asynchronous data you introduce unnecessary latency
>averaging half your tick period into your signal chain. Asynchronous data
>isn't that unusual once you go beyond PCM.
I agree. But since LADMEA doesn't imply anything whatsoever about
thread scheduling, its very hard to say anything about the latency
introduced by *its* asynchronous model. When a client calls
sendToExchange() to deliver a block of asynchronous data, it has no
idea when that data might actually get to the recipient. In the LAAGA
model, it knows precisely when it will get to the recipient - on that
same clock tick. if any async-generating client is delivering data to
another thread (i.e. an out-of-process client of a interconnection
system), then the delivery of the data must have some way to schedule
the recipient onto a processor Real Soon Now(TM). If thats not implied
by the interconnection system (and in LADMEA, I don't see how it could
be), then the fact that the data can get delivered to the exchange has
only solved part of the problem.
In the concrete case of MIDI over LAAGA, a client could deliver some
MIDI bytes to its port, and if its connected to a "MIDI output
client", that recipient client will get data the same tick for
delivery to the kernel driver (and hopefully, the bytes go out onto
the wire pretty much immediately).
In "reality" its likely that applications which want to ensure
excellent MIDI timing independent of anything else will have to use a
real time clock to ensure that one of their threads is scheduled
appropriately. Ardour, for example, has such a thread. It checks in
with the audio engine to see what the current audio time is, but its
driven by the RTC not the tick of the audioengine (the precursor to
LAAGA) to ensure that it can deliver MIDI data at the right time,
without being limited to tick-resolution.
This scheme only works when the destination for the data is a device
driver - otherwise, there's the same problem as with LADMEA: how do
you ensure that the recipient thread is scheduled once the data is
delivered? The easiest way to do that is to go back to the tick-driven
model, and accept the latency cost.
>It sounds as if we're using "inactive" in two different senses. When we mean
>the client is not switched on, the exchange will know this and either refuse
>to run an incomplete graph or feed silence (or noise?) into the relevant
>channel.
This means that the exchange needs to understand the data types
involved. Ick.
But anyway, thats not the point. By "inactive" all I mean is that a
client for one reason or another is not calling sendToExchange(). An
example: a network-interfacing client. It collects data from an IP
connection. For some reason, the network is dropping packets. The
client, as a result, does not feed anything to the exchange. Why
should it? Its allowed to run asynchronously, and it doesn't have any
data yet, so it doesn't call sendToExchange(). Any other model would
require every client to generate its own "tick" ...
Suppose there are two clients writing an exchange, this one and say, a
softsynth. Clients reading from the exchange, and using both data
streams, will block on the network client's stream even though the
softsynth is running just fine.
> When a client is broken or late, a exchange can know this and fail
>or compensate using a variety of techniques. LAAGA's approach is one option.
How do you define "late" in an asynchronous system? If you impose the
condition that it must have delivered data with an appropriate
timestamp, then the system isn't asynchronous anymore, and you seem to
be just praying for synchronous operation to occur
spontaneously. LAAGA instead imposes synchronous operation, though it
still allows a client to fail to complete its callback in time (and
then cleans up after it).
>When receiving data on a number of channels, you don't need a mutex because
>of the way the client API is specified (unless I've made a mistake).
If there's more than one potential writer and at least one reader and
they do run synchronously, its a basic axiom of CS that you need a
mutex for serialization. Many times it feels as if you can do away
with it, but the only race-free way to do that is to ensure
serialization some other way or use lock-free techniques which are
typically quite expensive.
From what I understand of the model, you execute client callbacks when
they have data ready and waiting. This means that you serialize the
readers with respect to each other and the writers. But I don't see
how you can serialize the writers which can run asynchronously by
design.
>Again I agree with your buffering comments but would prefer not to implement
>at this stage to keep the API simple.
!! :) and besides, you said there was no "S" in LADMEA :))
The zero copy on 16channels of 44.1kHz
>float audio is under 3Mb/sec which is a significant but not back-breaking
>cost. For current test purposes I think this is tolerable.
Its not the CPU cycles spent doing the copy. Its the cache effects that are
the problem. The example you've given will totally thrash the cache as
the data moves through the graph, when in all likelihood, it could fit
neatly into it if processed with some intelligence and using zero
copy. Such cache effects will have a dramatic effect on speed, even
though the actual number of CPU cycles involved are not particularly
different in either case.
--p
This archive was generated by hypermail 2b28 : Fri Aug 17 2001 - 16:04:52 EEST