[wdmaudiodev] Re: Record Buffer Issue

  • From: "David A. Hoatson" <dhoatson@xxxxxxx>
  • To: "Martin Puryear" <martinp@xxxxxxxxxxxxxxxxxxxxx>, <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Fri, 17 Sep 2004 08:11:08 -0700

Thanks Martin. I have it all working as expected under Windows XP. I guess I'll just have to write-off W2K for higher sample rate support.

Thank you,

David

----- Original Message ----- From: "Martin Puryear" <martinp@xxxxxxxxxxxxxxxxxxxxx>
To: "David A. Hoatson" <dhoatson@xxxxxxx>; <wdmaudiodev@xxxxxxxxxxxxx>
Sent: Thursday, September 16, 2004 6:25 PM
Subject: RE: [wdmaudiodev] Re: Record Buffer Issue


This behavior changed in Windows ME and XP, when we added the
splitter.sys component.
We unfortunately don't anticipate adding this component to Win2K SP - it
implies co-requisite changes in SysAudio.sys that are fairly invasive in
nature.

MartinP
Group Development Manager
Media Devices Group
Windows Digital Media Division
Microsoft Corporation

-----Original Message-----
From: David A. Hoatson [mailto:dhoatson@xxxxxxx]
Sent: Thursday, September 16, 2004 8:44 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Cc: Martin Puryear
Subject: Re: [wdmaudiodev] Re: Record Buffer Issue

Ok, I stand corrected.  I just checked again and
CWaveStreamMiniport::GetAllocatorFraming *is* being called by the port
driver under Windows XP SP2 and it does control the buffer size...
Looks like it doesn't get called under Windows 2000 SP4.

Can anyone fill me in on when this functionality changed?

Thank you,

David

----- Original Message -----
From: "David A. Hoatson" <dhoatson@xxxxxxx>
To: <wdmaudiodev@xxxxxxxxxxxxx>
Cc: <martinp@xxxxxxxxxxxxxxxxxxxxx>
Sent: Thursday, September 16, 2004 8:32 AM
Subject: [wdmaudiodev] Re: Record Buffer Issue


Hello and Thank you for your quick response...

I have a CWaveStreamMiniport::GetAllocatorFraming which only ever gets

called by SONAR when running in WDM/KS mode. It never gets called by
the 
Port class driver.

Are you saying that the Port class driver does an IOCTL_KS_PROPERTY /
KSPROPERTY_CONNECTION_ALLOCATORFRAMING and this never translates to
the 
Miniport::GetAllocatorFraming call?  Doesn't this seem like a serious
omission?

Martin Puryear (or anyone else from Microsoft), do you have any
comments 
on this?

Thank you,

David

----- Original Message ----- From: "Yura" <spirit@xxxxxxxxxx>
To: "David A. Hoatson" <wdmaudiodev@xxxxxxxxxxxxx>
Sent: Thursday, September 16, 2004 8:27 AM
Subject: [wdmaudiodev] Re: Record Buffer Issue


Hello ,David

You can hook IOCTL_KS_PROPERTY in the Dispatch routine and look for
the GET request for the KSPROPERTY_CONNECTION_ALLOCATORFRAMING
property of KSPROPSETID_Connection propery set. In this request you
can modify number of buffers and their sizes (after it has been
processed by lower drivers).

I know, this is bad way, but it helped me when I had problems with
sound recording in MsVad.

Thursday, September 16, 2004, 5:30:39 PM, you wrote:

DAH> I have noticed some specific behaviour for recording that is
causing major
DAH> grief for my audio driver
DAH> (IMiniportWavePci/IMiniportWavePciStream).

DAH> For playback, the buffers are chopped up into 10ms increments
and 
it seems
DAH> that a maximum of about 3 buffers are sent down to my driver
from 
the WDM
DAH> port class driver.  If the sample rate scales up, so does the
buffer size
DAH> so each buffer is still 10ms in length.  Playback at any sample
rate works
DAH> as expected.

DAH> For recording, eight 64-byte buffers are passed in regardless of 

sample
DAH> rate.  At 48kHz stereo, this means each buffer represents
~0.66ms, 
which is
DAH> just at the limit of what gives acceptable performance from
faster 
DAH> machines.  At 192kHz, the port driver still only gives eight
64-byte
DAH> buffers, so now that same buffer only represents 0.166ms for
stereo, or
DAH> only 1 sample period for 16 channel interleaved 32-bit (which my


device can
DAH> do)!  This means the PC is not able to respond to each interrupt


fast
DAH> enough and audio breakup will occur in only 1.3ms
(192kHz/Stereo). 
This
DAH> essentially means that recording through the port class driver
is 
not
DAH> possible at higher sample rates/higher channel counts.  I should


mention
DAH> that I am using Windows XP SP2.

DAH> So far I have found nothing that allows my driver to control the 

size or
DAH> number of buffers that are passed in from the upper level
driver. 
Does
DAH> anyone have a solution to this problem?  I'm sure there is
something very
DAH> basic that I am missing...

DAH> Thank you,

DAH> David

DAH> ******************

DAH> WDMAUDIODEV addresses:
DAH> Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
DAH> Subscribe:
DAH> mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
DAH> Unsubscribe:
DAH> mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
DAH> Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx

DAH> URL to WDMAUDIODEV page:
DAH> http://www.wdmaudiodev.de/



--
Best regards,
Yura                            mailto:spirit@xxxxxxxxxx

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

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/



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

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/

Other related posts:

  1. Home
  2. wdmaudiodev
  3. Archive
  4. 09-2004