[wdmaudiodev] Re: My driver doesn't work on Vista RC2!

  • From: "Jeff Pages" <barefeet@xxxxxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Thu, 2 Nov 2006 19:25:19 +1100

I'm not seeing any calls to my DataIntersectionHandler at all - what I outlined was the sum total of all activity. 


Jeff
----- Original Message ----- From: "Eugene Muzychenko" <emuzychenko@xxxxxxxxx> 
To: "Jeff Pages" <wdmaudiodev@xxxxxxxxxxxxx>
Sent: Thursday, November 02, 2006 7:07 PM
Subject: [wdmaudiodev] Re: My driver doesn't work on Vista RC2!



Hello Jeff!


4. The stream's MappingAvailable function is called. In response I call
IPortWavePciStream::GetMapping and receive one mapping. A second call to
GetMapping returns STATUS_NOT_FOUND.
5. The stream's MappingAvailable function is called again, and in response I 
call IPortWavePciStream::GetMapping and receive another mapping. A second
call to GetMapping returns STATUS_NOT_FOUND.
6. The stream's RevokeMapping function is called twice, once for each of the 
mappings obtained.
7. The stream's SetState function is called with state KSSTATE_ACQUIRE.
8. The stream's SetState function is called with state KSSTATE_STOP.
9. The stream object is released.


I often see such behavior under Windows 2k/XP, and under Vista RC2
too. I think some upper audio layer (kmixer, sysaudio, DirectSound and/or
MME) performs a kind of testing. A first stream is created, data
buffer IRPs are passed causing MappingAvailable to be called, then a
stream is destroyed. But next streams are created and used
successfully.


My first observation is that the call to my MappingAvailable function at
step 4 seems odd, since according to the WDK documentation, this function
should only be called if a previous call to IPortWavePciStream::GetMapping 
failed.


As I know, MappingAvailable is called in response to
IOCTL_KS_READ_STREAM/IOCTL_KS_WRITE_STREAM IPRs if portcls mapping
list is empty. So it is called when first data IRP is received.


I don't believe this unsolicited call to MappingAvailable is causing
the problem, but it's unexpected. If I ignore it instead of acquiring
mappings


MappingAvailable is only a notification function, no more. You may
respond by calling GetMapping or may not, it must not alter portcls
behavior.
My second observation is that the system never tries to set the stream state 
to KSSTATE_RUN. Instead, after I've acquired those two mappings, it just
immediately revokes them and releases the stream.


It seems like a kind of testing.


If my calling application is using the wave API, waveOutOpen returns
MMSYSERR_ERROR. If it is a DirectSound application, everything succeeds
until I call Play on my buffer which then returns E_POINTER.


Try to protocol data intersection requests and their results. Maybe
RC2 try to open "wider" stream for kmixer than RC1 and 2k/XP.

Regards,
Eugene

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

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:

  1. Home
  2. wdmaudiodev
  3. Archive
  4. 11-2006