Hi.  I have a 1394 audio device for which I use a portcls style miniport.
I'm thinking of porting to avstream in order that surprise removal be
properly supported.  Question: is there any way to properly and override the
dispatch table of the parent driver (specifically, for DeviceIoControl so my
control panel can talk to me). KSDEVICE_DISPATCH is available (but not
really suitable for me) in WinXP+ only, and at the very least I have to
support Win2k also (probably Win98SE and ME as well).  I did not see any
PcDispacthIrp equivalent, like there is in portcls drivers.

Any thoughts?

Philip Lukidis

PS: So far I always have had a bus driver architecture, i.e. bus driver
enumerates the audio driver, and the control panel talked to the bus driver.
But this may not always be the case for me.

----- Original Message ----- 
From: "Waldemar Haszlakiewicz" <waldemar.haszlakiewicz@xxxxxxxx>
To: "Matt Gonzalez" <wdmaudiodev@xxxxxxxxxxxxx>
Sent: Saturday, March 06, 2004 6:29 AM
Subject: [wdmaudiodev] Re: Which type of driver


  

Then again AVStream has lots of stuff implemented already there is less
    

writing, but yes more
  

thinking (read breaking your head).
BUT when you figure it out everything looks very clean and simple.

Anyway if you'll write AVStream driver you'll have to read older drivers
    

docs also (well not
  

everything) as some things are just upgrades.
In short: AVStream hides a lot of stuff from you, so you don't need to
    

bother with them.
  

Waldemar


MG> This is exactly what I've been doing.

MG> If you want to talk to a 1394 device, you have to make your own
    

IRPsand send them to the
  

MG> 1394 stack. You will find examples on how to dothis in the 1394
    

samples. Compuware's
  

MG> DriverWorks also has usefulsample code for talking to 1394.

MG> To expose your hardware as an audio device, you need to create a
    

kernelstreaming filter.
  

MG> You can try using portclass miniports (like MSVAD)or AVStream. There's
    

also the older stream
  

MG> class stuff, but you'd bebetter off with AVStream.

MG> Portclass is an older model and doesn't handle surprise removal
    

aswell. AVStream is
  

MG> cleaner, but there is no good example code forbuilding an audio
    

driver. Portclass is perhaps
  

MG> quirkier, but muchbetter documented.

MG> Both AVC.sys and 61883.sys weren't useful for our purposes.
    

AVC.sysdoesn't support audio
  

MG> formats. 61883.sys didn't give me enoughcontrol over the streaming.

MG> Matt

MG> John D. Farmer wrote:




MG>       Greetings,

MG>

MG>   I'm new to Audio driver developmentand still pretty new to driver
    

development in
  

MG> general. I am working ona project that needs to stream audio data down
    

to the 1394 Bus,
  

MG> viaAVC.sys and 61883.sys. The overall propose of my project is to
    

supportFirewire hardware that
  

MG> will implement the IEC-61883-6 standard (whichMicrosoft says they were
    

going to support, but
  

MG> which I have yet to seesupported). I am guessing I am in need of a
    

upper filter driver totake
  

MG> care of the passing down audio data through the AV/C stack (inplace of
    

the avcaudio.sys which I
  

MG> cannot find on my system but found inthe documentation as: Kernel-Mode
    

WDM Audio Components
  

MG> subsection:AVCAudio Class System Driver) and another driver below
    

avc.sys to beable to package
  

MG> the audio data up into the 61883-6 standard format onits way down to
    

the 1394 bus (since I do
  

MG> not believe that 61883.sysdoes not yet support the 61883-6 standard).

MG>

MG>   I have been perusing thedocumentation and this list and there seems
    

to be alot of
  

MG> confusion tome on which way would be best to do this. I started by
    

trying to useMSVAD (which I
  

MG> believe is a Port Class driver), but then I noticed thatMSVAD does not
    

seem to handle IRPs or
  

MG> anything else that would allow meto send data down to the 1394 bus. I
    

looked at the MSDN docs
  

MG> and theysaid that Port Class drivers could not be used for this
    

purpose. I tooka look at
  

MG> this list, and it seems a number of people have been able todo this by
    

implementing their own
  

MG> IRPs and URBs (in the case of USB). I've taken note of this and
    

noticed that it seems to be
  

MG> extremelydifficult to do, and probably not the best way to handle this
    

problem.
  

MG>

MG>   I then started to lookat the AVStream and Stream class drivers. The
    

AVStream overview
  

MG> onMSDN that it is a: "multimediaclass driver that supports video-only
    

streaming and
  

MG> integratedaudio/video streaming." So does this mean that I cannot use
    

AVStreamto stream
  

MG> audio-only? My last option was the Stream class driver whichthe MSDN
    

docs seem to suggest that
  

MG> these driver are almost if nottotally deprecated.

MG>

MG>   I also looked at AV/C Client driver(which I think is a Stream
    

Minidriver) as a option,
  

MG> and it seemed to bealmost what I wanted, but the documentation says
    

that the avcstream.sysplays
  

MG> a part in the AV/C stack, my big problem with this is: I can'tfind
    

avcstream.sys on my system
  

MG> (I'm running Windows XP) see: IEC-61883Protocol Driver in a Client
    

Driver Stack in the MSDN
  

MG> documentation. AmI correct in assuming that avcstream.sys handles the
    

AV/C Audio subunit?
  

MG>

MG>   So as you can probably tell, I am alittle lost and confused on this
    

subject. If there is
  

MG> anyone out therewho could give this newbie a little guidance, I would
    

be in youreternal debt.
  

MG>

MG>   Thanks,

MG>

MG>   John Farmer


MG> ******************WDMAUDIODEV addresses:Post message:
MG> mailto:wdmaudiodev@xxxxxxxxxxxxxxxxxxxxxx:
MG> mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribeUnsubscribe:
MG> mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribeModerator:
MG> mailto:wdmaudiodev-moderators@xxxxxxxxxxxxxxxx to WDMAUDIODEV
    

page:http://www.wdmaudiodev.de/
  

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

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.de/


    

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

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.de/