I have got the 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 MM_WOM_DONE msg to know that the playback has been finished.
Since a few days however (nothing changed neither in the process nor the machine) the MM_WOM_DONE message has been coming 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 have 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 for me to perform that once again and I am trying more analytical approach :). Any suggestions what might cause such a behavior? Maybe something on the other end of the ISDN line?
Based on your description, you are doing the playing asynchonously. Are you sure that the backing memory for the wav file is not being cleaned up in that time?
I don't have the time to Google too much for this, but I know that either Larry Osterman or Raymond Chen blogged about a similar situation.
I'll check back later when I have more time to see if this question is still open.
What is the return value when the sound does not play? If you get MMSYSERR_NOERROR that points to the driver incorrectly reporting to the OS that the buffer was processed.
Has the WAV file itself changed? This blog entry indicates that some pretty in-depth validation is done on the metadata.
Related
My application started life as a c++ Console application in VS2019. Code was provided as part of an SDK. Worked perfect. Great response from the manufacturer USB device. Later, I wanted to graduate is to a GUI application, much as I've been doing in VB and c#. Lo and behold, I managed to reconstruct the application in both Qt and Win32 but I'm running into a situation where the application becomes unresponsive and I have no way to tell what's going on.
In the Console application, I have to execute this code to interface with the device AFTER sending a "TakeMeasurement" command :
if (SDK_SUCCESSFUL(sdkError)) {
printf("\nWaiting for measurement to complete...\n");
while (!isMeasureWait) {
if (isDisConnect) break;
this_thread::sleep_for(chrono::milliseconds(1000));
}
}
This code works like a charm! Ater one or two iteration, the device has completed the measurement and I can get to the data easily.
On the Win32 side, I use the exact same code. Only, once control enters the loop, it never returns.
Any idea how I could diagnose the error? I have the impression that the "timing" is critical, between the exact moment where the Measurement command is initiated to the exact moment the instrument signals that it's done, and the data ready to be picked up.
My naive hypothesis is that, in debug mode on both 'platforms', I must be getting some timing differences? Sadly, I can't get more information from the manufacturer in this regard but I suspect I have a small window of time within which the instrument's response can be acted on? And I begin to suspect that, on Win32, that "time" is too long? Compared to on the Console side?
I was thinking of, perhaps, "measuring" that time, in milliseconds? First, on the Console side, to see what kind of delay "works", and then, to see how the delay compares with the Win32 side.
I may be wasting my time and I sure don't mean to waste yours.
How would I go about getting an idea of time elapsed in a c++ application? I'll take a look around VS2019, they have all kinds of "performance" things that popup at run time?
Any help is appreciated.
I am not sure I completely understand what is going on.
Execution of the thread wait loop was not not the culprit.
I'm not 100% sure but what happens is that, in my 'Export data to CSV TEXT file', if I tried to execute the call to :
SetWindowText(hEditMeasure, wMeasurements);
The application always hung. I placed breakpoints right before the call in the code, to trace execution, and it did not strike me at first but, in VS toolbar, there was a "thread" comboBox? With the value showing = DEVICE.DLL? and to its right, the name of my Export function as the Stackframe. In searching for additional information on the setWindowText function, I came accross the reference to use VM_SETTEXT to send to "different application"? Could it be unknowingly I was sending a message to "another thread", the DLL thread? And that's why it hung? I did not know enough to tell. So I started to move the setWindowText line around, ultimately inside the code that is called by the "Measure" button, and it worked!
I'm not out of the woods yet but I feel I'm making progress. Thank you all for your help and patience.
I have code that performs following steps:
open file
write data
set file timestamps (via SetFileInformationByHandle(FileBasicInfo))
close file
When file is stored on certain NAS devices (and accessed via share) it's modification time ends up being set to current time.
According to Process Monitor Close() in step 4 results in a Write (local cache gets flushed/pushed to NAS device) that (seemingly) updates file's mtime on server.
If I add FlushFileBuffers() (or sleep for few seconds) between steps 2 and 3 -- everything is fine.
Is this a bug in SMB implementation of this NAS device (Dell EMC Isilon) or SetFileInformationByHandle() never promised anything?
What is the best way to deal with this situation? I would really like to avoid having to call FlushFileBuffers()...
Edit: Great... :-/ It looks like for executables (and only executables) atime (last access time) gets screwed up too (in the same way). Only these are harder to reproduce -- need to run this logic few times. Could be some antivirus... I am still investigating.
Edit 2: According to procmon access time gets updated by EXPLORER.EXE -- when it sees an executable, it can't resist opening it and reading portions of it (probably extracting the icon).
You can't really do anything -- I guess Isilon's SMB implementation doesn't support certain things (that would've preserved timestamps).
I simply added FlushFileBuffers() before SetFileInformationByHandle() and made sure there are no related race conditions in my code.
I've done a bunch of research, but I can't figure out how to load a .wav file into memory and then play it. Also, I'd like to have the capability to simultaneously play multiple loaded .wav files.
Currently, I load the .wav file into string buffer, then call:
PlaySound(stows(buffer).c_str(), NULL, SND_MEMORY);
stows() is a function I created which converts a string into a wide string.
What am I doing wrong/what could I be doing better?
EDIT: I'm trying to use SFML now. I followed the walkthrough here to a T, but I'm getting 9 linker errors when I attempt to compile. It doesn't matter if I use the static or dynamic dlls.
EDIT2: I must have VS2010 32 bit. I downloaded SFML 2.0 32 bit for VS2010 and now I'm down to 5 linker errors. It says all of them are occurring in sfml-audio-s.lib.
EDIT3: I got it to compile! However, it simply isn't playing anything. I used VS to debug and confirmed that I am opening the WAV file correctly and storing it in a Sound object, but when I call the play() method, nothing happens. Furthermore, I'm getting an unhandled exception every time I close the program.
I'm reasonably convinced that PlaySound isn't able of mixing two sounds playing simultaneously. You can have one sound interrupt the other, and you can make it play "in the background" while your code is doing other things (using SND_ASYNC), but the documentation is pretty clearly stating that "if another sound is played, the current one stops" - in the section of SND_NOSTOP:
If this flag is not specified, PlaySound attempts to stop any sound
that is currently playing in the same process
(If you specify SND_NOSTOP, it doesn't play this sound if another one is already playing).
Link to full documentation: PlaySound.
I'm afraid I don't know exactly how you create sound playing using multiple sounds simultaneously, as I've never done that on a PC (I have used hardware mixers, and I've also written code to merge two sounds from a file, but that's almost certainly not what you want)
I got it working! I ended up using direct sound. I made a class to load and play .WAV files based on a tutorial I found here, which was immensely helpful.
Sometimes (in about 50% of runs), EnumDevices takes 5-10 seconds to return. Normally it is almost instant. I couldn't find any other reports of this kind of behaviour.
When things are this slow, it's ok to profile by watching stdout :) This:
std::cout << "A";
directInput8Interface->EnumDevices(DI8DEVCLASS_GAMECTRL, MyCallback, NULL, DIEDFL_ATTACHEDONLY);
std::cout << "C";
...
BOOL CALLBACK MyCallback(LPCDIDEVICEINSTANCE, LPVOID)
{
std::cout << "B";
return DIENUM_CONTINUE;
}
Seems to hang at a random point through enumerating devices - sometimes it'll be before the callback is called at all, sometimes after a couple, and sometimes it will be after the last call to it.
This is clearly a simplified chunk of code; I'm actually using the OIS input library ( http://sourceforge.net/projects/wgois/ ), so for context, please see the full source here:
http://wgois.svn.sourceforge.net/viewvc/wgois/ois/trunk/src/win32/Win32InputManager.cpp?revision=39&view=markup
There doesn't seem to be anything particularly fruity going on there though, but possibly something in their initialisation could be the cause - I don't know enough about DI8 to spot it.
Any ideas about why it could be so slow will be greatly appreciated!
EDIT:
I've managed to catch the hang in an etl trace file and analysed it in Windows Performance Analyzer. It looks like EnumDevices eventually calls through to DInput8.dll!fGetProductStringFromDevice, which calls HIDUSB.SYS!HumCallUSB, which calls KeWaitForSingleObject and waits. 9 times out of 10 (literally - there are 10 samples in the trace) this returns very quickly (324us each), with the readying callstack containing usbport.sys!USBPORT_Core_iCompleteDoneTransfer followed by HIDUSB.SYS!HumCallUsbComplete, which looks quite normal.
But 1 time in 10, this takes almost exactly 5 seconds to return. On the readying callstack is ntkrnlmp.exe!KiTimerExpiration instead of the HIDUSB.SYS function. I guess all this indicates that the HIDUSB.SYS driver is querying devices asynchronously with a timeout of 5 seconds, and sometimes it fails and hits this timeout.
I don't know whether this failure is associated with any one device in particular (I do have a few USB HIDs) or if it's random - it's hard to test because it doesn't always happen. Again, any information anyone can give me will be appreciated, though I don't hold out any hope for Microsoft fixing this any time soon given the odd situation DirectInput is in!
Perhaps I'll just have to start initialising input earlier, asynchronously, and accept that sometimes there'll be a 5 second delay before user input can happen.
I was running into this too, largely as an end user, but it's been annoying the hell out of me for years. I didn't realize it was this issue until I ran into it on an open source project and was able to debug it.
Turns out it was my USB Headphone DAC (The Objective DAC from Massdrop), it installs the driver: wdma_usb.inf_amd64_134cb113911feba4\wdma_usb.inf for Device Instance ID USB\VID_262A&PID_1048&MI_01\7&F217D4F&0&0001 and then shows up in Device Manager under Sound, video and game controllers as: ODAC-revB USB DAC and, under Human Interface Devices as: USB Input Device and HID-compliant consumer control device.
I have no idea what the HID entries do but... When they are enabled and this DAC is set as the Audio Output device both IDirectInput8_CreateDevice and EnumDevices are painfully slow. Disabling the "USB Input Device" entry seems to cause no negative effects and completely solves my issue.
Changing the Audio output from the DAC to anything else also weirdly solved the issue.
This was so bad that it made the Gamepad Configuration dialog joy.cpl unusable, hanging and eventually crashing.
I was wanting this to just be a comment but I don't have enough rep for it, and this is pretty much the only place on the internet that describes this problem though so hopefully this helps someone else one day!
I had the same issue. I have a Corsair K65 LUX RGB keyboard. I updated CUE and it seems to have fixed the issue
Got same issue when having my Corsair K55 Keyboard. Changing the keyboard of USB port fixes the issue for a while, but then it comes back later on. So it seems to be a buggy drivers issue.
As DaFox has pointed out, a likely cause appears to be certain device drivers being enabled. I contacted JDS Labs support (who sell one device which happens to install one such driver) and they kindly pointed out that the root cause is actually a bug within Windows (not the installed driver), and they actually provide the solution on their troubleshooting page. See Games hang or experience loading delays, which explicitly mentions VID_262. Disabling this driver fixes the issue without apparent side effects (under the condition that that is the only driver triggering the bug). As for what exactly is going wrong within Windows, here there be dragons.
So I guess the go-to solution (for users) is to scrape all the troubleshooting and FAQ pages for all devices which you have ever connected to your system and see if there is a mention of delays/lag caused by a driver.
As a software developer, you will probably want to benchmark the execution time of the affected code and kindly tell the user there is something wrong with their system configuration and where to look for how to fix it in case it is unreasonably long.
Same issue with Corsair K70 Keyboard.
Quickly reconnecting keyboard fixes this, until next time. Usually happens after some DirectInput devices removed from the system or go to sleep.
This has been plaguing me as a developer and my friend as a user for years. All games using DInput, SDL SDL_INIT_JOYSTICK or anything depending on that, took extremely long to initialize.
It was caused by a faulty driver of a DAC, and as pointed out by DaFox, disabling the corresponding USB Input Device resolved the issue. Although it's labeled with a different manufacturer name, the vendor IDs match.
The hardware ID of the device is USB\VID_262A&PID_9023&REV_0001&MI_00.
Same issue appears to happen with a Steelseries Apex 7 keyboard. Unplugging and plugging that keyboard back again got rid of 3 freezes (of 10 seconds each) while enumerating USB devices.
I'm a newbie C++ developer and I'm working on an application which needs to write out a log file every so often, and we've noticed that the log file has been corrupted a few times when running the app. The main scenarios seems to be when the program is shutting down, or crashes, but I'm concerned that this isn't the only time that something may go wrong, as the application was born out of a fairly "quick and dirty" project.
It's not critical to have to the most absolute up-to-date data saved, so one idea that someone mentioned was to alternatively write to two log files, and then if the program crashes at least one will still have proper integrity. But this doesn't smell right to me as I haven't really seen any other application use this method.
Are there any "best practises" or standard "patterns" or frameworks to deal with this problem?
At the moment I'm thinking of doing something like this -
Write data to a temp file
Check the data was written correctly with a hash
Rename the original file, and put the temp file in place.
Delete the original
Then if anything fails I can just roll back by just deleting the temp, and the original be untouched.
You must find the reason why the file gets corrupted. If the app crashes unexpectedly, it can't corrupt the file. The only thing that can happen is that the file is truncated (i.e. the last log messages are missing). But the app can't really jump around in the file and modify something elsewhere (unless you call seek in the logging code which would surprise me).
My guess is that the app is multi threaded and the logging code is being called from several threads which can easily lead to data corrupted before the data is written to the log.
You probably forgot to call fsync() every so often, or the data comes in from different threads without proper synchronization among them. Hard to tell without more information (platform, form of corruption you see).
A workaround would be to use logfile rollover, ie. starting a new file every so often.
I really think that you (and others) are wasting your time when you start adding complexity to log files. The whole point of a log is that it should be simple to use and implement, and should work most of the time. To that end, just write the log to an unbuffered stream (l;ike cerr in a C++ program) and live with any, very occasional in my experience, snafus.
OTOH, if you really need an audit trail of everything your app does, for legal reasons, then you should be using some form of transactional storage such as a SQL database.
Not sure if your app is multi-threaded -- if so, consider using Active Object Pattern (PDF) to put a queue in front of the log and make all writes within a single thread. That thread can commit the log in the background. All logs writes will be asynchronous, and in order, but not necessarily written immediately.
The active object can also batch writes.