Problems with MMSystem over 64 bit: a periodical noise appears lazarus / 34-Windows ---------------------------------------------------------------------- HomePlaneR · 2012-09-29 20:14 Hi. I've met quite particular difficulties implementing the waveform playback within Lazarus. The implementation is very typical. Without lots of details it includes the following: * use waveOutOpen(...) and waveOutPrepareHeader(...) to initialize the device and buffer headers (we got HWAVEOUT and TWAVEHDR ready to play), * send audio buffers using waveOutWrite(...). The code works perfectly when compiled over Windows XP 32 bit with Lazarus 0.9.31 / 2.6.0. But when I compile it with Lazarus 1.0 RC1 / 2.6.0 over Windows 7 (the compilation target is x86_64)... Firstly, the playback didn't work (a system error occurred) because the type TWAVEHDR is implemented in MMSystem only for Win32 platform. It is not a big trouble, I thought, and without thinking a lot I add this to the code: Code: [Select]type {$IFDEF WIN64}   TWAVEHDR = packed record     lpData: pointer;     dwBufferLength: QWord;     dwBytesRecorded: QWord;     dwUser: QWord;     dwFlags: QWord;     dwLoops: QWord;     lpNext: PWAVEHDR;     reserved: QWord;   end; {$ELSE}   TWAVEHDR = MMSystem.TWAVEHDR;  //for data size {$ENDIF}   PWAVEHDR = ^TWAVEHDR; I can not be sure that it is correct implementation, however the playback started to work over the both platforms. BUT after several tests I mentioned a quite strange periodic noise like some thin chirp. It is perceptible with 16 bits per sample over 44100 samples per second when a quite simple useful signal is sent (sinusoidal, for example). Of course, I started to storm my code that generates the signal buffer. And it was so amazing to discover that the source of the noise is not on my side. I proved it for myself several times by different ways, but three the simplest proves are: * When the buffers containing only zero samples is sent, we still hear the noise. When the output is set to 16 bit per sample and 44100 samples per second, it is not perceptible (only on the useful signal, as I mentioned, but not with zero samples), however on 8 bits per sample it becomes totally audible for all the sampling frequency values up to 44100 Hz. (I don't talk about quantization noise, please do not tell me what it is and how it is not good to use 8 BPS.) * When the same waveform containing "quite simple useful signal" (I mean exactly the same data bit-to-bit) is playing with external player, there's no any periodical chirp. So, it is not the OS drivers who make the noise. * As I said, when the same code is compiled on WinXP 32 bit, there is no any noise neither 16 nor 8 bit per sample, whatever. My questions are: 1) about TWAVEHDR first: is it my fail that I hadn't find 64 bit header declaration or it is you, guys (FPC developers?), who forgot to implement it? 2) and the principal one: can I do to make disappear the noise? The investigation shows that it is not on my side and not on the OS drivers side. I imagine that MMSystem only translates the function calls to one of Windows DLLs and all the magic happens there, but anyway... Maybe the problem is with my implementation of the TWAVEHDR? Thanks a lot to anyone who will try to help. ---------------------------------------------------------------------- HomePlaneR · 2012-09-29 20:35 OMG... I've just found something more dramatic. I launched the 32 bit executable (compiled on WinXP, this one who doesn't noise) on the 64 bit machine and it noises! I mean the output is clean on the WinXP, but noised on the 64 bit Windows 7. So it caused by something on the OS side. Have anybody met this kind of troubles? ---------------------------------------------------------------------- marcov · 2012-09-30 10:35 Yes, the wavehdr structure is wrong. The dwuser field should scale with pointersize. The packing is maybe not good either. BUT the record you display is wrong. Most dword fields stay dword, also on 64-bit. I fixed a few of these errors in SVN (trunk) in r22504 p.s. if you look at the date of the mmsystem units in the header, you hopefully realize this file is older than the x86 64-bit target. It probably needs a full audit for 64-bit compliance. If you find out details on other 64-bit problems, don't hesitate to report it  to http://bugs.freepascal.org As for the chirping, can be drivers or hardware. Many laptops chirp when they get too hot and the volume is at max. ---------------------------------------------------------------------- HomePlaneR · 2012-09-30 20:54 Quote from: marcov on September 30, 2012, 12:35:46 pmYes, the wavehdr structure is wrong. The dwuser field should scale with pointersize. The packing is maybe not good either. BUT the record you display is wrong. Most dword fields stay dword, also on 64-bit. I fixed a few of these errors in SVN (trunk) in r22504 Could you give a little bit of precision about what you wrote, please? I've tried to change some of these fields but nothing works better. Quote from: marcov on September 30, 2012, 12:35:46 pmp.s. if you look at the date of the mmsystem units in the header, you hopefully realize this file is older than the x86 64-bit target. It probably needs a full audit for 64-bit compliance. If you find out details on other 64-bit problems, don't hesitate to report it  to http://bugs.freepascal.org Yeah, done, I realized it! But I'm just a little signal processing engineer, I never studied the history of the targets and so on. So, I just take "a 32 and 64 bit professional Pascal compiler" and want to use it to construct cool professional 64 bit signal processing applications. And I could never think that it should be my problem to check the dates of the sources you use in order to assure myself that my programs will work. Quote from: marcov on September 30, 2012, 12:35:46 pmAs for the chirping, can be drivers or hardware. Many laptops chirp when they get too hot and the volume is at max. This is certainly not the source of problem.