How to record voice correctly?

[hank]

I'm developing recording program on WM. My steps when stop recording is:
waveInReset, waveInUnprepareHeader, then waveInClose. Because I want a
WIM_DATA message send immediately, so I use waveInReset not waveInStop.

But here is a wired problem: on some smartphone device, e.g. Motorola Q9H,
the value of dwBytesRecorded in WIM_DATA in callback AudioProc is always 0.
If I call waveInStop->waveInReset->waveInUnprepareHeader->waveInClose when
stop recording, the value of dwBytesRecorded is correct.

And I don't see this situation on other devices, like Touch Pro. My
questions are:
Does anyone know what's the problem?
How can I get the correct dwBytesRecorded? waveInGetPosition seems inaccurate.
Is that legal or correct to write like
"waveInStop->waveInReset->waveInUnprepareHeader->waveInClose" when stop
recording?
Is anyone able to provide an accurate and correct process of recording using
waveInRest?

Too many questions, it is really bothering me for a long time. Thanks very
much for help!

[Dave]

This post might be inappropriate. Click to display it.

[hank]

thanks for your reply. So it is legal and safe to write like
"waveInStop->waveInReset->waveInUnprepareHeader->waveInClose"?

Post by Dave
this may be related to some problems i had with a recording app some years
ago. at that time i was using the windows sound recorder ocx and found that
some card drivers would not return a partially full buffer at the end of
recording. for most uses this would be no problem since the buffer for the
sound recorder was defaulting to .5sec, but for what i was doing i needed to
have finer control than that, it was very annoying for the short recordings
that we were doing to lose up to .5 sec on the end. so it may not be
something you control, if the driver won't return a partially full buffer
after the stop or reset then you are probably out of luck. in my case the
fix was to make my own ocx with a shorter buffer, we went with .1sec since
that seemed to not be noticeable in the application we were working on.

Post by hank
waveInReset, waveInUnprepareHeader, then waveInClose. Because I want a
WIM_DATA message send immediately, so I use waveInReset not waveInStop.
But here is a wired problem: on some smartphone device, e.g. Motorola Q9H,
the value of dwBytesRecorded in WIM_DATA in callback AudioProc is always 0.
If I call waveInStop->waveInReset->waveInUnprepareHeader->waveInClose when
stop recording, the value of dwBytesRecorded is correct.
And I don't see this situation on other devices, like Touch Pro. My
Does anyone know what's the problem?
How can I get the correct dwBytesRecorded? waveInGetPosition seems inaccurate.
Is that legal or correct to write like
"waveInStop->waveInReset->waveInUnprepareHeader->waveInClose" when stop
recording?
Is anyone able to provide an accurate and correct process of recording using
waveInRest?
Too many questions, it is really bothering me for a long time. Thanks very
much for help!

[hank]

I didn't meet your problem. But I think you may call waveInReset in callback
function, I call it outside. There are many articles for deadlock for
waveInReset, you can google them.

Hank,
after waveInReset function it's some like infinity loop. Please post message
if you solved this problem.
Thank you!

Post by hank
thanks for your reply. So it is legal and safe to write like
"waveInStop->waveInReset->waveInUnprepareHeader->waveInClose"?

Post by Dave
this may be related to some problems i had with a recording app some years
ago. at that time i was using the windows sound recorder ocx and found that
some card drivers would not return a partially full buffer at the end of
recording. for most uses this would be no problem since the buffer for the
sound recorder was defaulting to .5sec, but for what i was doing i needed to
have finer control than that, it was very annoying for the short recordings
that we were doing to lose up to .5 sec on the end. so it may not be
something you control, if the driver won't return a partially full buffer
after the stop or reset then you are probably out of luck. in my case the
fix was to make my own ocx with a shorter buffer, we went with .1sec since
that seemed to not be noticeable in the application we were working on.

Post by hank
waveInReset, waveInUnprepareHeader, then waveInClose. Because I want a
WIM_DATA message send immediately, so I use waveInReset not waveInStop.
But here is a wired problem: on some smartphone device, e.g. Motorola Q9H,
the value of dwBytesRecorded in WIM_DATA in callback AudioProc is always 0.
If I call waveInStop->waveInReset->waveInUnprepareHeader->waveInClose when
stop recording, the value of dwBytesRecorded is correct.
And I don't see this situation on other devices, like Touch Pro. My
Does anyone know what's the problem?
How can I get the correct dwBytesRecorded? waveInGetPosition seems inaccurate.
Is that legal or correct to write like
"waveInStop->waveInReset->waveInUnprepareHeader->waveInClose" when stop
recording?
Is anyone able to provide an accurate and correct process of recording using
waveInRest?
Too many questions, it is really bothering me for a long time. Thanks very
much for help!

[Sergey Melnikov]

Hank,
FYI I have problems to stop audio recording at same sequence as you wrote:
after waveInReset function it's some like infinity loop. Please post message
if you solved this problem.

Thank you!

Post by hank
thanks for your reply. So it is legal and safe to write like
"waveInStop->waveInReset->waveInUnprepareHeader->waveInClose"?

Post by Dave
this may be related to some problems i had with a recording app some years
ago. at that time i was using the windows sound recorder ocx and found that
some card drivers would not return a partially full buffer at the end of
recording. for most uses this would be no problem since the buffer for the
sound recorder was defaulting to .5sec, but for what i was doing i needed to
have finer control than that, it was very annoying for the short recordings
that we were doing to lose up to .5 sec on the end. so it may not be
something you control, if the driver won't return a partially full buffer
after the stop or reset then you are probably out of luck. in my case the
fix was to make my own ocx with a shorter buffer, we went with .1sec since
that seemed to not be noticeable in the application we were working on.

Post by hank
waveInReset, waveInUnprepareHeader, then waveInClose. Because I want a
WIM_DATA message send immediately, so I use waveInReset not waveInStop.
But here is a wired problem: on some smartphone device, e.g. Motorola Q9H,
the value of dwBytesRecorded in WIM_DATA in callback AudioProc is always 0.
If I call waveInStop->waveInReset->waveInUnprepareHeader->waveInClose when
stop recording, the value of dwBytesRecorded is correct.
And I don't see this situation on other devices, like Touch Pro. My
Does anyone know what's the problem?
How can I get the correct dwBytesRecorded? waveInGetPosition seems inaccurate.
Is that legal or correct to write like
"waveInStop->waveInReset->waveInUnprepareHeader->waveInClose" when stop
recording?
Is anyone able to provide an accurate and correct process of recording using
waveInRest?
Too many questions, it is really bothering me for a long time. Thanks very
much for help!