Re: Any hints on optimizing my IO Proc for 128 channels ?
Re: Any hints on optimizing my IO Proc for 128 channels ?
- Subject: Re: Any hints on optimizing my IO Proc for 128 channels ?
- From: William Stewart <email@hidden>
- Date: Thu, 13 Oct 2005 12:22:55 -0700
Are you using the AUHAL unit to interface to this device?
The reason I'm asking is that it has some considerable logic in it to
optimise the usage of a device (enabling/disabling streams), as well
as some optimised pathways for interleaving/de-interleaving (if
that's even needed) and so forth... It also presents a channel map
property so that you can describe to it which channels of your input
to it should be mapped to which channels of the device's output...
this can be set as its going along (and also includes the ability to
describe input channels that should be dropped on the floor - ie that
wouldn't currently be routed to a device)
It doesn't do mixing, etc, but just in terms of raw output routing, I
think it does some useful work.
Bill
On 13/10/2005, at 10:46 AM, David Duncan wrote:
On Oct 13, 2005, at 12:55 PM, Mark Gilbert wrote:
1) Pages through the various buffers and flattens them into a
single 'composite' buffer (for this IO call, so 512 samples or
whatever) which is interleaved 128 channel Float32s. This
involves a line of array mapping assigment which executes for
every sample assigning a sample from each buffer in turn to a
place in our composite buffer. We do this so we can have a uniform
interleaved approach for all audio devices, even ones with unusual
buffer sets with different numbers of channels.
Your working through 512K of data (256 in your source, 256 in your
destination). Your probably blowing the cache quite often and
causing more memory stalls than you like (check this in Shark).
Rather than going from each buffer into your flattened buffer, I
would work with 1 buffer at a time. Reading from more than 1 buffer
at a time is working against the cache.
2) It then copies from the 512 (typical) sample/ch composite
buffer into our main (large) circular buffer which may be as big
as 30 seconds/ch. This copy is also a sample by sample, since we
are cross mapping (routing) channels from one input to a different
channel slot in the circular buffer. During this process we also
compare each level with a floating maximum to do our peak level
metering.
I would keep your buffer pre-routed and route it on the fly as you
read from it. If you can, I would also postpone peaking until
outside the IOProc. If you need realtime peak metering, you might
be able to get away with this as you read from the buffer.
--
Reality is what, when you stop believing in it, doesn't go away.
Failure is not an option. It is a privilege reserved for those who
try.
David Duncan
_______________________________________________
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
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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