Re: How long do render callbacks have to execute?
Re: How long do render callbacks have to execute?
- Subject: Re: How long do render callbacks have to execute?
- From: Brian Willoughby <email@hidden>
- Date: Thu, 18 Aug 2011 23:53:37 -0700
On Aug 18, 2011, at 22:53, tahome izwah wrote:
2011/8/13 Brian Willoughby <email@hidden>:
On Aug 12, 2011, at 15:39, Jonathan wrote:
Okay, that makes sense, but are the callbacks called in parallel?
In other
words, is only one callback firing at a time? In the example
with two
inputs into the mixer, does it fire one right after another even
though from
a graph perspective they are peers?
In general, a processor cannot carry out any operations in parallel.
Not true. That is exactly what SIMD instructions do which are built
into all modern CPUs.
SIMD does not carry out multiple operations, it performs the same
operation on multiple data values. Single Instruction Multiple
Data. Have you actually written any code using SIMD? How familiar
are you with how it works?
Also, you cannot take advantage of SIMD unless your data is
interleaved, which places this entire topic of separate cores for
separate channels out of the realm of AudioUnits, since interleaved
channel data has been deprecated many years ago. In other words, you
can't get two kernels in a stereo AU to use SIMD to process both
channels at the same time. You specifically cannot use SIMD to get
separate channels on separate cores because a SIMD instruction must
execute on a single core. You're not just comparing apple to
oranges, you're comparing apples to yoyos.
2011/8/11 Brian Willoughby <email@hidden>:
On Aug 10, 2011, at 13:30, tahome izwah wrote:
Last time I checked separate channels are using separate kernel
instances, in order to be able to distribute processing across
multiple cores.
The reason that AUEffectBase creates a separate kernel for each
channel has
nothing to do with multiple CPU cores or distributing the CPU load.
When I was recently testing a new AU that was what was happening.
Makes sense, too.
Exactly what was happening? When you say "that," do you mean that
you observed what I was saying to be true? Your claims are not very
well specified, so I can't tell what you're trying to say here.
What you originally wrote is completely impossible unless
AUEffectBase.cpp has been rewritten, which means that shipping
AudioUnits certainly do not work that way. If you care to take a
look at AUEffectBase::ProcessBufferLists(), you'll note that there is
a for () loop that iterates through the kernels, one at a time, only
calling Process() on one at a time, serially. It is impossible for
two kernels to execute in parallel on more than one core
concurrently. Besides, if this code were to change, it would most
likely break several AU hosts.
What you may have observed is the completely typical situation where
a single thread will be scheduled on different cores at random.
Don't be fooled, just because one thread bounces around from one core
to another does not mean that the thread ever executes on two cores
at the same time - it doesn't. It's perfectly normal to see activity
on multiple cores in even a single-threaded program, but that has
nothing to do with multi-threaded programs that can run
simultaneously on more than one core.
Sorry if I seem grumpy, but I really can't understand why you're
making these various claims.
Brian Willoughby
Sound Consulting
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden