Re: Built-in audio devices unexpected behavior
Re: Built-in audio devices unexpected behavior
- Subject: Re: Built-in audio devices unexpected behavior
- From: Jeff Moore <email@hidden>
- Date: Tue, 19 Aug 2008 11:32:15 -0700
On Aug 19, 2008, at 11:06 AM, Mikael Hakman wrote:
On Aug 19, 2008, at 5:40 PM, Jeff Moore wrote:
On Aug 19, 2008, at 5:23 AM, Mikael Hakman wrote:
While performing some tests using built-in audio devices I
observed following behavior not consistent with my expectations.
•
Whenever my application sets virtual format on either input or
output device to standard Float32 PCM then physical format changes
to 16-bits even if I set it to 24-bits in AMS.
I'd consider this user error on your part.
When you set the virtual format, the device is free to map the
virtual format to whatever physical format it desires. If you want
to set a specific physical format, you should set that specific
physical format rather than setting the virtual format and leaving
it up to the device.
Because I set virtual format that is compatible with current
physical format, the device has no reason to change its physical
format. This is what I would call straight-forward logics. Then of
course software and hardware full quirks isn't completely unknown,
more so from certain vendors than from others. This device has
displayed many other shortcomings before.
Maybe I wasn't being clear. You should not be setting the virtual
format, period. That property is only writeable for historical
reasons. New code should not be setting it but rather using the
physical format to select the specific format desired.
•
According to HALLab and to returned kAudioDevicePropertyLatency/
kAudioStreamPropertyLatency properties, latency of these devices
is 30 samples. Connecting output to input, outputting a single
pulse, and measuring the number of samples until the pulse appears
on input yields a total latency of about 900 samples when using
128 sample buffer sizes. I would expect total latency of 128 + 30
+ 30 = 188 samples.
Again. More user error on your part. You are leaving out the safety
offset in your calculation of throughput latency. You are also
leaving out the input buffering as well.
I'm counting with input buffer size - that's the first 128 samples
in my calculation.
Then you aren't counting the output buffer. Either way, there are two
IO buffers in between writing the output and reading the input
Could you please show how to arrive at 900 samples using information
provided by CA?
For a full duplex device, you would calculate the total throughput
latency like this:
input safety offset + input Latency + 2 * IO buffer size + output
safety offset + output latency
If you were being complete, you would calculate the latency figures as
the sum of the device latency and the stream latency for the
particular stream a given channel is on. In other words, latency can
vary from stream to stream. An example would be a device that has both
analog and digital outputs. The latency for the streams corresponding
to the analog outputs would include the DAC latency whereas the
latency for the streams corresponding to the digital output would not.
•
Whenever optical input signal ceases then input device changes its
input stream from digital to line-in despite optical connector
still being physically connected. I would expect reported input
stream still being digital but with no channels in it when there
is no valid digital signal. Output device does it right – when
optical jack is connected then the stream is digital, when analog
jack is connected then the stream is line-out.
Could you please comment on these observations.
The SPDIF in requires a clock to work. If it doesn't have one, it
has to switch to something that works and can give timing. The
output has no such problems since it is generating the clock.
As I wrote above it could report digital stream with 0 channels. Or
it could report that it currently doesn't have any streams. Both
these reports would agree with reality. Instead it reports line-in
input, which isn't in agreement with physical facts. As long as
optical jack is connected there is no line-in input, only digital
with or without valid signal.
It is my understanding that this is not how the hardware behaves.
One of the things we try to do at the HAL/driver level is to
accurately portray the hardware as it is. "Faking" things has shown to
have all sorts of undesired side effects down the road.
--
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