[wdmaudiodev] Re: Record Buffer Issue
- From: "Martin Puryear" <martinp@xxxxxxxxxxxxxxxxxxxxx>
- To: "David A. Hoatson" <dhoatson@xxxxxxx>, <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Thu, 16 Sep 2004 18:25:03 -0700
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:
