waveInOpen callback_window -- usefullness ?

[R.Wieser]

Hello All,

I've just been tinkering around with retrieving microphone sound-data using
the "waveInOpen" command while specifying the CALLBACK_WINDOW argument, and
was wondering about its usefullness ...

I notice that none of the three WIM_??? messages supplies any user-defined
value (like a pointer to some special storage-area), such as the
CALLBACK_FUNCTION does seem to accept/supply.

What I mean to say is that if-and-when I decide to open *two* input-devices
I will have a problem with figuring out which of the buffers belong to the
handle did get, so I can free the buffers added to that input-device.

Did I miss something (like I can somehow attach to and retrieve from the
input-device some user-defined data (like with a Window and
"GWL_USERDATA") ) or do I really have to use a
compare-the-callback-supplied-handle-with-some-globally-stored-handles like
that ?

Regards,
Rudy Wieser

[Francois PIETTE]

Post by R.Wieser
I've just been tinkering around with retrieving microphone sound-data using
the "waveInOpen" command while specifying the CALLBACK_WINDOW argument, and
was wondering about its usefullness ...
I notice that none of the three WIM_??? messages supplies any user-defined
value (like a pointer to some special storage-area), such as the
CALLBACK_FUNCTION does seem to accept/supply.
What I mean to say is that if-and-when I decide to open *two*
input-devices
I will have a problem with figuring out which of the buffers belong to the
handle did get, so I can free the buffers added to that input-device.

Use a different window for each input-device. Of course you don't need to
have a visible windows.

[R.Wieser]

Hello Francois

Post by Francois PIETTE
Use a different window for each input-device.

Or a thread, yes. Maybe even (ab)use the function call-backs (which *does*
have a user-defined value) to send messages to the current windows thread
instead (didn't test it yet, but could be workable).

But I has hoping to hear I simply missed something while reading the
commands explanation, and a better/easier method was available.

Regards,
Rudy Wieser

Post by Francois PIETTE

Post by R.Wieser
I've just been tinkering around with retrieving microphone sound-data using
the "waveInOpen" command while specifying the CALLBACK_WINDOW argument, and
was wondering about its usefullness ...
I notice that none of the three WIM_??? messages supplies any user-defined
value (like a pointer to some special storage-area), such as the
CALLBACK_FUNCTION does seem to accept/supply.
What I mean to say is that if-and-when I decide to open *two* input-devices
I will have a problem with figuring out which of the buffers belong to the
handle did get, so I can free the buffers added to that input-device.

Use a different window for each input-device. Of course you don't need to
have a visible windows.
--
The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)
http://www.overbyte.be

[Bob Masta]

On Thu, 15 Apr 2010 11:33:29 +0200, "R.Wieser"

Post by R.Wieser
Hello Francois

Post by Francois PIETTE
Use a different window for each input-device.

Or a thread, yes. Maybe even (ab)use the function call-backs (which *does*
have a user-defined value) to send messages to the current windows thread
instead (didn't test it yet, but could be workable).
But I has hoping to hear I simply missed something while reading the
commands explanation, and a better/easier method was available.

I'll add a vote for the thread approach using
CALLBACK EVENT, at least for continuous operation.
I think the other methods may be suitable for
grabbing an occasional short snippet of sound, but
they are more likely to have problems for
continuous operation.

Best regards,


Bob Masta

DAQARTA v5.10
Data AcQuisition And Real-Time Analysis
www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
Frequency Counter, FREE Signal Generator
Pitch Track, Pitch-to-MIDI
DaqMusic - FREE MUSIC, Forever!
(Some assembly required)
Science (and fun!) with your sound card!

[Francois PIETTE]

Post by Bob Masta
I'll add a vote for the thread approach using
CALLBACK EVENT, at least for continuous operation.
I think the other methods may be suitable for
grabbing an occasional short snippet of sound, but
they are more likely to have problems for
continuous operation.

I use the windows message feature in a production application and there is
defenitely and absolutely no problem doing that for any length of operation.
If you experience problems with that approach, then you may have something
wrong in your own code, for example having a lengthy blocking message
handling. If your application screen looks frozen for some period of time,
then you have that kind of issue.

[Alessandro Angeli]

From: "R.Wieser"

Post by R.Wieser
Did I miss something (like I can somehow attach to and retrieve from
the input-device some user-defined data (like with a Window and
"GWL_USERDATA") ) or do I really have to use a
compare-the-callback-supplied-handle-with-some-globally-stored-handles
like that ?

Window/thread messages only have 2 params and waveIn uses them to
specify the device and buffer, which leaves no way to also pass along
some user-specified info.

[R.Wieser]

Hello Alessandro,

Post by Alessandro Angeli
Window/thread messages only have 2 params and waveIn uses
them to specify the device and buffer, which leaves no way to
also pass along some user-specified info.

Not quite true. While its so for the WIM_DATA event, both the WIM_OPEN and
WIM_CLOSE do not use the lParam argument (have set it to Zero).

For the WIM_DATA event I could use the "dwUser" field in the WAVEHDR
structure to pass my own data/data-pointer.

Regards,
Rudy Wieser

Post by Alessandro Angeli
From: "R.Wieser"

Post by R.Wieser
Did I miss something (like I can somehow attach to and retrieve from
the input-device some user-defined data (like with a Window and
"GWL_USERDATA") ) or do I really have to use a
compare-the-callback-supplied-handle-with-some-globally-stored-handles
like that ?

Window/thread messages only have 2 params and waveIn uses them to
specify the device and buffer, which leaves no way to also pass along
some user-specified info.
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm

[Alessandro Angeli]

From: "R.Wieser"

Post by R.Wieser
Not quite true. While its so for the WIM_DATA event, both the
WIM_OPEN and WIM_CLOSE do not use the lParam argument (have set it to
Zero).
For the WIM_DATA event I could use the "dwUser" field in the WAVEHDR
structure to pass my own data/data-pointer.

I'll assume that you meant MM_WIM_xxx and not WIM_xxx.

I see what you are saying, but my guess is that the original designers
of the API almost 20 years ago thought that, if don't have room for a
user-defined message param in the case of MM_WIM_DATA, then there was no
point in passing it only for MM_WIN_OPEN and MM_WIM_CLOSE, which are not
usually performance-critical events and are often ignored.

The API could have been designed differently, but it is what it is.

If you don't like using separate windows (like Francois suggested) or
separate threads or a callback (like you thought of yourself), you can
always just put your user info in the WAVEHDR and only match the dev id
for MM_WIM_OPEN and MM_WIM_CLOSE (how many devices are you ever going to
handle that a simple linear search in those 2 cases would be
impractical?).

But using a callback to post custom messages is not going to be
significantly slower than having waveIn post the message itself (it's
only an additional function call) so, if I were you, I'd just go down
this road.

After all, DirectSound is even worse than waveIn in this respect, since
it only supports event-based signals (probably because callbacks are
dangerous and window messages are not designed for real-time
applications like audio capture).

[R.Wieser]

Hello Alessandro,

Post by Alessandro Angeli
I'll assume that you meant MM_WIM_xxx and not WIM_xxx.

In my header-files one is equated as the other, so in essence they are the
same. But to be absolutily clear about it : I mean the window-messages 03BE
thru 03C0.

To be honest, all my googeling into the waveInOpen command and family did
not reveal any explanation to why *both* the MM_WIM_xxx and WIM_xxx exist.

Post by Alessandro Angeli
but my guess is that the original designers of the API
almost 20 years ago thought that, if don't have room
for a user-defined message param in the case of
MM_WIM_DATA,

But there is : the dwUser field in the WAVEHDR structure. Unless that one
has been added in later years ofcourse.

Post by Alessandro Angeli
then there was no point in passing it only for
MM_WIN_OPEN and MM_WIM_CLOSE, which are
not usually performance-critical events and are often ignored.

Pardon me saying so, but as far as I can see the (MM_)WIM_CLOSE *is*
critical. When you use the a CALLBACK_WINDOW you can issue a waveInClose
command, but both the (MM_)WIM_DATA and (MM_)WIM_CLOSE events will fire
after that command returns.

Buffers assigned to the recording-channel may (as far as I can tell) not be
erased until after the recording-channel has fully closed, which means after
the (MM_)WIM_CLOSE event has fired, not directly after the waveInClose
command.

So we have an event we (somehow) *have* to wait for and *could* be used to
do the final cleaning-up housekeeping in, but due to some choice of 20 years
back (and never has been updated) its virtually unusable ...


Or have I missed something in this regard ? Is there a standard way to do
that clean-up house-keeping after a recording-channel is ordered to close ?

Regards,
Rudy Wieser

Post by Alessandro Angeli
From: "R.Wieser"

Post by R.Wieser
Not quite true. While its so for the WIM_DATA event, both the
WIM_OPEN and WIM_CLOSE do not use the lParam argument (have set it to
Zero).
For the WIM_DATA event I could use the "dwUser" field in the WAVEHDR
structure to pass my own data/data-pointer.

I'll assume that you meant MM_WIM_xxx and not WIM_xxx.
I see what you are saying, but my guess is that the original designers
of the API almost 20 years ago thought that, if don't have room for a
user-defined message param in the case of MM_WIM_DATA, then there was no
point in passing it only for MM_WIN_OPEN and MM_WIM_CLOSE, which are not
usually performance-critical events and are often ignored.
The API could have been designed differently, but it is what it is.
If you don't like using separate windows (like Francois suggested) or
separate threads or a callback (like you thought of yourself), you can
always just put your user info in the WAVEHDR and only match the dev id
for MM_WIM_OPEN and MM_WIM_CLOSE (how many devices are you ever going to
handle that a simple linear search in those 2 cases would be
impractical?).
But using a callback to post custom messages is not going to be
significantly slower than having waveIn post the message itself (it's
only an additional function call) so, if I were you, I'd just go down
this road.
After all, DirectSound is even worse than waveIn in this respect, since
it only supports event-based signals (probably because callbacks are
dangerous and window messages are not designed for real-time
applications like audio capture).
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm

[Alessandro Angeli]

From: "R.Wieser"

Post by R.Wieser
To be honest, all my googeling into the waveInOpen command and family
did not reveal any explanation to why *both* the MM_WIM_xxx and
WIM_xxx exist.

They are not the same thing: the MM_WIM set are standard window messages
while the WIM set are custom messages passed to the callback. Of course
they are all just UINTs and so they gave them the same values, but they
are different namespaces.

Post by R.Wieser

Post by Alessandro Angeli
but my guess is that the original designers of the API
almost 20 years ago thought that, if don't have room
for a user-defined message param in the case of
MM_WIM_DATA,

But there is : the dwUser field in the WAVEHDR structure. Unless
that one has been added in later years ofcourse.

IIRC from the Win16 SDK, it's always been there. It's just not a window
message param. It can serve the same purpose of course, but whoever
designed this API seem to have valued consistency over practicality.

[...]

Post by R.Wieser
Or have I missed something in this regard ? Is there a standard way
to do that clean-up house-keeping after a recording-channel is
ordered to close ?

I haven't used waveIn in a long time, but I am quite sure you are
mistaken about the way waveInClose() works. According to the docs and
the source code, waveInClose() will fail if there are queued buffers so,
if waveInClose() succeeds, you will not receive data notifications
anymore and you can safely clean up.

Before calling waveInClose() you are supposed to call waveInReset() to
remove all buffers from the queue, then waveInUnprepareHeader() and only
after that you can safely call waveInClose(), which should succeed at
this point, meaning you can clean up your stuff.

Notice that the waveIn API is just a lightweight wrapper for the waveIn
device driver. It is possible that a buggy driver can keep sending data
notifications after a successful waveInClose() but, if that is the case,
then the close notification is in no way more reliable (it is still sent
by the driver).

[R.Wieser]

Hello Alessandro,

Post by Alessandro Angeli
I haven't used waveIn in a long time, but I am quite sure
you are mistaken about the way waveInClose() works.
According to the docs and the source code, waveInClose()
will fail if there are queued buffers so, if waveInClose()
succeeds, you will not receive data notifications
anymore and you can safely clean up.

Neither happens. At least,not if I may trust my debugging-output.

I must say I used waveInStop() and waveInClose() in that order. When
executing these commands I can see a debugging-message I printed after the
above sequence, and after that I see the last MM_WIM_DATA and MM_WIM_CLOSE
come by.

In other words : the single buffer I'm using is still being filled and
returned to the user *after* the waveInClose command returns successfully.

Post by Alessandro Angeli
Before calling waveInClose() you are supposed to call
waveInReset()

Only if you want to loose the data recorded from the last MM_WIM_DATA up
until the moment that command is issued (very noticable when recording an
16KByte block at 8 bit per sample and 11025 samples a sec :-) ). Calling
waveInStop() instead does not have that drawback.

Post by Alessandro Angeli
It is possible that a buggy driver can keep sending data
notifications after a successful waveInClose()

Hmmmm .... I've run the exact same code on two different versions of Windows
(98se and XP) with quite different hardware & drivers, and in both (four, if
I allso count the waveInReset method) cases I got the above-described result
(data and close window-messages after the waveInClose() command terminates
successfully.

But you made me aware of something : I do not use the
waveInUnprepareHeader() command, as I simply close the recording-device and
discard the used data-stuctures and buffers. I should look into that a bit
more.

Regards,
Rudy Wieser


-- Origional message

Post by Alessandro Angeli
From: "R.Wieser"

Post by R.Wieser
To be honest, all my googeling into the waveInOpen command and family
did not reveal any explanation to why *both* the MM_WIM_xxx and
WIM_xxx exist.

They are not the same thing: the MM_WIM set are standard window messages
while the WIM set are custom messages passed to the callback. Of course
they are all just UINTs and so they gave them the same values, but they
are different namespaces.

Post by R.Wieser

Post by Alessandro Angeli
but my guess is that the original designers of the API
almost 20 years ago thought that, if don't have room
for a user-defined message param in the case of
MM_WIM_DATA,

But there is : the dwUser field in the WAVEHDR structure. Unless
that one has been added in later years ofcourse.

IIRC from the Win16 SDK, it's always been there. It's just not a window
message param. It can serve the same purpose of course, but whoever
designed this API seem to have valued consistency over practicality.
[...]

Post by R.Wieser
Or have I missed something in this regard ? Is there a standard way
to do that clean-up house-keeping after a recording-channel is
ordered to close ?

I haven't used waveIn in a long time, but I am quite sure you are
mistaken about the way waveInClose() works. According to the docs and
the source code, waveInClose() will fail if there are queued buffers so,
if waveInClose() succeeds, you will not receive data notifications
anymore and you can safely clean up.
Before calling waveInClose() you are supposed to call waveInReset() to
remove all buffers from the queue, then waveInUnprepareHeader() and only
after that you can safely call waveInClose(), which should succeed at
this point, meaning you can clean up your stuff.
Notice that the waveIn API is just a lightweight wrapper for the waveIn
device driver. It is possible that a buggy driver can keep sending data
notifications after a successful waveInClose() but, if that is the case,
then the close notification is in no way more reliable (it is still sent
by the driver).
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm

[Bob Masta]

On Sat, 17 Apr 2010 17:10:07 +0200, "R.Wieser"

Post by R.Wieser
Hello Alessandro,

Post by Alessandro Angeli
I haven't used waveIn in a long time, but I am quite sure
you are mistaken about the way waveInClose() works.
According to the docs and the source code, waveInClose()
will fail if there are queued buffers so, if waveInClose()
succeeds, you will not receive data notifications
anymore and you can safely clean up.

Neither happens. At least,not if I may trust my debugging-output.
I must say I used waveInStop() and waveInClose() in that order. When
executing these commands I can see a debugging-message I printed after the
above sequence, and after that I see the last MM_WIM_DATA and MM_WIM_CLOSE
come by.
In other words : the single buffer I'm using is still being filled and
returned to the user *after* the waveInClose command returns successfully.

Post by Alessandro Angeli
Before calling waveInClose() you are supposed to call
waveInReset()

Only if you want to loose the data recorded from the last MM_WIM_DATA up
until the moment that command is issued (very noticable when recording an
16KByte block at 8 bit per sample and 11025 samples a sec :-) ). Calling
waveInStop() instead does not have that drawback.

Post by Alessandro Angeli
It is possible that a buggy driver can keep sending data
notifications after a successful waveInClose()

Hmmmm .... I've run the exact same code on two different versions of Windows
(98se and XP) with quite different hardware & drivers, and in both (four, if
I allso count the waveInReset method) cases I got the above-described result
(data and close window-messages after the waveInClose() command terminates
successfully.
But you made me aware of something : I do not use the
waveInUnprepareHeader() command, as I simply close the recording-device and
discard the used data-stuctures and buffers. I should look into that a bit
more.

Since you are testing on Win98SE, note that in
older versions of Windows (possibly including
98SE) there was a serious problem with waveInReset
wherein the buffers were not all returned
(WHDR_DONE not set).

It was discussed in this group (a long time ago,
now) and I don't know if there was ever any solid
evidence that it was really the Windows version
that was at fault... it might have simply been the
case that older systems had older drivers that
were screwing up, and eventually all the driver
writers got up to speed... and by then Windows was
into XP versions.

In my own tests at the time, I found one Win95 133
MHz laptop that occasionally took nearly 500 reset
attempts before returning. (I never found a "fix"
for this... I ended up adding a test to my code
that tried for 2 seconds before giving up and
alerting the user.)

Best regards,


Bob Masta

DAQARTA v5.10
Data AcQuisition And Real-Time Analysis
www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
Frequency Counter, FREE Signal Generator
Pitch Track, Pitch-to-MIDI
DaqMusic - FREE MUSIC, Forever!
(Some assembly required)
Science (and fun!) with your sound card!

[Alessandro Angeli]

From: "R.Wieser"

Post by R.Wieser
Only if you want to loose the data recorded from the last MM_WIM_DATA
up until the moment that command is issued (very noticable when
recording an 16KByte block at 8 bit per sample and 11025 samples a
sec :-) ). Calling waveInStop() instead does not have that drawback.

One call does not exclude the other, I was just writing about the
closing/clean-up phase. To set up the recording I assume you do this:

waveInOpen()
waveInPrepareBuffer()
waveInAddBuffer()
waveInStart()

So, to clean up, you are supposed to do the reverse:

waveInStop()
waveInReset()
waveInUnprepareHeader()
waveInClose()

You can skip any of the calls, but you do it at your own risk.

Post by R.Wieser
Hmmmm .... I've run the exact same code on two different versions of
Windows (98se and XP) with quite different hardware & drivers, and in
both (four, if I allso count the waveInReset method) cases I got the
above-described result (data and close window-messages after the
waveInClose() command terminates successfully.

Try adding the result of GetCurrentThreadId() and
QueryPerformanceCounter() to your trace messages to see whether the
message order is what it seems or an artifact of multi-threading. If you
are using windows/thread messages, you should also print out MSG::time.

Notice that, with window/thread messages, a message may be posted to
your queue before you invoke waveInClose() but, do to unpredictability
of the thread scheduling, you may end up retrieving it only after you
already invoked waveInReset() and waveInClose(). Do you dispatch the
messages on the same thread that invokes reset/close? Do you dispatch
all pending messages before invoking reset/close?

[R.Wieser]

Hello Alessandro,
....

Post by Alessandro Angeli
You can skip any of the calls, but you do it at your own risk.

Well, with all the pages I've visited and all the examples I've found only
you is showing me this particular sequence of commands ... I'll have to
try and see what happens.

But a question : Why would I need waveInUnprepareHeader() when waveInReset()
allready released the buffer to the user (me) ?

Post by Alessandro Angeli
If you are using windows/thread messages, you should
also print out MSG::time.

I could, but all messages are coming from a single window, and are thus in
order of their execution.

Post by Alessandro Angeli
you may end up retrieving it only after you already invoked
waveInReset() and waveInClose().

Well, the MM_WIM_CLOSE event is triggered by the waveInClose(). It
therefore stands to reason that the event allways follows the command.

Post by Alessandro Angeli
Do you dispatch the messages on the same thread that invokes
reset/close?

Yes. My current (testing) app has got only a single window, and the
MM_WIM_??? message are directed to it.

Post by Alessandro Angeli
Do you dispatch all pending messages before invoking
reset/close?

[Blink] How would I be able to know ? Its not like I'm able to ask MCI if
it still has got anything it wants to tell me.

Actually, that is what I expect the MM_WIM_CLOSE event to be for : to tell
me that the MCI subsystem does not have anything for me anymore, and I can
safely close down the program

= = = = = =
I just changed a waveInStop(), waveInClose() sequence into a waveInStop(),
waveInReset(), waveInClose() sequence, and saw no change in MM_WIM_???
events or timing thereof.

Rudy Wieser

Post by Alessandro Angeli
From: "R.Wieser"

Post by R.Wieser
Only if you want to loose the data recorded from the last MM_WIM_DATA
up until the moment that command is issued (very noticable when
recording an 16KByte block at 8 bit per sample and 11025 samples a
sec :-) ). Calling waveInStop() instead does not have that drawback.

One call does not exclude the other, I was just writing about the
waveInOpen()
waveInPrepareBuffer()
waveInAddBuffer()
waveInStart()
waveInStop()
waveInReset()
waveInUnprepareHeader()
waveInClose()
You can skip any of the calls, but you do it at your own risk.

Post by R.Wieser
Hmmmm .... I've run the exact same code on two different versions of
Windows (98se and XP) with quite different hardware & drivers, and in
both (four, if I allso count the waveInReset method) cases I got the
above-described result (data and close window-messages after the
waveInClose() command terminates successfully.

Try adding the result of GetCurrentThreadId() and
QueryPerformanceCounter() to your trace messages to see whether the
message order is what it seems or an artifact of multi-threading. If you
are using windows/thread messages, you should also print out MSG::time.
Notice that, with window/thread messages, a message may be posted to
your queue before you invoke waveInClose() but, do to unpredictability
of the thread scheduling, you may end up retrieving it only after you
already invoked waveInReset() and waveInClose(). Do you dispatch the
messages on the same thread that invokes reset/close? Do you dispatch
all pending messages before invoking reset/close?
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm

[Alessandro Angeli]

From: "R.Wieser"

Post by R.Wieser
Well, with all the pages I've visited and all the examples I've found
only you is showing me this particular sequence of commands ...

How were you making it work without all 4 setup calls? The cleanup
sequence is just the result of the setup sequence.

Post by R.Wieser
But a question : Why would I need waveInUnprepareHeader() when
waveInReset() allready released the buffer to the user (me) ?

waveInReset() removes a buffer from the queue but does not deallocate
the resources allocated by waveInPrepareHeader().

Post by R.Wieser
I could, but all messages are coming from a single window, and are
thus in order of their execution.

Messages do not come from windows, they are retrieved through windows.
MSG::time gives you the time when the messages was posted to the window,
which is more important than the time when you retrieved it.

Post by R.Wieser
Well, the MM_WIM_CLOSE event is triggered by the waveInClose(). It
therefore stands to reason that the event allways follows the command.

I was referring to MM_WIM_DATA. If the message was posted but not
retrieved before you invoke
waveInReset()/waveInUnprepareHeader()/waveInClose(), you will end up
retrieving it afterwards, when it is meaningless.

Post by R.Wieser

Post by Alessandro Angeli
Do you dispatch the messages on the same thread that invokes
reset/close?

Yes. My current (testing) app has got only a single window, and the
MM_WIM_??? message are directed to it.

Having 1 window does not imply 1 thread. The problem I am hinting here
is multi-threading and your confusion about windows and threads (see
above and below) makes you code suspicious (incorrectly handling
multi-threading leads to surprising apparent execution sequences).

Are the waveIn functions invoked by the same thread that dispatches the
messages for the windows that receives the MM_WIN messages?

Post by R.Wieser

Post by Alessandro Angeli
Do you dispatch all pending messages before invoking
reset/close?

[Blink] How would I be able to know ? Its not like I'm able to ask
MCI if it still has got anything it wants to tell me.

MCI? Do you meane waveIn or WinMM? MCI is a completely different
framework.

Anyway, if you retrieve all pending messages and all buffers are
returned to you (either through MM_WIM_DATA messages or after a
waveInReset()) and you don't queue others, then you're done.

[R.Wieser]

Hello Alessandro,

Thanks for your responses, but I'm stopping with this.

Nonwithstanding our exchange I've become barely anything wiser, and I'm
getting a bit tired having to explain pretty-much every other word I say.

Regards,
Rudy Wieser

[Alessandro Angeli]

From: "R.Wieser"

Post by R.Wieser
Nonwithstanding our exchange I've become barely anything wiser, and
I'm getting a bit tired having to explain pretty-much every other
word I say.

The reason is that you are observing a behavior that nobody else here
has observed before (I even wrote code to try and reproduce it). Since
you are the only one who knows your code and we can not read minds, let
alone across a computer network, the questions are the only way to try
and figure out what your code exactly does to behave the way it seems to
behave.

[R.Wieser]

Hello Alessandro,

Post by Alessandro Angeli
The reason is that you are observing a behavior that
nobody else here has observed before

Yes, I hear that regulary. Maybe thats because I'm someone who finds the
road to the end-result (understanding what happens) more interesting than
the end-result itself.

Post by Alessandro Angeli
(I even wrote code to try and reproduce it).

How can that be ? I can reproduce the result on two different machines,
even with different combinations of the stop, reset and close commands
(stop-close, reset-close, stop-reset-close).

Post by Alessandro Angeli
Since you are the only one who knows your code

This is what I did :

-- start sampling (by button-press)
waveInOpen (using CALLBACK_WINDOW)
waveInPrepareHeader (just a single buffer, 16KByte, 8 bits,11025 bits per
sample, mono)
waveInAddBuffer
(create output-file)
waveInStart

-- end sampling (by button-press)
waveInStop
waveInClose

And for completeness sake, the events too

-- event MM_WIM_DATA
(write block to output-file)
waveInAddBuffer

-- event MM_WIM_CLOSE
(finalize/close output-file)

Nothing outof the ordinary I would say.

By prepending a RIFF header to the above-generated file (something I
actually do when creating the file and update on close) the result is played
by double-clicking the file (executing the default media-player).

Regards,
Rudy Wieser

Post by Alessandro Angeli
From: "R.Wieser"

Post by R.Wieser
Nonwithstanding our exchange I've become barely anything wiser, and
I'm getting a bit tired having to explain pretty-much every other
word I say.

The reason is that you are observing a behavior that nobody else here
has observed before (I even wrote code to try and reproduce it). Since
you are the only one who knows your code and we can not read minds, let
alone across a computer network, the questions are the only way to try
and figure out what your code exactly does to behave the way it seems to
behave.
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm

[R.Wieser]

Hello Alessandro,

Post by Alessandro Angeli
The reason is that you are observing a behavior that
nobody else here has observed before

Yes, I hear that regulary. Maybe thats because I'm someone who finds the
road to the end-result (understanding what happens) more interesting than
the end-result itself.

Post by Alessandro Angeli
(I even wrote code to try and reproduce it).

How can that be ? I can reproduce the result on two different machines,
even with different combinations of the stop, reset and close commands
(stop-close, reset-close, stop-reset-close).

Post by Alessandro Angeli
Since you are the only one who knows your code

This is what I did :

-- start sampling (by button-press)
waveInOpen (using CALLBACK_WINDOW)
waveInPrepareHeader (just a single buffer, 16KByte, 8 bits,11025 bits per
sample, mono)
waveInAddBuffer
(create output-file)
waveInStart

-- end sampling (by button-press)
waveInStop
waveInClose

And for completeness sake, the events too

-- event MM_WIM_DATA
(write block to output-file)
waveInAddBuffer

-- event MM_WIM_CLOSE
(finalize/close output-file)

Nothing outof the ordinary I would say.

By prepending a RIFF header to the above-generated file (something I
actually do when creating the file and update on close) the result is played
by double-clicking the file (executing the default media-player).

Regards,
Rudy Wieser

Post by Alessandro Angeli
From: "R.Wieser"

Post by R.Wieser
Nonwithstanding our exchange I've become barely anything wiser, and
I'm getting a bit tired having to explain pretty-much every other
word I say.

The reason is that you are observing a behavior that nobody else here
has observed before (I even wrote code to try and reproduce it). Since
you are the only one who knows your code and we can not read minds, let
alone across a computer network, the questions are the only way to try
and figure out what your code exactly does to behave the way it seems to
behave.
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm