TLC suggestions for large matrix mixers?
TLC suggestions for large matrix mixers?
- Subject: TLC suggestions for large matrix mixers?
- From: Christopher Ashworth <email@hidden>
- Date: Thu, 29 Mar 2007 22:16:20 -0400
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