In my driver I reset them on transition to KSSTATE_STOP. There is also a "reset" callback but I don't do anything there. It is on my list to see if that ever gets called. -----Original Message----- From: wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Nick Dowell Sent: Tuesday, September 05, 2006 3:59 AM To: wdmaudiodev@xxxxxxxxxxxxx Subject: [wdmaudiodev] Re: AVStream on Vista Do the KSAUDIO_POSITION Play and Write offsets need to be reset to 0 at any time during a Pin's life - for example upon transition to KSSTATE_STOP? The DDK is a bit ambiguous about this - simply stating that the values are offsets from the beginning of a stream. (when does a stream begin - at pin creation or transition from KSSTATE_STOP?) Cheers, Nick On 27 Feb 2006, at 20:12, Sam Tertzakian wrote: > My experience has been that XP is much more tolerant of errors in > an audio > driver than Vista. Since the audio stack in Vista has been > rewritten, minor > errors that caused no problem in XP cause big problems in Vista. So > just > because the driver works fine in XP, it could still mean there is a > bug that > XP over looks. > > The first things that I would check are: > > 1. Are you returning the proper position information in the > KSSTREAM_HEADER > and that it matches properly with what you are sending in > PlayOffset? It > should match properly to what the Play Offset returns. I would check > DataUsed, Duration, PresentationTime.Numerator, > PresentationTime.Denominator > and the OptionsFlags. > > 2. Make sure that Play offset always returns the last position it > returned > or a greater number. I cannot think of any situation where the > number should > return a number less than what it returned at a previous time. > > 3. My understanding is that basically you can say that PlayPosition > = how > many bytes have actually been played by the driver. WritePosition = > how many > bytes have been received by the driver. Is that how you are setting > the > numbers? > > 4. Are you sure that you are starting the stream in the correct > KS_STATE > transition? > > 5. Does your driver set KSPIN_FLAG_PROCESS_IN_RUN_STATE_ONLY in the > Pin > Options? My driver set this flag...I found it simplifies matters. > > 6. Are you sure you are always returning STATUS_SUCCESS in the Process > function and if not, that you are calling KsAttemptProcessing to > restart > processing? > > Those are my ideas for now...But, the most important thing I can > tell you is > not to feel a sense that things are proper because the driver works > under > XP. Almost certainly, you are not following the rules as stated in > the DDK > in a way that XP ignores...but Vista does not. That has been my > experience > with these types of issues. > > > -----Original Message----- > From: wdmaudiodev-bounce@xxxxxxxxxxxxx > [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Andrew Sha > Sent: Monday, February 27, 2006 11:33 AM > To: wdmaudiodev@xxxxxxxxxxxxx > Subject: [wdmaudiodev] AVStream on Vista > > Hi guys, > > > > I developed an audio driver that is implemented as an AVStream > minidriver. > It works fine on XP, but not on Vista. I got a hint to implement the > KSPROPERTY_AUDIO_POSITION property. It sort of helps - as far as I > keep the > PlayOffset equal to WriteOffest (kind of kludge), it seems to work > fine. But > > when I report the real PlayOffset that is behind the WriteOffset > about 100 > mS, the situation is screwed - after submitting of 30 mS of the PCM > data a > player issues KSPROPERTY_AUDIO_POSITION request endless, probably > waiting on > > the PlayOffset to be advanced. So how to instruct a player (either > the WMP > or the graphedit) about a portion of data that is needed to be pre- > buffered > by my driver? My first guess was the KSPROPERTY_AUDIO_LATENCY > property will > do the trick, but it is not requested at all. > > > > Any ideas? > > > > TIA > > Andrew > ****************** > > 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/