Re: 'Ganged' or 'Linked' Hardware
Re: 'Ganged' or 'Linked' Hardware
- Subject: Re: 'Ganged' or 'Linked' Hardware
- From: Kurt Bigler <email@hidden>
- Date: Fri, 18 Apr 2003 16:16:20 -0700
on 4/17/03 12:57 PM, Herbie Robinson <email@hidden> wrote:
>
At 11:41 PM -0400 4/16/03, B.J. Buchalter wrote:
>
> Hi Andrew,
>
>
>
>
>
>> A couple of people have asked me about the lack of drivers that support
>
>> treating two (or more) identical hardware units as a single entity. ASIO
>
>> has such a feature and I know that both M-Audio and Metric Halo both
>
>> supported this in their ASIO OS 9 drivers but haven't done so yet in
>
>> their OS X drivers.
>
>>
>
>> Does anyone know if ths is this a 'waiting for something to change in
>
>> CoreAudio' problem or a 'haven't got around to it yet - it's difficult'
>
>> problem or something else entirely ?
>
>
>
> Its more of a 'haven't got around to it yet - it's difficult' due to the
>
> nature of kext drivers coupled with the fact that it is possible for the
>
> applications to do this in Userland (even across multiple unlike devices).
>
> DP4 has this support (I have not tested it yet). We have done this in the
>
> record panel code we have. I really expected Logic to do this, since they
>
> could do it in OS 9 (e.g. Run ASIO and Mac A/V at the same time -- multiple
>
> CA devices should have been more of the same). Anyway doing it in the kext
>
> gives a partial solution (for a class of devices) but does not solve the
>
> general case of disparate devices. Doing it in the kext has a number of
>
> complications, because it is not clear that the user automatically wants to
>
> consolidate every attached device, and communicating complex preferences to
>
> the kext is a difficult process.
>
>
>
> So, while (at least) we will be addressing this, there is still a benefit to
>
> App vendors (or Apple) supporting access to multiple devices simultaneously.
>
>
There are two potential ways to do this:
>
>
1. Queue all the data from the HAL driver callbacks into FIFOs and
>
run another real time thread for DSP.
>
>
2. Run the DSP in one of the HAL callbacks and have the remaining
>
callbacks queue the data.
And a 3rd way, which can at least work for synthesis applications, does not
increase latency:
3. Run the DSP for each device independently in its own HAL callback.
This also offers the advantage of not requiring the devices to be
synchronized, or even to have the same nominal sample rate.
Applications of this are limited, of course, but I mention it for
completeness. If you are willing to do on-the-fly sample-rate conversion
then the applications of this can be broader. (But I for one, have not
figured out how to do this yet.) Effects that cross devices pose additional
challenges and probably make one of the other choices more attractive.
Also, approach 1 may have the advantage of making better use of multiple
CPUs.
Finally, based on everything I've heard (from many people at this point) the
DSP thread for approach 1 does not need to be "real time" but just very
high-prioirity.
-Kurt Bigler
>
>
Either way is going to increase latency.
>
>
Any opinions as to which method is preferred?
>
>
Are there any recommendations from 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.