 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
H Strickner
Guest
|
 Posted: Fri Nov 14, 2003 1:48 pm Post subject: Synchronize buffer with WOM_DONE - how? |
 |
|
I'm using wavein and waveout with two threads in a VCL to handle wav
processing. Everything is fine under normal system load (XP OS, 2.4
GHz P4), however when some momentary peak load is encountered by the
OS I am loosing sync of the waveout with my application buffer, the
audio starts to click.
I have established that my application buffer (middle buffer between
wavein and waveout) is not ready with new data at that stage and the
previous buffer is re-read again. I am doing a fairly big amount of
audio processing on the data, FFT IFFT AGC etc.
What I need to know is how the playback side can be synchronised to my
app buffer, or in case that data is not ready when WOM_DONE is sent
how to re-read my buffer a little bit later when it has new valid
data. I am using three buffers each for recording and playback queues,
so some delay should be allowable but yet I am loosing sync, that
seems to be the problem. Would it help to have another thread to keep
things balanced and how?
Thanks for your assistance,
Helmut
|
|
| Back to top |
|
 |
AlanGLLoyd
Guest
|
| Posted: Fri Nov 14, 2003 2:44 pm Post subject: Re: Synchronize buffer with WOM_DONE - how? |
|
|
In article <cea5de3c.0311140548.10c3362 (AT) posting (DOT) google.com>, [email]hstr (AT) gil (DOT) com.au[/email] (H
Strickner) writes:
| Quote: | I'm using wavein and waveout with two threads in a VCL to handle wav
processing. Everything is fine under normal system load (XP OS, 2.4
GHz P4), however when some momentary peak load is encountered by the
OS I am loosing sync of the waveout with my application buffer, the
audio starts to click.
I have established that my application buffer (middle buffer between
wavein and waveout) is not ready with new data at that stage and the
previous buffer is re-read again. I am doing a fairly big amount of
audio processing on the data, FFT IFFT AGC etc.
What I need to know is how the playback side can be synchronised to my
app buffer, or in case that data is not ready when WOM_DONE is sent
how to re-read my buffer a little bit later when it has new valid
data. I am using three buffers each for recording and playback queues,
so some delay should be allowable but yet I am loosing sync, that
seems to be the problem. Would it help to have another thread to keep
things balanced and how?
|
1 Try using bigger buffers, that will average out the peaks more
2 Try adding another buffer, but that would not make much difference.
3 You allocate memory only once for the buffers and headers don't you ?.
4 Have a loop waiting on WHDR_DONE in the TWaveHdr.dwFlags which will be set
when wave has finished with the buffer and will be returning it to the
application for you to read from/to.
5 Perhaps three threads (one for waveIn, one for processing, and one for
waveOut) might help, but I'm not really sure. Every additional thread soaks up
more CPU power. On the other hand two threads (one to handle buffer transfer
for both waveIn _and_ waveOut, and another to process) might work even better.
Are you using the same wave buffers to read from for process input, and
similarly the same buffers for process output, or are you using additional
process input and output buffers, and hence have the overhead (although not
much) of memory transfer out of and into the process buffers from and to the
process buffers.
6 Depending on where your delays are, using a callback function might give you
some improvement.
You have a hell of a lot of CPU power. Although I'm not doing the processing
you are I'm using a 500Mhz AMD and doing some other activity with no problem.
What CPU loading is showing.
Alan Lloyd
[email]alanglloyd (AT) aol (DOT) com[/email]
|
|
| Back to top |
|
|
H Strickner
Guest
|
| Posted: Sat Nov 15, 2003 3:17 pm Post subject: Re: Synchronize buffer with WOM_DONE - how? |
|
|
[email]alanglloyd (AT) aol (DOT) com[/email] (AlanGLLoyd) wrote in message news:<20031114094441.28496.00001941 (AT) mb-m18 (DOT) aol.com>...
Hi Alan, thanks for replying...
After some more consideration I have come to the conclusion that I am
probably asking a bit to much from the Windows OS:
I am using WAVEFORMATEXTENSIBLE to enable me to implement 24
BitsPerSample with two channels of data. That requires me to convert
from triple bytes to integer to float both ways and I dont have
suitable asm functions for that as yet. Will post another call for
help for that later perhaps. Next I will try to change the
KSDATAFORMAT_SUBTYPE_PCM to _SUBTYPE_IEEE_FLOAT, that will speed
things up a bit.
The problem happens mainly when I do some graphics processing on a bit
map and sometimes when the Taskmanager is started at the "right" time.
| Quote: |
1 Try using bigger buffers, that will average out the peaks more
|
I like using a buffer size that equals my FFT nsize, either 2048 or
4096 data samples, which equals 85 msec at the 4096 FFT size @ 48000
Hz sample rate. Bigger buffers could help but the overhead of buffer
transfers increases as well. I will have to try transfering 8192
samples and then process them in two parts. Perhaps the overall
efficiency is better then. The downside is of course that the "near
realtime" effect is getting worse.
| Quote: | 2 Try adding another buffer, but that would not make much difference.
|
That would make no difference at all, actually I would prefer to use
two buffers only if Nr 1 above works
| Quote: | 3 You allocate memory only once for the buffers and headers don't you ?.
|
Yes all the memory allocation and header preparation is done in a
setup procedure at program start, it is OK.
| Quote: | 4 Have a loop waiting on WHDR_DONE in the TWaveHdr.dwFlags which will be set
when wave has finished with the buffer and will be returning it to the
application for you to read from/to.
|
No benefit gained here, the problem is that the application data
processing is not completely finished when WOM_DONE arrives.
| Quote: | 5 Perhaps three threads (one for waveIn, one for processing, and one for
waveOut) might help, but I'm not really sure. Every additional thread soaks up
more CPU power. On the other hand two threads (one to handle buffer transfer
for both waveIn _and_ waveOut, and another to process) might work even better.
|
I will experiment with that. Since the playback and recording streams
are asynchronous one may be able to force a better start of the
playback stream. My preference would be to do the waveoutwrite just
before the WIM_DATA is handled. At that time the app buffer must be
done. Dont know if that can be controlled at all.
| Quote: | Are you using the same wave buffers to read from for process input, and
similarly the same buffers for process output, or are you using additional
process input and output buffers, and hence have the overhead (although not
much) of memory transfer out of and into the process buffers from and to the
process buffers.
|
The "middle buffer" where the processing is taking place has
independent input and output buffers. In addition, as mentioned above,
I am using buffers to convert from triple byte to integer and then to
double. On the output side I convert from double to integer and then
to triple byte. But that could be omitted when I am using the
IEEE_FLOAT with the waveformatextensible struct.
| Quote: |
6 Depending on where your delays are, using a callback function might give you some improvement.
|
I prefer to stay with callback_threads as they offer more flexibility
especially with multiple soundcards input/output etc. It gets hard to
make sure that the main window still provides enough response to user
control like menu clicks and other things.
Any further comments are appreciated. Would love to hear from anyone
about 24 bit MME implementation success and problems/solutions.
Regards, Helmut
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
