[wdmaudiodev] Re: External clock synchronization and sample rate issue
- From: "Philip Lukidis" <plukidis@xxxxxxxxxxxxx>
- To: <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Thu, 11 Jan 2007 08:11:00 -0500
Yes, a simpler approach would be great. It was quite simple under WinXP-
merely constrain the dataintersection handler, and SetFormat handler.
-----Original Message-----
From: wdmaudiodev-bounce@xxxxxxxxxxxxx on behalf of Markus Bollinger
Sent: Thu 1/11/2007 4:56 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
URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/
Other related posts:
