Re: SampleHardwareDriver bug?
Re: SampleHardwareDriver bug?
- Subject: Re: SampleHardwareDriver bug?
- From: "Mike Kluev" <email@hidden>
- Date: Mon, 19 Jan 2009 13:19:54 +0300
On Mon, 19 Jan 2009 12:53:40 +0300
"Mike Kluev" <email@hidden> wrote:
On Mon, 19 Jan 2009 12:15:37 +0300
"Mike Kluev" <email@hidden> wrote:
On Tue, 06 Jan 2009 12:26:31 Jeff Moore <email@hidden> wrote:
On Dec 18, 2008, at 5:43 AM, Mike Kluev wrote:
My HAL plugin is based on SampleHardwareDriver sample code. It has
more
than one sample rate, and while the rates are shown in HALLab and
AMS,
I can't change them. I traced it down to the following:
When my client app calls
AudioDeviceGetProperty(device, channel, isInput,
kAudioDevicePropertyNominalSampleRate ...)
the channel parameter is getting translated into the the
AudioObjectPropertyAddress's
inAddress.mElement and the isInput parameter is getting translated
into the
inAddress.mScope ('inpt' or 'outp') inside SampleHardwareDriver
plugin.
However, the SampleHardwareDriver's
HP_DeviceFormatList::GetPropertyData
completely ignores mScope (it has logic that tries input first, then
output).
Also, HP_DeviceFormatList::SetPropertyData completely ignores the
scope
(it has different logic in its kAudioDevicePropertyNominalSampleRate
handler
that not only ignores the scope but is completely incompatible with
the
GetPropertyData logic).
Is that not a bug in SampleHardwareDriver?
Since an AudioDevice is required to have only a single sample rate,
it
doesn't matter what scope kAudioDevicePropertyNominalSampleRate is
asked for in they should all return the same value.
The code in the HPBase classes takes an expansive view of the scope
passed in for a property query so that it can do it's best to always
satisfy the request. So one pattern you'll find in the HPBase
classes
is that for global scope properties, the scope won't ever actually
get
checked and the same value is always returned.
So no, I would not view this situation as a bug. There is likely
something else causing your problems with changing sample rates.
Jeff,
The whole reason I debugged it in my own app is because it didn't
work
right away when I tried to change sample rate from within AMS or
HALLab.
I took the fresh copy of SampleHardwarePlugin and modified its
SHP_Stream::AddAvailablePhysicalFormats() to include a second format
(all fields the same as in the first formar except for the sample
rate).
With this change both rates are shown in AMS and HALLab, but the
rate
can't be changed there. What should I do to fix it?
BTW, why AMS has two fields for Input and Output sample rates for a
single device? (HALLab has only rate one which looks correct).
Additional information.
This is what happens on set nominal sample rate (done with HALLab):
AudioDeviceSetProperty(isInput=NO, Rate)
-->
HP_DeviceFormatList::SetPropertyData(inAddress scope='outp')
-->
...
HP_Stream* theStream =
mOwningDevice->GetStreamByPropertyAddress(inAddress, false);
...
theStream->SetCurrentNominalSampleRate(theNewSampleRate, true);
// theStream is output stream
And this is what happens on get nominal sample rate (done from
HALLab when
it updates its rate popup to show the current rate):
AudioDeviceGetProperty(isInput = NO);
-->
HP_Device::GetCurrentNominalSampleRate()
{
...
if(HasInputStreams()) // yes, there is input stream
{
theStream = GetStreamByIndex(true, 0);
}
else if(HasOutputStreams())
{
theStream = GetStreamByIndex(false, 0);
}
if(theStream != NULL)
{
theAnswer = theStream->GetCurrentNominalSampleRate();
// the stream here is *input* stream
}
return theAnswer;
}
So the rate is set for the output scope and get from the input scope
(no matter what
is passed to "isInput" of AudioDeviceGetProperty).
If inside:
HAL/HPBase/HP_DeviceFormatList::SetPropertyData()
I remove the test for isDone where it sets
kAudioDevicePropertyNominalSampleRate,
then it begins to work correctly:
....
case kAudioDevicePropertyNominalSampleRate:
....
for(theSectionIndex = 0; /*!isDone &&*/ (theSectionIndex < 2);
++theSectionIndex)
....
for(theIndex = 0; /*!isDone &&*/ (theIndex < theNumberItems);
++theIndex)
However I haven't tested it thoroughly. Is this correct fix?
Mike
_______________________________________________
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