Hi all,
I am new to Avstream audio drivers. I want to expose
KSPROPERTY_CONNECTION_ALLOCATORFRAMING property from my driver so i can
access in the user mode using
*IKsPropertySet::Get*http:,
i gone through “http://www.wd-3.com/archive/KsProxyPlugin.htm” and got some
idea. Can any one help me out regarding this.
1. How can i expose this through an pin or through an node?
2. i wanted to know how much frames and what are the frame size that will
be passed from the lower level drivers
Thanks
Dennis Scott.</http:>
Dennis Scott wrote:
I am new to Avstream audio drivers. I want to expose
KSPROPERTY_CONNECTION_ALLOCATORFRAMING property from my driver so i
can access in the user mode using *IKsPropertySet::Get*
http:, i gone
> through “http://www.wd-3.com/archive/KsProxyPlugin.htm” and got some
> idea. Can any one help me out regarding this.
>
> 1. How can i expose this through an pin or through an node?
> 2. i wanted to know how much frames and what are the frame size that
> will be passed from the lower level drivers
Why?
All AVStream drivers support KSPROPERTY_CONNECTION_ALLOCATORFRAMING.
The AVStream framework provides this automatically, based on the
AllocatorFraming member of the KSPIN_DESCRIPTOR_EX. You don’t have to
support this explicitly.
However, this is not something that you should be worrying about in user
mode. AVStream and DirectShow will cooperate to allocate the number and
size of buffers for this pin, as negotiated between the driver and the
next downstream filter. I cannot think of anything useful you could do
with this information if you had it.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</http:>
Thanks Tim,
So this means
- I can call IKsPropertySet::Get directly from the user mode with out doing
any thing in the driver? - Now once i get the buffer size and the number of buffers in the user
mode, is their any possibility of changing these??(using SET) If my
assumptions are wrong sorry. - I am just learning the AVSTREAM so just want to known how to use all the
KSPROPERTYS.
Thanks
Dennis Scott.
On Wed, Jul 15, 2009 at 10:00 PM, Tim Roberts wrote:
> Dennis Scott wrote:
> >
> > I am new to Avstream audio drivers. I want to expose
> > KSPROPERTY_CONNECTION_ALLOCATORFRAMING property from my driver so i
> > can access in the user mode using IKsPropertySet::Get
> > http:, i gone
> > through “http://www.wd-3.com/archive/KsProxyPlugin.htm” and got some
> > idea. Can any one help me out regarding this.
> >
> > 1. How can i expose this through an pin or through an node?
> > 2. i wanted to know how much frames and what are the frame size that
> > will be passed from the lower level drivers
>
> Why?
>
> All AVStream drivers support KSPROPERTY_CONNECTION_ALLOCATORFRAMING.
> The AVStream framework provides this automatically, based on the
> AllocatorFraming member of the KSPIN_DESCRIPTOR_EX. You don’t have to
> support this explicitly.
>
> However, this is not something that you should be worrying about in user
> mode. AVStream and DirectShow will cooperate to allocate the number and
> size of buffers for this pin, as negotiated between the driver and the
> next downstream filter. I cannot think of anything useful you could do
> with this information if you had it.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
></http:>
Dennis Scott wrote:
So this means
- I can call IKsPropertySet::Get directly from the user mode with out
doing any thing in the driver?
Of course. Those are available for every kernel streaming driver in a
graph, thanks to ksproxy. For many of the properties, it doesn’t make
any sense for anyone other than ksproxy to manipulate them, and most of
the properties map to native DirectShow interfaces that should be used
instead, but it is available.
There used to be some issue with the IKsPropertySet interface, although
I don’t recall what it was, and it might have been solved long ago. By
force of habit, I usually use IKsControl::KsProperty.
- Now once i get the buffer size and the number of buffers in the
user mode, is their any possibility of changing these??(using SET) If
my assumptions are wrong sorry.
Why would you want to do so? The driver sets the buffer size so that it
is convenient for the driver. For a video capture driver, the buffer
size will usually be the size of a frame. For MPEG streams, it’s a
multiple of the Transport Stream packet size.
Further, this is not something that an application writer worries
about. The buffer negotiation is part and parcel of DirectShow.
Ksproxy participates in this negotiation on behalf of the driver, using
the FRAMING properties from the driver. If the next downstream filter
happens to want additional buffers, it can try to do so using the normal
DirectShow buffer negotiation, but the driver has the right to refuse
that change.
- I am just learning the AVSTREAM so just want to known how to use
all the KSPROPERTYS.
What point of view are you trying to learn? From the user mode point of
view, AVStream is irrelevant. Your capture driver appears in your
DirectShow graph as a user-mode capture filter, and you use the standard
DirectShow interfaces to talk to it. Behind the scenes, ksproxy is
translating the DirectShow interfaces into KSPROPERTY calls as needed,
but the rest of the graph doesn’t need to know that. That’s the beauty
of DirectShow. I can replace my capture driver by a user-mode capture
filter (maybe reading video over a network) that doesn’t use
KSPROPERTYs, and the rest of the graph doesn’t have to change at all.
If you are trying to write AVStream drivers, that’s another story.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks Tim for those valuable Responses
-
Actually I am a C/C++ developer from past 4 years, now i wanted to learn
kernel programming So i started with Audio device drivers both portcls and
Avstream( i Know both audio/video) . -
Since portcls is also an kernel stream drivers can the KSPROPERTYES be
applied to portcls drivers?? -
If yes how to use KSPROPERTY_CONNECTION_ALLOCATORFRAMING or any other
propertyes in portcls driver (which are defaulty exposed by avstream) -
I wanted to change the buffer size and the number of buffer is it
possible??( let it be in kernel side OR on user side) -
I went through “MSVAD” and also “avshws” both are very good examples can
i treat these as my starting point in studying the Avstream ans portcls
device driver?
Thanks
Dennis Scott.
On Thu, Jul 16, 2009 at 10:49 PM, Tim Roberts wrote:
> Dennis Scott wrote:
> >
> > So this means
> > 1. I can call IKsPropertySet::Get directly from the user mode with out
> > doing any thing in the driver?
>
> Of course. Those are available for every kernel streaming driver in a
> graph, thanks to ksproxy. For many of the properties, it doesn’t make
> any sense for anyone other than ksproxy to manipulate them, and most of
> the properties map to native DirectShow interfaces that should be used
> instead, but it is available.
>
> There used to be some issue with the IKsPropertySet interface, although
> I don’t recall what it was, and it might have been solved long ago. By
> force of habit, I usually use IKsControl::KsProperty.
>
>
> > 2. Now once i get the buffer size and the number of buffers in the
> > user mode, is their any possibility of changing these??(using SET) If
> > my assumptions are wrong sorry.
>
> Why would you want to do so? The driver sets the buffer size so that it
> is convenient for the driver. For a video capture driver, the buffer
> size will usually be the size of a frame. For MPEG streams, it’s a
> multiple of the Transport Stream packet size.
>
> Further, this is not something that an application writer worries
> about. The buffer negotiation is part and parcel of DirectShow.
> Ksproxy participates in this negotiation on behalf of the driver, using
> the FRAMING properties from the driver. If the next downstream filter
> happens to want additional buffers, it can try to do so using the normal
> DirectShow buffer negotiation, but the driver has the right to refuse
> that change.
>
>
> > 3. I am just learning the AVSTREAM so just want to known how to use
> > all the KSPROPERTYS.
>
> What point of view are you trying to learn? From the user mode point of
> view, AVStream is irrelevant. Your capture driver appears in your
> DirectShow graph as a user-mode capture filter, and you use the standard
> DirectShow interfaces to talk to it. Behind the scenes, ksproxy is
> translating the DirectShow interfaces into KSPROPERTY calls as needed,
> but the rest of the graph doesn’t need to know that. That’s the beauty
> of DirectShow. I can replace my capture driver by a user-mode capture
> filter (maybe reading video over a network) that doesn’t use
> KSPROPERTYs, and the rest of the graph doesn’t have to change at all.
>
> If you are trying to write AVStream drivers, that’s another story.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Thanks Tim for those valuable Responses
-
Actually I am a C/C++ developer from past 4 years, now i wanted to learn
kernel programming So i started with Audio device drivers both portcls and
Avstream( i Know both audio/video) . -
Since portcls is also an kernel stream drivers can the KSPROPERTYES be
applied to portcls drivers?? -
If yes how to use KSPROPERTY_CONNECTION_ALLOCATORFRAMING or any other
propertyes in portcls driver (which are defaulty exposed by avstream) -
I wanted to change the buffer size and the number of buffer is it
possible??( let it be in kernel side OR on user side) -
I went through “MSVAD” and also “avshws” both are very good examples can
i treat these as my starting point in studying the Avstream ans portcls
device driver?
Thanks
Dennis Scott.
On Fri, Jul 17, 2009 at 9:26 AM, Karthik Gurumurthy <
xxxxx@nextbitcpu.com> wrote:
Thanks Tim for those valuable Responses
Actually I am a C/C++ developer from past 4 years, now i wanted to learn
kernel programming So i started with Audio device drivers both portcls and
Avstream( i Know both audio/video) .Since portcls is also an kernel stream drivers can the KSPROPERTYES be
applied to portcls drivers??If yes how to use KSPROPERTY_CONNECTION_ALLOCATORFRAMING or any other
propertyes in portcls driver (which are defaulty exposed by avstream)I wanted to change the buffer size and the number of buffer is it
possible??( let it be in kernel side OR on user side)I went through “MSVAD” and also “avshws” both are very good examples can
i treat these as my starting point in studying the Avstream ans portcls
device driver?Thanks
Dennis Scott.On Thu, Jul 16, 2009 at 10:49 PM, Tim Roberts wrote:
>
>> Dennis Scott wrote:
>> >
>> > So this means
>> > 1. I can call IKsPropertySet::Get directly from the user mode with out
>> > doing any thing in the driver?
>>
>> Of course. Those are available for every kernel streaming driver in a
>> graph, thanks to ksproxy. For many of the properties, it doesn’t make
>> any sense for anyone other than ksproxy to manipulate them, and most of
>> the properties map to native DirectShow interfaces that should be used
>> instead, but it is available.
>>
>> There used to be some issue with the IKsPropertySet interface, although
>> I don’t recall what it was, and it might have been solved long ago. By
>> force of habit, I usually use IKsControl::KsProperty.
>>
>>
>> > 2. Now once i get the buffer size and the number of buffers in the
>> > user mode, is their any possibility of changing these??(using SET) If
>> > my assumptions are wrong sorry.
>>
>> Why would you want to do so? The driver sets the buffer size so that it
>> is convenient for the driver. For a video capture driver, the buffer
>> size will usually be the size of a frame. For MPEG streams, it’s a
>> multiple of the Transport Stream packet size.
>>
>> Further, this is not something that an application writer worries
>> about. The buffer negotiation is part and parcel of DirectShow.
>> Ksproxy participates in this negotiation on behalf of the driver, using
>> the FRAMING properties from the driver. If the next downstream filter
>> happens to want additional buffers, it can try to do so using the normal
>> DirectShow buffer negotiation, but the driver has the right to refuse
>> that change.
>>
>>
>> > 3. I am just learning the AVSTREAM so just want to known how to use
>> > all the KSPROPERTYS.
>>
>> What point of view are you trying to learn? From the user mode point of
>> view, AVStream is irrelevant. Your capture driver appears in your
>> DirectShow graph as a user-mode capture filter, and you use the standard
>> DirectShow interfaces to talk to it. Behind the scenes, ksproxy is
>> translating the DirectShow interfaces into KSPROPERTY calls as needed,
>> but the rest of the graph doesn’t need to know that. That’s the beauty
>> of DirectShow. I can replace my capture driver by a user-mode capture
>> filter (maybe reading video over a network) that doesn’t use
>> KSPROPERTYs, and the rest of the graph doesn’t have to change at all.
>>
>> If you are trying to write AVStream drivers, that’s another story.
>>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
Dennis Scott wrote:
- Actually I am a C/C++ developer from past 4 years, now i wanted to
learn kernel programming So i started with Audio device drivers both
portcls and Avstream( i Know both audio/video) .
Are you familiar with DirectShow, then? Understanding the DirectShow
model tends you give you a leg up in grasping the philosophical
decisions in the AVStream model.
- Since portcls is also an kernel stream drivers can the KSPROPERTYES
be applied to portcls drivers??
Yes, the standard driver half of port class is a KS driver and will use
this property. However, the framing property is not directly exposed to
the miniport. The port class driver will make calls into the miniport
to discover the information it needs to respond to the framing property.
- If yes how to use KSPROPERTY_CONNECTION_
ALLOCATORFRAMING or any other propertyes in portcls driver (which are
defaulty exposed by avstream)
The question, as you have written it, doesn’t particularly make sense.
Buffer framing is a negotiation between two pins that are connected
together. It is the responsibility of the destination pin to provide an
allocator to allocate buffers. The destination pin will ask the source
pin what its allocation requirements are, using that property. The
destination pin then merges that with whatever criteria it might have on
its own, creates an allocator that meets those requirements, allocates
buffers, and starts sending them to the source pin to be filled.
In some cases, the destination pin actually hands off responsibility for
the allocation to the next downstream filter, until it finally gets to
someone who cares enough to create an allocator.
So, unless you are a pin on a filter that is in the process of
connecting, you don’t worry about this. You CAN’T worry about this.
The owner of the graph simply does not get involved in this
communication. It’s part of the internal negotiation between the pins.
- I wanted to change the buffer size and the number of buffer is it
possible??( let it be in kernel side OR on user side)
Again, it depends on what you mean. If you are writing a filter that
will accept a connection from an upstream filter, then your pin will be
involved in the negotiation, and you can modify the framing requirements
from the source pin. You are only allowed to do so if the source pin
tells you so (by setting KSALLOCATOR_REQUIREMENTF_PREFERENCES_ONLY). If
it hasn’t given you that flag, then the source pin requires that the
allocator use its settings exactly.
- I went through “MSVAD” and also “avshws” both are very good
examples can i treat these as my starting point in studying the
Avstream ans portcls device driver?
Yes.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim Thanks,
After a weak of study (seems to be very less for the wonderfull word of DD)
of Avstream and portcls i decided to get into coding!!
Are you familiar with DirectShow, then? Understanding the DirectShow
model tends you give you a leg up in grasping the philosophical
decisions in the AVStream model.
No i am an pure C and C++ with exp of windows application programming with
VC++ (MFC,OLE…)
I read about DS and DX but not a prominent one.
Now my question is,
-
As the example of MAX “Extending KS Proxy with Custom Property Pages and
Interface Plug-ins” is it needed for all avstream drivers to write proxy i
want to get only the property and some methods (I dont want property pages) -
I went through wdm list and i found an article "
http://www.freelists.org/post/wdmaudiodev/Record-Buffer-Issue,3" this is why
i asked you my initial questions about setting frame size and number of
frames. -
So i decided to start with coding MSVAD as an virtual audio driver ( i
known lot and lot of people has already done that and VAC is a very good
example for that) i wanted this has my starting point. I wrote a buffer to
interface between copyto and copyfrom and it worked fine, Now what ever i
play in the win32 player application i am able to record in the win32
recorder application(I was glade my first program worked!!!) but the
problem in that is if the load of the OS increases the Recorded file will
have some loss of data i am not able to figure this out any suggestions???
Thanks
Dennis Scott.
On Fri, Jul 17, 2009 at 10:32 PM, Tim Roberts wrote:
> Dennis Scott wrote:
> >
> > 1. Actually I am a C/C++ developer from past 4 years, now i wanted to
> > learn kernel programming So i started with Audio device drivers both
> > portcls and Avstream( i Know both audio/video) .
>
> Are you familiar with DirectShow, then? Understanding the DirectShow
> model tends you give you a leg up in grasping the philosophical
> decisions in the AVStream model.
>
>
> > 2. Since portcls is also an kernel stream drivers can the KSPROPERTYES
> > be applied to portcls drivers??
>
> Yes, the standard driver half of port class is a KS driver and will use
> this property. However, the framing property is not directly exposed to
> the miniport. The port class driver will make calls into the miniport
> to discover the information it needs to respond to the framing property.
>
>
> > 3. If yes how to use KSPROPERTY_CONNECTION_
> > ALLOCATORFRAMING or any other propertyes in portcls driver (which are
> > defaulty exposed by avstream)
>
> The question, as you have written it, doesn’t particularly make sense.
>
> Buffer framing is a negotiation between two pins that are connected
> together. It is the responsibility of the destination pin to provide an
> allocator to allocate buffers. The destination pin will ask the source
> pin what its allocation requirements are, using that property. The
> destination pin then merges that with whatever criteria it might have on
> its own, creates an allocator that meets those requirements, allocates
> buffers, and starts sending them to the source pin to be filled.
>
> In some cases, the destination pin actually hands off responsibility for
> the allocation to the next downstream filter, until it finally gets to
> someone who cares enough to create an allocator.
>
> So, unless you are a pin on a filter that is in the process of
> connecting, you don’t worry about this. You CAN’T worry about this.
> The owner of the graph simply does not get involved in this
> communication. It’s part of the internal negotiation between the pins.
>
>
> > 4. I wanted to change the buffer size and the number of buffer is it
> > possible??( let it be in kernel side OR on user side)
>
> Again, it depends on what you mean. If you are writing a filter that
> will accept a connection from an upstream filter, then your pin will be
> involved in the negotiation, and you can modify the framing requirements
> from the source pin. You are only allowed to do so if the source pin
> tells you so (by setting KSALLOCATOR_REQUIREMENTF_PREFERENCES_ONLY). If
> it hasn’t given you that flag, then the source pin requires that the
> allocator use its settings exactly.
>
>
> > 5. I went through “MSVAD” and also “avshws” both are very good
> > examples can i treat these as my starting point in studying the
> > Avstream ans portcls device driver?
>
> Yes.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Dennis Scott wrote:
Now my question is,
- As the example of MAX “Extending KS Proxy with Custom Property
Pages and Interface Plug-ins” is it needed for all avstream drivers to
write proxy i want to get only the property and some methods (I dont
want property pages)
** IF ** you want to expose your own custom properties through a
friendly COM interface wrapper, then you need a ksproxy plugin. But, if
you are willing to access your custom properties using the IKsControl
interface, then no plugin is needed. For standard properties, the
plugin concept does not apply.
- I went through wdm list and i found an article
“http://www.freelists.org/post/wdmaudiodev/Record-Buffer-Issue,3” this
is why i asked you my initial questions about setting frame size and
number of frames.
Yes, but you need to read the whole message. This is about a driver
that wants more control over its OWN buffering. A port class minidriver
doesn’t get directly involved in the property exchange (the class driver
handles it for you), so the author was suggesting intercepting the
property ioctl directly.
- So i decided to start with coding MSVAD as an virtual audio driver
( i known lot and lot of people has already done that and VAC is a
very good example for that) i wanted this has my starting point. I
wrote a buffer to interface between copyto and copyfrom and it worked
fine, Now what ever i play in the win32 player application i am able
to record in the win32 recorder application(I was glade my first
program worked!!!) but the problem in that is if the load of the OS
increases the Recorded file will have some loss of data i am not able
to figure this out any suggestions???
The input and output applications are not synchronized. If you assume
that you get one read request for each write request, then inevitably
you will lose data. You need at least a little bit of buffering in there.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi,
** IF ** you want to expose your own custom properties through a
friendly COM interface wrapper, then you need a ksproxy plugin. But, if
you are willing to access your custom properties using the IKsControl
interface, then no plugin is needed. For standard properties, the
plugin concept does not apply.
Thanks that answers my question, so if i want to expose my own custom
property then only i have to write
plugins.
Now how can i know what are the default propertyes the driver exposes (can
graphedit will help).Or i have to write DS
program to query the driver using IKsObject and KsSynchronousDeviceControl?
The input and output applications are not synchronized. If you assume
that you get one read request for each write request, then inevitably
you will lose data. You need at least a little bit of buffering in there.
Yes i am buffering the data which is played by the player, the buffer is a
cyclic buffer of size (40 * PAGE_SIZE). Is this too heavy or the buffering
is not correct??
I got this problem in XPSP3, but this problem is not visible in VISTASP1.
Thanks
Dennis Scott.
On Mon, Jul 20, 2009 at 11:03 PM, Tim Roberts wrote:
> Dennis Scott wrote:
> >
> > Now my question is,
> >
> > 1. As the example of MAX “Extending KS Proxy with Custom Property
> > Pages and Interface Plug-ins” is it needed for all avstream drivers to
> > write proxy i want to get only the property and some methods (I dont
> > want property pages)
>
> IF you want to expose your own custom properties through a
> friendly COM interface wrapper, then you need a ksproxy plugin. But, if
> you are willing to access your custom properties using the IKsControl
> interface, then no plugin is needed. For standard properties, the
> plugin concept does not apply.
>
>
> > 2. I went through wdm list and i found an article
> > “http://www.freelists.org/post/wdmaudiodev/Record-Buffer-Issue,3” this
> > is why i asked you my initial questions about setting frame size and
> > number of frames.
>
> Yes, but you need to read the whole message. This is about a driver
> that wants more control over its OWN buffering. A port class minidriver
> doesn’t get directly involved in the property exchange (the class driver
> handles it for you), so the author was suggesting intercepting the
> property ioctl directly.
>
>
> > 3. So i decided to start with coding MSVAD as an virtual audio driver
> > ( i known lot and lot of people has already done that and VAC is a
> > very good example for that) i wanted this has my starting point. I
> > wrote a buffer to interface between copyto and copyfrom and it worked
> > fine, Now what ever i play in the win32 player application i am able
> > to record in the win32 recorder application(I was glade my first
> > program worked!!!) but the problem in that is if the load of the OS
> > increases the Recorded file will have some loss of data i am not able
> > to figure this out any suggestions???
>
> The input and output applications are not synchronized. If you assume
> that you get one read request for each write request, then inevitably
> you will lose data. You need at least a little bit of buffering in there.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Tim,
The problem is with The Microphone data not the performance issue. Is
this the known problem? any work around?
Thanks
Dennis Scott.
On Tue, Jul 21, 2009 at 10:31 AM, Dennis Scott
wrote:
> Hi,
>
> > IF you want to expose your own custom properties through a
> >friendly COM interface wrapper, then you need a ksproxy plugin. But, if
> >you are willing to access your custom properties using the IKsControl
> >interface, then no plugin is needed. For standard properties, the
> >plugin concept does not apply.
>
> Thanks that answers my question, so if i want to expose my own custom
> property then only i have to write
> plugins.
> Now how can i know what are the default propertyes the driver exposes (can
> graphedit will help).Or i have to write DS
> program to query the driver using IKsObject and KsSynchronousDeviceControl?
>
>
> >The input and output applications are not synchronized. If you assume
> >that you get one read request for each write request, then inevitably
> >you will lose data. You need at least a little bit of buffering in there.
>
> Yes i am buffering the data which is played by the player, the buffer is a
> cyclic buffer of size (40 * PAGE_SIZE). Is this too heavy or the buffering
> is not correct??
>
> I got this problem in XPSP3, but this problem is not visible in VISTASP1.
>
> Thanks
> Dennis Scott.
>
>
> On Mon, Jul 20, 2009 at 11:03 PM, Tim Roberts wrote:
>
>> Dennis Scott wrote:
>> >
>> > Now my question is,
>> >
>> > 1. As the example of MAX “Extending KS Proxy with Custom Property
>> > Pages and Interface Plug-ins” is it needed for all avstream drivers to
>> > write proxy i want to get only the property and some methods (I dont
>> > want property pages)
>>
>> IF you want to expose your own custom properties through a
>> friendly COM interface wrapper, then you need a ksproxy plugin. But, if
>> you are willing to access your custom properties using the IKsControl
>> interface, then no plugin is needed. For standard properties, the
>> plugin concept does not apply.
>>
>>
>> > 2. I went through wdm list and i found an article
>> > “http://www.freelists.org/post/wdmaudiodev/Record-Buffer-Issue,3” this
>> > is why i asked you my initial questions about setting frame size and
>> > number of frames.
>>
>> Yes, but you need to read the whole message. This is about a driver
>> that wants more control over its OWN buffering. A port class minidriver
>> doesn’t get directly involved in the property exchange (the class driver
>> handles it for you), so the author was suggesting intercepting the
>> property ioctl directly.
>>
>>
>> > 3. So i decided to start with coding MSVAD as an virtual audio driver
>> > ( i known lot and lot of people has already done that and VAC is a
>> > very good example for that) i wanted this has my starting point. I
>> > wrote a buffer to interface between copyto and copyfrom and it worked
>> > fine, Now what ever i play in the win32 player application i am able
>> > to record in the win32 recorder application(I was glade my first
>> > program worked!!!) but the problem in that is if the load of the OS
>> > increases the Recorded file will have some loss of data i am not able
>> > to figure this out any suggestions???
>>
>> The input and output applications are not synchronized. If you assume
>> that you get one read request for each write request, then inevitably
>> you will lose data. You need at least a little bit of buffering in there.
>>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
Dennis Scott wrote:
>** IF ** you want to expose your own custom properties through a
>friendly COM interface wrapper, then you need a ksproxy plugin. But, if
>you are willing to access your custom properties using the IKsControl
>interface, then no plugin is needed. For standard properties, the
>plugin concept does not apply.Thanks that answers my question, so if i want to expose my own custom
property then only i have to write
plugins.
Not quite. The FIRST step in exposing a custom property is to have your
AVStream driver add the custom property set to its lists of properties
in the AutomationTable member in KSPIN_DESCRIPTOR_EX or
KSFILTER_DESCRIPTOR. Once that’s done, anyone can access the properties
through IKsControl.
When ksproxy adds your driver to a DirectShow graph, it goes through
every property that the driver has in its automation tables. For every
property it doesn’t recognize, it goes out to the registry to see if you
have declared a plugin to handle it. The plugin provides a pretty COM
server front-end for the property set, and optionally a property page
handler as well.
So, the driver decides which properties to add; the optional proxy
plugin just adds a pretty face to it.
Now how can i know what are the default propertyes the driver exposes
(can graphedit will help).Or i have to write DS
program to query the driver using IKsObject and
KsSynchronousDeviceControl?
As a DirectShow application, you don’t worry about this. You use the
DirectShow interfaces, and ksproxy translates them to property
requests. So, for a video camera, the IAMVideoProcAmp interface talks
to the PROPSETID_VIDCAP_VIDEOPROCAMP properties, the IAMVideoControl
interface talks to the PROPSETID_VIDCAP_VIDEOCONTROL properties,
IAMDroppedFrames talks to the PROPSETID_VIDCAP_DROPPEDFRAMES properties,
and so on.
Property sets like KSPROPSETID_General, KSPROPSETID_Pin,
KSPROPSETID_Topology, KSPROPSETID_Connection, and KSPROPSETID_Stream are
handled by the AVStream framework, based on the information in the data
structures you provided. As a DirectShow user, you would never talk to
any of those directly.
Yes i am buffering the data which is played by the player, the buffer
is a cyclic buffer of size (40 * PAGE_SIZE). Is this too heavy or the
buffering is not correct??
That should be enough – that’s 1/2 second at 44kHz stereo 16-bit. Are
you checking in your code to make sure you never get overflow or
underflow in your buffer?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Dennis Scott wrote:
Tim,
The problem is with The Microphone data not the performance
issue. Is this the known problem? any work around?
I don’t know what that means. Can you restate it?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.