desires for the AUBufferUnit
desires for the AUBufferUnit
- Subject: desires for the AUBufferUnit
- From: Kurt Bigler <email@hidden>
- Date: Sun, 02 Mar 2003 17:14:09 -0800
Previously the thread was "Re: audio computation and feeder threads". Since
the AUBufferUnit ideas stood out in Bill Stewart's response to my post, and
since the message was getting too long anyway, I started this new thread for
all that related to the AUBufferUnit topic.
These snippets from Bill's response illustrate the point of this thread:
>
we have considered introducing a buffering type of AU that
>
could potentially deal with this type of situation - which of course is
>
essentially what you are describing.
and
>
I'll take that as at least one vote for the "AUBufferUnit"
Text has been snipped freely throughout, to make this as short as possible!
on 3/1/03 7:29 PM, Bill Stewart <email@hidden> wrote:
>
On Friday, February 28, 2003, at 08:10 PM, Kurt Bigler wrote:
>
> (4) to buffer against much nastier things like thread-performance
>
> inter-dependencies caused by caching issues.
>
>
Hmmm... I think this is a misuderstanding of how your AU *would* or
>
*should* be used in that context.
I think you are saying you see the issue, but that the AU should not do
strange things to work around it. Let me clarify - I don't think extra
threads should be created to trick the scheduler. I just mean this issue is
one more source of irregularity in computation performance. I figure this
is unavoidable in any architecture with bottlenecks, no matter how "good"
the scheduler.
Bottom line: performance in a thread will vary in an unpredictable ways.
Decoupling from the IOProc together with a little more buffering latency
might help absorbe the bumps.
I think this could apply to an AUGraph scenario. The "other factors" that
cause the unpredictable need not be another AU - it could be anything. On
the other hand, it could also be another AUGraph running under another
IOProc on another device from another vendor. There is nothing keeping host
apps from supporting multiple IOProcs - even if they don't currently. My
app certainly has to do this so I can make use of my current hardware. I'm
sure there are people out there who wish they could use "that old interface"
to get some extra channels now and then, rather than having to go buy
another one by the same vendor so they can coerce all the channels into a
single IOProc. So I figure multiple IOProc support in a host app would be a
good thing.
This relates to my point about creating an output AU that spans multiple
IOProcs. If you implemented such a thing then host apps would not have to
do extra work to support a whole closet-full of audio interfaces. The idea
of wrapper objects that encapsulate multi-threadedness strikes me as very
powerful. And I think an AUGraph environment is one place where you could
pull it off cleanly, because the boundaries of each AU are so clearly layed
out, and so independent of the context in which they are used. With
sufficient "decoupling" throughout an AUGraph, the scheduler would be free
to distribute the graph between available processors in the most effective
way. Naturally this involves some increase in latency.
However isn't it possible to introduce LESS than a buffers worth of latency?
The goal would be to introduce the minimum latency needed to solve the
problem of glitchless throughput, and no more. More on this below.
>
We do not allow fan out connections in the AUGraph (ie. the situation
>
where the same output bus of an AU is going to 2 or more different
>
destinations)
>
>
We also do not allow for more than one output unit on an AUGraph -
A multi-IOProc output unit could change this, right?
>
That said - we have considered introducing a buffering type of AU that
>
could potentially deal with this type of situation - which of course is
>
essentially what you are describing.
>
>
That kind of AU (which would introduce at least a buffer's worth of
>
latency)
Are you sure it requires a full buffer of latency? Or is that just to make
the implementation simpler? I am imagining something like an isochronous
situation for each block of computation that sits in its own thread. Maybe
the thread keeps track of its latency, computes until it the sample time
hits a certain threshold, then goes to sleep for a time. The amount
computed in each wake cycle might not relate to IOProc buffer boundaries at
all - just as the isochronous bursts on firewire relate loosely to the bus
cycle. Mind you I'm not yet much of a thread programmer yet and this is all
in theory for me. But it seems to me that the HAL is already doing similar
kinds of things, and that this is actually _much_ simpler than the HAL
heuristics, and I think people are already doing things like this with their
feeder threads, no? It is just a question of whether it can be
encapsulated.
I think it would be most useful to have a buffering AU that would allow
introducing any desired "cushion" latency. Of course, one can choose to
reduce the buffer size if necessary, but that may be counter-productive in
terms of performance for the usual reasons. The fractional-IOProc-buffer
"cushion" latency might make possible the best net performance for a given
net latency. This remains to be proved of course - though I suspect this is
not a new topic in CS theory. I'm just not that well-versed in CS.
>
would get its data from its sources through a single bus, in a
>
single thread. It could have multiple output busses (say in the case
>
you describe above) that would be providing data on those threads. The
>
whole raison d'etre for this unit would be to deal with these kinds of
>
threaded and buffering situations, with minimal need to use locking
>
semantics.
It sounds like you are describing a situation that _would_ support multiple
IOProcs for output from a single new-fangled output AU.
>
> (5) perhaps - to make good use of multiple processors on the system when
>
> they are available
>
Sure - this certainly holds out some good benefits for doing something
>
like this - though also here,
...
>
the host maybe in a better
>
situation to make this decision than a particular AU... I could imagine
>
a situation where a user might be able to split their usage or you
>
synth into different sources of control events, and thus instaniate
>
multiple instances of you synth, which then the host could target to
>
different CPUs..
I think that relates to what I was saying above - except as I envisioned it,
it would depend only on the scheduler, with no special thought from the
host. Except a host could "operate" on an user-specified AUGraph to turn it
into a "distributable" one, by inserting buffering with controlled
latencies.
Thanks again,
Kurt Bigler
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.