[wdmaudiodev] Re: External clock synchronization and sample rate issue

  • From: Hakon Strande <hakons@xxxxxxxxxxxxxxxxxxxxx>
  • To: Markus Bollinger <bollinger@xxxxxxxxxxxx>, <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Wed, 14 Mar 2007 14:47:42 -0700

The bug "Need a way for a device to advertise realtime format caps changes" is 
currently not a Windows OS Bug since the feature is part of the ongoing feature 
planning/prioritization process for the next version of Windows and given the 
ability for 3rd parties to work around this in the driver:

"Custom audio driver implements a different PnP device interface for each of 
the possible formats."

This means it is currently not slated for QFE or SP1 release. If you feel 
strongly this is unacceptable (and I think many of you will) please consider 
going through Microsoft premier product support channels to file a QFE request 
against Vista for this issue. We need officially documented demand to justify 
working on this sooner than what is now planned.


Hakon Strande | Windows Sound Team PM | (p) 425.705.0637

-----Original Message-----
From: Markus Bollinger [mailto:bollinger@xxxxxxxxxxxx] 
Sent: Tuesday, March 13, 2007 2:59 AM
To: wdmaudiodev@xxxxxxxxxxxxx; Hakon Strande
Subject: Re: [wdmaudiodev] Re: External clock synchronization and sample rate 

Hello Hakon,
are there any news about this subject ?


Hakon Strande a écrit :
> We have certainly taken note of this. I can't promise that we will remedy 
> this any time soon though but we will include this issue in our planning 
> going forward.
> Sincerely,
> Hakon Strande
> PM Integrated, Internal, External, and Wireless Audio Devices
> MediaTech/DMD/Windows Client/Microsoft
> -----Original Message-----
> From: wdmaudiodev-bounce@xxxxxxxxxxxxx 
> [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Markus Bollinger
> Sent: Thursday, January 11, 2007 1:57 AM
> To: wdmaudiodev@xxxxxxxxxxxxx
> Subject: [wdmaudiodev] Re: External clock synchronization and sample rate 
> issue
> Stephan Kappertz a écrit :
>> I'm sorry but don't we agree that this is an ugly workaround? Is there 
>> any chance for a better implementation of external sample rate control 
>> from the Microsoft side? Please!
>> I would suggest that the audio subsystem should call the intersection 
>> handler if opening the driver fails at the preselected sample rate. If 
>> the driver suggests a different sample rate, this should be used as 
>> new default rate.
> Hello Stephan!
> I agree with your idea;
> There are surely more than we two who would appreciate if such an 
> implementation could be done by Microsoft!
>> - Stephan
>> Jeff Pages wrote:
>>> I've found under Vista stopping and starting drivers is quite fast - 
>>> we have a FM radio capture card that creates 24 capture devices, and 
>>> I can stop and start that in just a second or two on Vista whereas on 
>>> XP you just about die of old age waiting for it!
>>> ----- Original Message ----- From: "Matt Gonzalez" <matt@xxxxxxxxxxxxx>
>>> To: <wdmaudiodev@xxxxxxxxxxxxx>
>>> Sent: Thursday, January 11, 2007 1:29 PM
>>> Subject: [wdmaudiodev] Re: External clock synchronization and sample 
>>> rate issue
>>>> OK, so you don't allow the sample rate to be set by Windows.   That 
>>>> would certainly work.
>>>> My descriptors are all built dynamically, so I wouldn't need 
>>>> different subdevices for the different rates.
>>>> I don't like stopping and restarting the driver 'cos  it takes so 
>>>> long to restart when you have a lot of audio devices.   I guess if 
>>>> that's what you have to do, then that's what you have to do.
>>>> Matt
>>>> Jeff Pages wrote:
>>>>> Matt,
>>>>> My card sounds very similar with multiple inputs and outputs driven 
>>>>> by a common clock. I use a property page accessible from Device 
>>>>> Manager to set the card clock, storing the clock value under the 
>>>>> device's hardware registry key and setting the 
>>>>> DI_FLAGSEX_PROPCHANGE_PENDING flag on exit which forces the driver 
>>>>> to be stopped and restarted.
>>>>> The driver, on starting, reads the clock setting from the registry 
>>>>> and activates the appropriate set of wave subdevices for that 
>>>>> sampling rate.
>>>>> Jeff
>>>>> ----- Original Message ----- From: "Matt Gonzalez" 
>>>>> <matt@xxxxxxxxxxxxx>
>>>>> To: <wdmaudiodev@xxxxxxxxxxxxx>
>>>>> Sent: Thursday, January 11, 2007 12:00 PM
>>>>> Subject: [wdmaudiodev] Re: External clock synchronization and 
>>>>> sample rate issue
>>>>>> OK, that makes sense.  So you know when you create the subdevice 
>>>>>> that you are only supporting one sample rate.
>>>>>> The problem I have is somewhat different - my driver creates 
>>>>>> multiple subdevices for each pair of inputs and outputs on the 
>>>>>> card.   All the subdevices share a common , internally generated 
>>>>>> hardware clock, so you would want to specify the same preferred 
>>>>>> format for all the inputs and outputs.
>>>>>> Obviously, having to go through the control panel and setting the 
>>>>>> preferred format for each audio device is not desirable.
>>>>>> It seems like in that case, you'd want to allow the full range of 
>>>>>> sample rates to be available.   But then - if you change one 
>>>>>> device, is there some way to propagate the change to all the 
>>>>>> others?   The discussion so far suggests that there is no way to 
>>>>>> do this automatically.
>>>>>> I'm thinking here of something along the lines of the IPortEvents 
>>>>>> interface, but I'm just spitballing.
>>>>>> Matt
>>>>>> Jeff Pages wrote:
>>>>>>> No, I don't call IoSetDeviceInterfaceState anywhere - presumably 
>>>>>>> the port class takes care of enabling device interfaces when the 
>>>>>>> subdevice is registered. Only one wave subdevice is ever created 
>>>>>>> at a time, it's just that it might have different parameters 
>>>>>>> (specifically supported sampling rate) depending on what the 
>>>>>>> hardware clock is when the subdevice is created. I think a 
>>>>>>> different subdevice name is needed for each option because Vista 
>>>>>>> stores the audio engine rate in the registry for each one.
>>>>>>> Jeff


WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe:  mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx


Other related posts: