Re: WaveIn/WaveOut and sound distortion

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Phil Taylor (ptaylor_at_private-citizen.com)
Date: 04/12/04 

Date: Mon, 12 Apr 2004 09:37:10 -0700

skipping a call is different than issueing it over and over.

I am not saying skipping unprepare.

I am informing you that the usage pattern is:

   at init time, for all buffers needed
        allocate, prepare

    for all playback duration
        use buffers

    at termination time, for all buffers allocated
        unprepare
        deallocate.

think. these APIs are based in a Win16 timeframe.

then all memory moved, even global memory. global lock'ed memory could move
between locks.

preparing the header did a global page lock, needed so the Win16 drivers
didnt have moving memory for DMAs, and fixed the block in memory.
unpreparing did a global page unlock. there is no value in locking a 2nd
time. in point of fact, after an application executes for a duration and
given reasonable expectations of memory fragmentation, continuing to try to
page lock will cause a search for a contiguous region.

it says "must be called after the device driver fills a buffer and returns
it to the application". but isnt it the app that is filling the buffer and
handing it to the API?

this comment is to make sure you prepare once.

whats more, the doc also says "Preparing a header that has already been
prepared has no effect, and the function returns zero"

so which one do you give more weight to?

"Kurt Grittner" <grittkmg_NO_SPAM_@mailbag.com> wrote in message
news:vi9l70d77cgj5i7a19f1j1tvjdljm816o8@4ax.com...
> Why is it so hard to believe that? Here's what the MS site still
> says:
> --------------------------------------------
> waveInUnprepareHeader
>
> The waveInUnprepareHeader function cleans up the preparation performed
> by the waveInPrepareHeader function. This function must be called
> after the device driver fills a buffer and returns it to the
> application. You must call this function before freeing the buffer.
> ---------------------------------------------
>
> If I'm a DDK person reading this why wouldn't I assume these are
> always issued in pairs? The docs don't say what the preperation is,
> NOR whether it is preperation by windows proper and/or by the device
> driver. A device driver author might do something like duping a
> handle counting on the paired unprepare call to free the duplicated
> handle. In fact I have seen win98 drivers for no-name audio cards
> leak handles when you skip the paired unprepare.
>
> Until I see clarification from the docs that say the unprepare is
> optional and is intended for use with multiple AddBuffers I will
> continue to use them in pairs. I don't consider sample programs from
> Microsoft to be sufficient proof one way or the other.
>
> I don't consider it superstition since I have seen actual failures.
> So instead of eternally arguing about this, how would we go about
> getting the documentation clarified?
>
> Kurt
>
>
> On Wed, 7 Apr 2004 18:27:50 -0700, "Phil Taylor"
> <ptaylor@private-citizen.com> wrote:
>
> >hard to believe any drivers got this wrong.
> >
> >this was the API behavior pattern from the docs with the original MME
> >extensions SDK on top of Win3.0, carried forth when the MMEs got
integrated
> >into Win3.1 and the Win3.1 SDK, migrated to Win32 for Win95, etc.
> >
> >I repeat, I debugged Tomb Raider II with exactly this problem in 1998 as
a
> >DirectX evangelist. the app was stuttering in certain situations on QA
> >tests. I got on the phone with the Eidos programmer, he adjusted the code
as
> >I am saying, it passed the QA tests, and the product went out the door.
> >
> >this is superstition re unprepare/prepare each time after use.
> >
> >all this does is eat perf. and it does cost. it can cost enough to cost a
> >real-time app its real-time response and cause audible glitches.
> >
> >Note, I just doublechecked an old Platform SDK, and before the "old MM"
> >samples were culled, the PSDK had samples that showed this usage.
> >
> >"Bob Masta" <NoSpam@daqarta.com> wrote in message
> >news:407405da.3184478@news.itd.umich.edu...
> >> On Tue, 6 Apr 2004 08:25:40 -0700, "Phil Taylor"
> >> <ptaylor@private-citizen.com> wrote:
> >>
> >> <snip>
> >> >
> >> >no, you dont have to unprepare each time to reuse. thats misreading
the
> >> >docs.
> >> >
> >> >essentially, waveOutPrepareHeader locks the page in addr space so the
mem
> >> >manager cant move it around. thats all its doing, eg a physical page
> >lock.
> >> >and the doc says nothing about this being a one-shot.
> >> >
> >>
> >> The docs are pretty vague on this. My interpretation was exactly the
> >> same as yours, and my code ran just fine. But someone on this NG
> >> reported that certain drivers on certain older Windows versions needed
> >> the un- and re-prepare on each block or there would be problems.
> >> Seemed safer to "just do it" to head off potential (hard to find)
> >> problems on some user's system in the future. It annoys me to
> >> have to do "superstitious" (and 99 44/100% superfluous) stuff
> >> like this, but I don't think it costs much in terms of execution
> >> speed. (Has anyone timed this?)
> >>
> >>
> >> Bob Masta
> >> dqatechATdaqartaDOTcom
> >>
> >> D A Q A R T A
> >> Data AcQuisition And Real-Time Analysis
> >> www.daqarta.com
> >
>

Relevant Pages

  • Re: PCI bus-master and large contiguous memory buffers
    ... As soon as device reaches the end of the buffer ... Sure, I am developing both PCI adapter and device driver, so, it is ... not afford reinitializing DMA on my device after every transfer. ... x86 CPU memory management structures I never tried to dig into Windows ...
    (microsoft.public.development.device.drivers)
  • Re: PCI bus-master and large contiguous memory buffers
    ... x86 CPU memory management structures I never tried to dig into Windows ... What about buffer consistency in the long run? ... The scattergather list methods provide a vastly simplified mechanism ... CD-ROM driver may keep the system for seconds at elevated IRQL levels, ...
    (microsoft.public.development.device.drivers)
  • Re: PCI bus-master and large contiguous memory buffers
    ... I built my scatter gather list in SRAM that was on my device, ... could have done it in system memory had I needed to. ... interrupt when a buffer was filled, the application would save the buffer to ... beginning of the recording I made a device IO control call to my driver. ...
    (microsoft.public.development.device.drivers)
  • Re: PCI bus-master and large contiguous memory buffers
    ... x86 CPU memory management structures I never tried to dig into Windows ... What about buffer consistency in the long run? ... CD-ROM driver may keep the system for seconds at elevated IRQL levels, ... addresses of physical pages of memory, from which the user buffer ...
    (microsoft.public.development.device.drivers)
  • PCI bus-master and large contiguous memory buffers
    ... large 32MB contiguous memory buffer, which is a big problem in modern ... After getting these data from device driver needs to perform some ... buffer while OS not yet managed to invoke my DPC for ISR. ... addresses of physical pages of memory, from which the user buffer ...
    (microsoft.public.development.device.drivers)