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

  • From: Mitchell Rundle <mitchr@xxxxxxxxxxxxx>
  • To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Wed, 17 Jan 2007 13:12:38 -0800

I'm happy to help.

This is definitely unexpected behavior.  What status code are you returning in 
the _PROPOSEDATAFORMAT handler when you are queried for 44100?

Mitch

-----Original Message-----
From: wdmaudiodev-bounce@xxxxxxxxxxxxx 
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Philip Lukidis
Sent: Wednesday, January 17, 2007 10:50 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: External clock synchronization and sample rate issue

Mitch, thanks for taking the time to answer this question and warn of this race 
condition.  I do have one quick and related question- is it normal for the 
caller of _PROPOSEDATAFORMAT to require that 44100 16 bits to be supported?  I 
can constrain my filter's sample rate with a DataRangeIntersection handler, but 
NOT with a _PROPOSEDATAFORMAT handler.  Once my _PROPOSEDATAFORMAT handler 
refuses to support 44100, I'm never called with another sample rate.

thanks,

Philip Lukidis


> -----Original Message-----
> From: wdmaudiodev-bounce@xxxxxxxxxxxxx
> [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx]On Behalf Of Mitchell Rundle
> Sent: Wednesday, January 17, 2007 1:15 PM
> To: wdmaudiodev@xxxxxxxxxxxxx
> Subject: [wdmaudiodev] Re: External clock synchronization and sample
> rate issue
>
>
> It should be sufficient to just toggle the presence and name
> of the topology filter.  The wave filter can generally be left alone.
>
> You should use IUnregisterSubdevice and
> IUnregisterPhysicalConnection for this (see portcls.h) and
> you should unregister/register subdevices and physical
> connections in the following order:
>
> 1) unregister the topology subdevice
> 2) unregister the physical connection between the wave and
> topology filters
> 3) release the topology subdevice
> 4) flip whatever bits you need in the wave subdevice to
> change the format capabilities
> 5) create a new topology subdevice with a new name
> 6) register the new physical connection
> 7) register the new subdevice
>
> It might seem more natural to switch the order of (1) and (2)
> as well as (6) and (7).  Doing so however introduces a race
> condition between subdevice registration and the endpoint
> builder service and you may will end up with a bogus
> "disabled" endpoint associated with the bridge pin on the wave device.
>
> Regards,
> Mitch Rundle
>
> This posting is provided "AS IS" with no warranties, and
> confers no rights.
>
> -----Original Message-----
> From: wdmaudiodev-bounce@xxxxxxxxxxxxx
> [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Frank Yerrace
> Sent: Wednesday, January 17, 2007 8:56 AM
> To: wdmaudiodev@xxxxxxxxxxxxx
> Subject: [wdmaudiodev] Re: External clock synchronization and
> sample rate issue
>
> Wouldn't creating different device IDs via a bus driver cause
> multiple device driver installations. This would probably be
> a worse user experience.
>
> Frank Yerrace
>
> This posting is provided "AS IS" with no warranties, and
> confers no rights.
>
> -----Original Message-----
> From: wdmaudiodev-bounce@xxxxxxxxxxxxx
> [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Philip Lukidis
> Sent: Wednesday, January 17, 2007 6:07 AM
> To: wdmaudiodev@xxxxxxxxxxxxx
> Subject: [wdmaudiodev] Re: External clock synchronization and
> sample rate issue
>
> Hello Jeff,
>
> I'll have to see which approach is easier and go that route.
> Probably the method you suggested is easier, as opposed to my
> method of having a bus driver create a different ID based on
> the sample rate, and having to call
> IoInvalidateDeviceRelations to unload it in order to switch
> rates, etc.  Since I already had a bus driver it wasn't a big
> deal to test out.  I'll try it out with a topology/wave
> subdevice pair.
>
> thanks,
>
> Philip Lukidis
>
> > -----Original Message-----
> > From: wdmaudiodev-bounce@xxxxxxxxxxxxx
> > [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx]On Behalf Of Jeff Pages
> > Sent: Wednesday, January 17, 2007 6:47 AM
> > To: wdmaudiodev@xxxxxxxxxxxxx
> > Subject: [wdmaudiodev] Re: External clock synchronization and sample
> > rate issue
> >
> >
> > Hi Philip,
> >
> > I think I may have given you the wrong steer in an earlier
> > post. I said to
> > use multiple wave subdevices with a single topology
> > subdevice, but looking
> > at my code, I used multiple topology subdevices too, with one
> > pair of wave
> > and topology subdevices per sampling rate. It makes sense,
> > because the
> > engine sampling rate is associated with each endpoint, which
> > in turn relates
> > to a topology pin.
> >
> > Jeff
> >
> > ----- Original Message -----
> > From: "Philip Lukidis" <plukidis@xxxxxxxxxxxxx>
> > To: <wdmaudiodev@xxxxxxxxxxxxx>
> > Sent: Wednesday, January 17, 2007 8:00 AM
> > Subject: [wdmaudiodev] Re: External clock synchronization and
> > sample rate
> > issue
> >
> >
> > > Hello, I hope you don't mind if I ask a question again on
> > this topic.
> > > After a delay of a few days I managed to get back on this
> > and I got it to
> > > work- but only after a few somewhat painful measures.
> > >
> > > First I tried registering using the same HardwareID for my
> > device and
> > > registering the appropriate subdevice based on the selected
> > sample rate,
> > > but this did not work, despite the fact that I gave the
> subdevice a
> > > different name (the name passed to PcRegisterSubdevice, and
> > KSStudio
> > > confirmed that the name was different).  My single
> > HardwareID in the INF
> > > would register all interfaces (one for each sample rate).
> > While it worked
> > > for first sample rate during installation, it never worked
> > for any other
> > > sample rate; the system kept on remembering the first
> > sample rate.  For
> > > now, I would switch sample rate by using a registry value.
> > So a "switch"
> > > is provoked by an unplug of the device, changing the
> > registry value, and
> > > replugging.  Also, this only worked with a
> > DataRangeIntersection handler-
> > > if I implemented a KSPROPERTY_PIN_PROPOSEDATAFORMAT
> > handler, it did NOT
> > > like an absence of 44100.
> > >
> > > I was only able to get it to work by moving to a different device
> > > altogether, by having my virtual bus driver announce a different
> > > HardwareID based on the sample rate (so we are no longer
> talking of
> > > subdevices on a device object; the device object is now
> > different).  Of
> > > course, the first switch to a new rate provokes an
> > installation, which is
> > > not the end of the world, but not ideal either.
> > >
> > > My question is: can I get this scheme to work with just
> > registering the
> > > appropriate subdevice on the same device object based on
> > the sample rate
> > > (Frank Yerrace's text suggests- at least to me- that it
> > can)?  If so, any
> > > clues on what I may have overlooked?  I have not even yet
> > touched dynamic
> > > subdevice unregistration and dynamic physical disconnection.
> > >
> > > thanks,
> > >
> > > Philip Lukidis
> > >
> > >> -----Original Message-----
> > >> From: wdmaudiodev-bounce@xxxxxxxxxxxxx
> > >> [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx]On Behalf Of Jeff Pages
> > >> Sent: Wednesday, January 10, 2007 5:55 PM
> > >> To: wdmaudiodev@xxxxxxxxxxxxx
> > >> Subject: [wdmaudiodev] Re: External clock synchronization
> > and sample
> > >> rate issue
> > >>
> > >>
> > >> I had a similar problem, where I wanted the audio engine
> > >> sampling rate of
> > >> each endpoint to match the hardware clock on my card which
> > >> was set globally
> > >> in a driver property page.
> > >>
> > >> One of the Microsoft people suggested I have several
> different wave
> > >> miniports (each with a different name) defined in my inf file
> > >> and driver,
> > >> with each supporting only one sampling rate in its pin
> > >> datarange structure,
> > >> and only instantiating the one corresponding to the hardware
> > >> clock. Since my
> > >> driver was unloaded and reloaded if the hardware clock was
> > >> changed in my
> > >> Device Manager property page, this was pretty easy to
> > >> implement and worked
> > >> well.
> > >>
> > >> In your case, where the external clock can change while
> > the driver's
> > >> running, you might be able to use the
> > >> IUnregisterPhysicalConnection and
> > >> IUnregisterSubdevice interfaces to remove the current
> > >> subdevice and then
> > >> activate and register the one corresponding to the new rate
> > >> (see the stuff
> > >> on Dynamic Audio Subdevices in the WDK).
> > >>
> > >> Jeff Pages
> > >> Innes Corporation Pty Ltd
> > >>
> > >> ----- Original Message -----
> > >> From: "Philip Lukidis" <plukidis@xxxxxxxxxxxxx>
> > >> To: <wdmaudiodev@xxxxxxxxxxxxx>
> > >> Sent: Thursday, January 11, 2007 9:20 AM
> > >> Subject: [wdmaudiodev] External clock synchronization and
> > >> sample rate issue
> > >>
> > >>
> > >> > Hello.  I'm wondering if anyone else has any clue about
> > >> solving this
> > >> > issue.  My audio device can be clocked from an external
> > >> source.  For
> > >> > example, the audio format of the device can be set to 16
> > >> bits 44100 in the
> > >> > advanced tab in the MS audio cpl, and thereafter using our
> > >> own control
> > >> > panel be clocked off an external source which is at the
> > >> same rate of
> > >> > 44100.
> > >> >
> > >> > Now say that the external source's clock changes from 44100
> > >> to 48000.
> > >> > Under XP, my datarange intersection handler would merely
> > >> constrain the
> > >> > format's sample rate to match the new external sample rate.
> > >>  Under Vista,
> > >> > the system will never try to send at any other rate other
> > >> than what is the
> > >> > selected rate in the advanced tab of the audio device.
> > >> >
> > >> > Does anyone have a suggestion as to how to cope with this?
> > >> Is there a way
> > >> > to programmatically change the selected format of the
> > >> device?  Or is there
> > >> > another approach?
> > >> >
> > >> > thank you,
> > >> >
> > >> > Philip Lukidis
> > >> > ******************
> > >> >
> > >> > 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/
> > >> >
> > >> >
> > >>
> > >> ******************
> > >>
> > >> 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/
> > >>
> > >>
> > > ******************
> > >
> > > 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/
> > >
> > >
> >
> > ******************
> >
> > 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/
> >
> >
> ******************
>
> 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/

******************

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/

******************

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/

******************

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/

******************

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: