Re: multithreaded mixer
Re: multithreaded mixer
- Subject: Re: multithreaded mixer
- From: "B.J. Buchalter" <email@hidden>
- Date: Fri, 19 Mar 2004 02:24:22 -0500
Hey Folks,
I've noticed what I think is incorrect behavior in AMS/HALLab/IOAudioFamily.
If a device has a complex set of stream formats, it is possible to set the
device to an invalid stream configuration with the current implementation
(10.3.3).
It can also be difficult to set the device to a correct stream
configuration.
For example, if a device has the following output stream configurations:
44.1k-18Chan-24bit
48k-18Chan-24bit
88.2k-14Chan-24bit
96k-14Chan-24bit
In AMS, you get two popup menus under the Output section
Sample Rate & Stream Config
If you have the device set to the 18 Channel stream, AMS will not let you
select 88.2 or 96k from the Sample Rate popup. Conversely if you have the 14
Channel Stream selected, AMS will not allow you to select 44.1 or 48k.
OTOH, if you have 48k selected, AMS will allow you to select the 14 channel
stream format. Other invalid combinations are also allowed.
If you check out the validateFormat() method in IOAudioStream from
IOAudioFamily, it only checks to see if the format is registered,
irrespective of the sample rate. Since the stream format is actually
registered in combination with the Sample Rate this would seem to be
incorrect. And in fact, the stream will allow the format change to an
invalid format combination.
In the previous implementation of AMS (and also in Daisy), this would not
happen because the S/R and Stream Format were closely coupled.
It would seem that applications presenting this sort of interface need to be
more careful about validating the stream format that they construct from
these disparate elements; they also need to be smart about adjusting the
second element to match the user selected element -- e.g. if the user
selects the S/R, the app should find a valid format with that S/R.
Actually, it almost seems like AMS has it backwards -- S/R should force
stream width, changing the stream width should not be allowed to happen
unless there are multiple widths available for the specified sample rate.
As it is, the S/R change request from AMS never makes it to the
performFormatChange() method in the IOAudioEngine if the stream width is
wrong. I can't see where this would error out in the IOAudioFamily code --
it seems like AMS is determining that the change is not valid. HALLab has
the same behavior.
Am I misunderstanding either the intent of this, or some implementation
requirement in the driver to cope with this case, or is this just not quite
right yet?
Best regards,
B.J. Buchalter
Metric Halo
5 Donovan Drive
Hopewell Junction, NY 12533 USA
_______________________________________________
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.