Re: Application Support of hardwareSampleRateChanged and externalclocking
Re: Application Support of hardwareSampleRateChanged and externalclocking
- Subject: Re: Application Support of hardwareSampleRateChanged and externalclocking
- From: Jeff Moore <email@hidden>
- Date: Mon, 31 Jan 2005 17:51:23 -0800
This is the correct thing to do. The idea is that available format list
should always reflect what is currently available. It's only fair.
Otherwise apps will look at the list your driver presents, choose a
currently illegal one, and wonder why they can't change the sample
rate.
This conversation reminded me of an old bug in the HAL where it was
being a little too flexible in trying to match the format the app
requested to a format the device supported. The HAL was accepting a
format that was the same as the current format, except that the sample
rate was different. For a few devices, this was OK because the new
sample rate was supported. Unfortunately, further testing showed that a
few apps acted funny with this version of the HAL on a few specific
pieces of hardware. The apps would exhibit many of the problems you
described: hanging, crashing, etc.
It turned out the reason for this was that the HAL was taking the
requested format, which was actually illegal and unsupported, and
massaging it into the current format using it's fuzzy matching rules
(this was the bug, BTW). Then the HAL would notice that the new format
was the same as the current one and do nothing. These apps that were
misbehaving had a dependancy on receiving either an error when setting
the new format or a notification that the format changed. Since the HAL
did nothing, the app saw neither the error (what it should have gotten)
nor the notification (since nothing changed).
The worst case scenario was a few apps that would set the format,
assume it was successful because there was no error (hard to blame
them) and then block waiting for the notification that the format
changed. Since this notification was never going to come, they hung
forever. Others, just went on, operating under the impression that the
format of the device is the format they just set apparently
successfully. Later these apps would have issues as their assumptions
clashed with reality =)
The moral to the story is that since your driver wasn't returning an
error for a format change request it wasn't going to honor, it could
easily have caused all sorts of havoc, much like my bug in the HAL.
On Jan 31, 2005, at 5:16 PM, Lynx Studio Technology, Inc. wrote:
This actually raises and additional question. I have two 'sets' of
formats in the AvailableFormats list. One set is just an entry for
specific sample rates (min & max are the same), and the last entry is
the range of sample rates our PLL actually supports (min is 8000 & max
is 215000). When clocking externally, I assume you are saying that
there should only be one entry in the list, where min & max are the
same - and they are the rate of the external clock. Once I notice the
clock has changed rates, I clearAvailableFormats() then rebuild the
list with only one entry.
--
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