Re: TLC suggestions for large matrix mixers?
Re: TLC suggestions for large matrix mixers?
- Subject: Re: TLC suggestions for large matrix mixers?
- From: William Stewart <email@hidden>
- Date: Fri, 30 Mar 2007 12:28:30 -0700
max frames is there to tell an AU what the max number of frames it
will be asked to render for any given render call. If you ask an AU
to render for more frames than this, it returns an error and doesn't
render. So, you need to ensure that max frames is always as big as
the largest number of frames you would ask to render. So, if there
are rate conversions in your graph, you have to allow for that - for
instance, if the output is 48K, and some of your sources are say 96K,
then anything above the 96K->48K rate convert will have to have max
frames set to 2X what it is on the other side (48K) of the conversion.
In AULab we manage this ourselves and also listen for rate or I/O
cycle changes and re-assess the max frames based on current device
settings - this both ensures minimal but sufficient memory usage/
As for the dropouts - you really need to diagnose this further - if
its due to overloads you could diagnose this by running HALLab as
root and having it listen to IO overloads for the targeted process.
If its due to some render errors, you can listen to:
kAudioUnitProperty_LastRenderError on any/every audio unit in your
chain (this will also tell you if you have problems with max frames).
Just instantiate a property listener for this property and if it
fires you can get the value of the error
HTH
Bill
On 29/03/2007, at 7:16 PM, Christopher Ashworth wrote:
On Mar 29, 2007, at 3:41 PM, Jeff Moore wrote:
I have not heard of any issues at the hardware level or HAL level
with hardware running at 192K, other than potentially bandwidth
issues on constrained busses (e.g. USB). Depending on the bit
depth and number of channels involved, it's quite possible to run
out of isoch bandwidth.
One thing you might run into though is that to maintain an ~11.5ms
IO cycle, the buffer size would increase from the default of 512
frames to 2048 frames. If this is the case, you probably need to
update each AU's kAudioUnitProperty_MaximumFramesPerSlice property
to be large enough.
This topic also seems as if it *may* be related to a problem I'm
currently trying to solve:
* Summary of Problem:
When playing multiple audio files, a user reports drop-outs
lasting from ~0.1 to ~1 second, usually around ~.5. The dropouts
manifest across all files and all output channels simultaneously.
* Hardware / OS / file specs:
Dual 2.7GHz G5 with 4G RAM
OS 10.4.8 and 10.4.9 (Drive wiped clean, reinstalled OS to
ensure clean system.)
Audio devices used to test:
+ USB MOTU 828 Mk2
+ Firewire MOTU 828 Mk1
+ Built-in Audio
Seven audio files played simultaneously: 24 bit stereo WAVs @
44100 sample rate
* Application overview and architecture:
The application is being used to play back sound files during a
theatrical performance.
Audio playback is split up into "cues" which each have an
associated audio file.
The path of audio data is:
Audio File => Format Conversion => Audio Buffer => "Individual"
Matrix Mixer AU => "Global" Matrix Mixer AU => Device
There is exactly one "global" mixer per physical output device.
This global mixer is created with a relatively large number of
busses (100 to 1000 in tests). Those busses are enabled and
disabled as needed so that multiple audio files can be fed to the
same physical device. There is one "individual" mixer per file.
The global mixer is in an AUGraph. The render callback for this
device examines which bus is being requested and pulls on the Mixer
AU for the appropriate audio file. The callback for that AU uses
the buffer to provide frames, and meanwhile the buffer is filled in
a separate feeder thread.
* The "facts of the case":
By giving the user a version of the software with extensive
logging enabled, we have determined that:
- No CoreAudio errors or warnings are logged at any time.
- The audio buffers never run out of audio data (i.e. there is no
disk bottleneck).
- The request for frames from the global mixer's render callback
is always fulfilled with all requested frames in less than a
millisecond. In other words, at least until the audio hits the
global mixer, there are no dropouts or glitches, or any apparent
problems at all.
- Activity Monitor reports no CPU spikes; for 7 stereo WAVs
routed out all 16 channels CPU load is 20-22% out of a possible
200% for the dual CPU machine.
- Total system load is low.
- Although originally noticed on the USB MOTU, switching to a
Firewire device and then Built-in audio both exhibited similar
problems, although to a much lesser degree. (The dropouts became
brief glitches.) So it doesn't appear to be purely a saturation of
the USB bus.
When trying to recreate a similar system to test first-hand, I used:
1.25 GHz PowerPC G4 (1 CPU), 1 GB RAM (PowerBook)
Firewire MOTU UltraLight
Strangely, I am getting no dropouts on my less powerful machine.
In sum, it appears that the dropouts are either happening in the
final matrix mixer, the drivers, or somewhere further down the chain.
I'm wondering if the kAudioUnitProperty_MaximumFramesPerSlice may
need to be increased for this scenario, but as I said in my last
post I don't fully understand the implications of that, so maybe
it's completely unrelated to this problem....
Any thoughts warmly welcomed.
Best,
Christopher
_______________________________________________
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