Re: 'Ganged' or 'Linked' Hardware
Re: 'Ganged' or 'Linked' Hardware
- Subject: Re: 'Ganged' or 'Linked' Hardware
- From: Shaun Wexler <email@hidden>
- Date: Fri, 18 Apr 2003 21:33:38 -0700
On Friday, April 18, 2003, at 01:05 PM, Jeff Moore wrote:
An application can be coded today that takes advantage of the
information the HAL provides along with some rate conversion to
perform accurate synchronization regardless of what devices are
involved or whether or not they are synchronized at the hardware
level. It isn't necessarily easy but I don't believe that this is
asking too much of applications. As BJ points out, some apps already
are doing it.
MacFOH currently performs latency and timestamp synchronization between
different devices, in order to calculate transfer function,
cross-correlation, etc. It works reliably, so far with all the devices
I've tested, and rarely fails to achieve sync. My sync method sets a
pointer for each AudioConnection into its AudioChannel's virtual ring
buffer. I use a class named ThreadedJob to segment subtasks into "job"
objects (similar to NSInvocations) which are enqueued and dispatched
into a managed group of worker threads, and maintain processing state
info, with delegate notifications, etc; they also allow timed-wait
performs, repeating or one-shot, using one dedicated RR scheduler
thread.
- (void) processAudio
{
if (running)
{
if ([sourceConnection syncWithConnection:referenceConnection])
{
[processSource_job perform];
[processReference_job perform];
}
else {
[sourceConnection waitForNewData];
[referenceConnection waitForNewData];
[processAudio_job perform];
}
}
}
Certain device drivers have a problem generating their timestamps when
first started, not returning valid data for a few buffer cycles; namely
the Sound Devices USBPre's beta driver. When I can't match timestamps,
I again wait on a semaphore until the next ioProc slices are written,
until I achieve sync, and so far I've never had a discernable hang
other than waiting on the USBPre to get up to speed (incidentally, it
also throws an overload when started, nearly every time, if its buffer
size < 1024).
As for users, all they should have to do is plug the devices in and
tell the app to use them. From there, the app should be the one to
figure out how to go about synchronizing the devices using the
information provided.
Something which I've been discussing for the past 6 months is how
CoreAudio should provide info to an application so it can perform
device/engine matching, for HAL client user-space deviceID's. I would
like to see a new HAL property "kAudioHardwareDeviceMatchingID", which
would return a UInt32 value, to allow the client to sort the list of
active devices for device matching. It should be up to the kext/driver
to determine which AudioEngines, etc, qualify to match, regardless if
they represent the same physical hardware. The HAL should provide
sequential ID's as requested by the drivers. This
kAudioHardwareDeviceMatchingID property would allow a driver to treat
multiple hardware units as one large device, without breaking existing
apps, allowing new apps to represent multiple DeviceID's as one
physical device to the user. I currently use a DeviceUID parsing
method (yeah, I know) to perform this, and it works great, but may
break if the UID format changes in the future... not a problem, in that
case, since it would simply fail to coalesce individual DeviceID's and
present them as separate devices, as most apps do currently...
--
Shaun Wexler
MacFOH
http://www.macfoh.com
_______________________________________________
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.