Search Results

Search found 2 results on 1 pages for 'waveoutwrite'.

Page 1/1 | 1 

  • Problem with waveOutWrite and waveOutGetPosition deadlock

    - by MusiGenesis
    I'm working on an app that plays audio continuously using the waveOut... API from winmm.dll. The app uses "leapfrog" buffers, which are basically a bunch of arrays of samples that you dump into the audio queue. Windows plays them seamlessly in sequence, and as each buffer completes Windows calls a callback function. Inside this function, I load the next set of samples into the buffer, process them however, and then dump the buffer back into the audio queue. In this way, the audio plays indefinitely. For animation purposes, I'm trying to incorporate waveOutGetPosition into the application (since the "buffer done" callbacks are irregular enough to cause jerky animation). waveOutGetPosition returns the current position of playback, so it's hyper-precise. The problem is that in my application, making calls to waveOutGetPosition eventually causes the application to lock up - the sound stops and the call never returns. I've boiled things down to a simple app that demonstrates the problem. You can run the app here: http://www.musigenesis.com/SO/waveOut%20demo.exe If you just hear a tiny bit of piano over and over, it's working. It's just meant to demonstrate the problem. The source code for this project is here: http://www.musigenesis.com/SO/WaveOutDemo.zip The first button runs the app in leapfrog mode without making the calls to waveOutGetPosition. If you click this, the app will play forever without breaking (the X button will close it and shut it off). The second button starts the leapfrogger and also starts a forms timer that calls the waveOutGetPosition and displays the current position. Click this and the app will run for a short while and then lock up. On my laptop, it usually locks up in 15-30 seconds; at most it's taken a minute. I have no idea how to fix this, so any help or suggestions would be most welcome. I've found very few posts on this issue, but it seems that there is a potential deadlock, either from multiple calls to waveOutGetPosition or from calls to that and waveOutWrite that occur at the same time. It's possible that I'm calling this too frequently for the system to handle.

    Read the article

  • Playing wave file ends immediatly (C++, Windows)

    - by TyBoer
    I've got a following situation. On a machine there is a Fritz ISDN card. There is a process that is responsible for playing a certain wave file on this device's wave out (ISDN connection is made at startup and made persistent). The scenario is easy, whenever needed the process calls waveOutWrite() on the previously opened wave device (everything initialized without any problems of course) and a callback function waits for MMWOMDONE msg to know that the playback has been finished. Since a few days however (nothing changed neither in the process nor the machine) the MMWOMDONE message comes immediately after calling waveOutWrite() even though the wave lasts a couple of seconds. Again no error is reported, it looks like the file was played but had zero length (which is not the case). I am also sure that waveOutReset() was not called by my process (it would also trigger sending the mentioned message). I already used to have some strange problems in the past that where solved simply by reinstalling TAPI drivers. This time for some reason it is problematic form me to perform that once again and am trying more analytical approach :). Any suggestions what might cause such a behavior? Maybe sth on the other end of the ISDN line?

    Read the article

1