Re: Audio Engine Design question
Re: Audio Engine Design question
- Subject: Re: Audio Engine Design question
- From: Jeff Moore <email@hidden>
- Date: Mon, 23 Sep 2002 11:36:05 -0700
All clients of the HAL are supposed to be able to support whatever
buffer layout a driver provides, so you'll be fine doing it this way
for folks wanting to do 5.1 output.
On Friday, September 20, 2002, at 05:32 PM, Matt Gonzalez wrote:
Thanks, Jeff - all stabs are welcome. Doing mono streams for each
channel is
really easy for me - it's already in the firmware.
On Windows, we have to support interleave-by-six to do 5.1 playback.
If I do
go with all-mono streams, is 5.1 still OK?
Matt
Jeff Moore wrote:
If I had to stab something in the ground, I'd suggest going with a
mono
stream for each channel. This gives the most flexibility and provides
the best cache coherency. Plus, the majority of the apps out there
tend
to want to do their audio processing as a bunch of mono buffers. The
V2
AudioUnits are also promoting the idea of doing things this way as
well.
On Friday, September 20, 2002, at 04:54 PM, Matt Gonzalez wrote:
That all makes sense.
Our stuff is firmware based; it's relatively straightforward to
change
the firmware to
handle whatever interleaving scheme is optimal. That being the case,
what is the most
optimal? Or is there a single, optimal solution?
The comments below (Richard's, not Bill's) seem to suggest that it
should be
user-configurable - that I should present some kind of GUI in our
console app that lets
the user pick which one they want. Is this the case?
Matt
Bill Stewart wrote:
I'd like to second Richard's comments
Our intention with the HAL and driver models was to present a model
that is
not arbitrarily complex, but one that can logically encapsulate (by
DESIGN)
the complexities of some pieces of audio hardware, whilst still
allowing a
simple presentation of simple feature sets.
I hope we've succeeded in doing this...
Bare in mind that this is new territory for many companies (both
hardware
and software), so the initial pangs should NOT be used to drive
design
decisions.
A question we've thrown back to driver writers is this:
How is your hardware configured?
How can your driver MOST EFFICIENTLY presents its capabilities?
Kernel resources are the most expensive resources on the OS, so
having
drivers do extra work to satisfy doubtful objectives is both more
work for
the driver writer and ultimately a disservice to the user.
That said:) - there are obviously areas where this ideal presents
problems,
that may require short term workarounds or revisions of released
products.
Hopefully these are far and away the exception to the rule, and
those
compromises are made with the knowledge that the workaround IS
temporary.
(end of lecture - back to your regularly scheduled programming)
Bill
on 20/9/02 6:54 AM, Richard Dobson wrote:
All of the below. Can all 12 channels be driven together with
sample-accurate
timing? Cards such as the Sonorus STUDI/O support multiple
alternative
configurations - 1 16ch devivce or 2 * 8Ch devices, or 4 * 4-ch
devices, etc.
The ideal is for the user to be able to create one or more virtual
devices
with
N channels, up to the available limit.
A 6-ch device has obvious uses for streaming 5.1 surround; a 4-ch
device
supports LCRS surround, simple quad, and direct B-Format signals.
2nd-Order
B-Format requires 9 channels. It seems to me that any applications
that crash
(!!) if presented with a 12ch device need fixing, and should not be
used as
the
baseline for something as universally important as a device driver.
To be
limited to multiple stereo devices seems to me the worst possible
arrangement.
A user might well fancy, for example:
Device #1: stereo
Device #2: 4-ch for B-Format
Device #3: 6-CH for a 5.1 stream
That would use up all analogue 12 channels very tidily.
Out of interest, how many output channels does this device support?
Richard Dobson
Laurent Humbert wrote:
Hello everyone,
The device I'm working with has got 12 analogical line inputs
(24bit) as
well as a couple of S/PDIF (one coaxial, one optical).
Which layout would be best:
A: 1 input stream with 16 channels
B: 1 input stream with 12 channels
1 input stream with 2 channels (coaxial)
1 input stream with 2 channels (optical)
C: 6 input streams with 2 channels
1 input stream with 2 channels (coaxial)
1 input stream with 2 channels (optical)
D: 12 input streams with 1 channel
1 input stream with 2 channels (coaxial)
1 input stream with 2 channels (optical)
E: Other
1 input stream with 12 channels works fine in Ableton Live but
crashes
SoundStudio and Amadeus. Maybe it's safer not to have more than 2
channels per streams. On the other hand, I've seen one audio
driver
do
that....
For the moment I use solution B but I am tempted to go for
solution
C,
but what bothers me is that the Audio MIDI Setup displays
information
only for the first stream, so the user might think the device has
got
only one stereo input :-/
Laurent
_______________________________________________
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.
_______________________________________________
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.
--
mailto:email@hidden
tel: +1 408 974 4056
____________________________________________________________________
__
____
"...Been havin' some trouble lately in the sausage business,"
C.M.O.T.
Dibbler replied.
"What, having trouble making both ends meat?"
____________________________________________________________________
__
____
_______________________________________________
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.
_______________________________________________
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.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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.