Re: Audio devices input and output coupling
Re: Audio devices input and output coupling
- Subject: Re: Audio devices input and output coupling
- From: Jeff Moore <email@hidden>
- Date: Tue, 13 Oct 2009 11:24:35 -0700
On Oct 12, 2009, at 11:12 PM, AI Developer wrote:
Hi Jeff,
I tried looking at the properties for Bulit-In sound devices with
HALLab on a MacBook Pro.
What I see is that the Built-In Mic, Built-In Input, and Built-In
Output are all related, and they are also on the same clock domain.
Which makes me wonder why they were split up, if they are
synchronized?
As I said, they are most likely presented separately because there are
usage cases where they are clocked separately.
On the other hand, it is also possible that it's just more convenient
for the driver to split up the device for any number of reasons.
Drivers are free to present their hardware as they see fit. That's why
there are properties like the clock domain and related devices
properties to help sort it all out.
However, at the same time, it is possible to run the Mic at 44.1K,
while Output is running at 48K.
This is a little strange - as the properties(clock domain) indicate
that they are synchronized, yet they are running at different
sampling rates.
Not really very strange at all. As the clock domain indicates, the
devices are locked together which prevents them from drifting
regardless of the sample rates involved.
Does this mean that the hardware is running at one sampling rate,
and some form of SRC is being applied?
Doubtful.
If so, where is the SRC happening? Will this affect latency?
If there were any changes in latency, you would see it reflected in
the latency properties.
Thanks.
Devendra.
Jeff Moore wrote:
On Oct 11, 2009, at 9:01 AM, Oshrat Fahima wrote:
We would like to display the user only audio devices that have
input and output which are clock synced.
Currently:
We use the core audio API calls AudioDeviceGetProperty and
AudioDeviceGetPropertyInfo in order to acquire the available
devices.
Core Audio splits the input and output into 2 audio devices with
different device id for each of them,
So we can’t tell which input and output devices are related to the
same physical device.
If this is happening, it is not CoreAudio that is doing it, but
rather the driver of the device. The reason a driver does this is
precisely because the input and output parts of the device are not
always synchronized in hardware. For example, the driver for our
built-in hardware will spilt up the input and output hardware on
some of our machines but not others. This is done precisely because
there are cases where the input and output hardware on specific
machines are not synchronized in hardware.
So, you are already starting in a hole with respect to your stated
objective. There's a good chance that the device you want to use is
being split up into input and output halves because the two halves
are not synchronized in hardware.
Motivation:
Due to the fact that our application in intended for real time
LIVE usage, it has more strict demands.
The basic requirement is that the user will be able to choose only
input and output devices which are clock synchronized, in order to
minimize the latency.
The workaround:
The way we are handling this issue today is very poor, we rely on
the device’s name (a sub string of its name) but it is somehow
awkward.
Does anyone have an acceptable solution for this issue?
So, you have stated two questions. First, you'd like to be able to
identify the input side and output side of the same bit of
hardware. Second, you'd like to identify when two bits of hardware
are synchronized in hardware.
The answer to the first question is that you use the property,
kAudioDevicePropertyRelatedDevices. For IOAudio-based devices, this
property returns an array of AudioObjectIDs for all of the devices
that are packaged together.
The answer to the second question is to use the property,
kAudioDevicePropertyClockDomain. Devices that are synchronized in
hardware will have the same value for this property (as long as the
value isn't 0).
_______________________________________________
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
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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