Re: Built-in audio devices unexpected behavior
Re: Built-in audio devices unexpected behavior
- Subject: Re: Built-in audio devices unexpected behavior
- From: Mikael Hakman <email@hidden>
- Date: Tue, 19 Aug 2008 20:06:22 +0200
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.
•
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. Could you please show how to arrive at 900 samples
using information provided by CA?
•
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.
Thanks/Mikael
_______________________________________________
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