Re: Some basic Audio device questions
Re: Some basic Audio device questions
- Subject: Re: Some basic Audio device questions
- From: Jeff Moore <email@hidden>
- Date: Thu, 13 May 2004 18:56:45 -0700
On May 11, 2004, at 4:35 PM, Shaun Wexler wrote:
On May 11, 2004, at 2:20 PM, Jeff Moore wrote:
Apart from a bug in the HAL that causes the list of rate ranges to
overlap or otherwise appear out of order for devices whose ranges are
complex, I'm unaware of any such problem.
Would you care to elaborate on this? Which devices are causing
trouble and what are they saying that is wrong?
Older versions of Sound Devices and Edirol drivers were buggy and
didn't quite comply. The latest USBPre driver seems to be doing a
better job, but still needs quite a bit of love in other areas.
Edirol used to crash when certain properties were requested.
Which devices are you talking about? Most of Edirol's devices are USB
and use our class driver in one fashion or another. The UA-3 I have
here seems to report the proper rates and does ok when I switch the
sample rates, even on the fly. I don't see any crashes or anything like
that.
I'm not familiar with any of Sound Devices' stuff.
AMS used to read the low range and ignore the high range value, which
was apparent in the USBPre driver which (correctly) reported an output
range of [5k, 55k]. To appear correct in AMS, it was changed to
report several ranges: [32k, 32k], [44.1k, 44.1k], [48k, 48k]. All
of this is from memory; honestly I haven't mucked with it for several
months... since AMS became part of Panther, I eliminated my pref's tab
that previously performed those duties in 10.1/10.2.
AMS has been around since at least Jaguar and I think it was in Puma
and Cheetah, but I can't remember. It was rewritten in ObjC for
Panther.
At any rate, there shouldn't be anything wrong with reporting a range
of 5k-50K. I have a pair of USB speakers sitting here on my desk that
report the exact same range, and they seem to show up OK in AMS and
HALLab. A workaround shouldn't be necessary. I don't have a USBPre, so
I can't look at why it might be throwing things for a loop, but it
smells like a bug that should be filed in Radar, especially if this
device uses the class driver.
--
Jeff Moore
Core Audio
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.