1

I import "winmm.dll" by using the following code.

  MyUtils = public static class
  private
  protected
  public
    [DllImport("winmm.dll")]
    class method timeBeginPeriod(period:Integer):Integer; external;
    [DllImport("winmm.dll")]
    class method timeEndPeriod(period:Integer):Integer; external;
  end;

Access the methods as follows.

MyUtils.timeBeginPeriod(1); //within winform load event
MyUtils.timeEndPeriod(1);   //within winform formclosing event

Under Windows 7, it works great as expected. Under mono on Linux System, it works as well but with one exception. As soon as the program is started, it pops up with a message box with the name of the dll that is imported and OK button as shown below. When I click the OK button, my program continues and runs as expected without any errors.

enter image description here

I've combed through my program to see if I am intentionally displaying the dll file name anywhere, but I simply can't find anything like that.

EDIT: Little bit more information, the reason I need to work with winmm.dll is I need to be able to adjust thread sleep granularity or default delay down to about 1 milliseconds or close to it - NOT to play movie or music file. The only way I able to adjust is through these methods timeBeginPeriod and timeEndPeriod. So that my program can successfully talk through serial port. My program is to be talking back and forth every few milliseconds nonstop 24/7/365 days. It is critical that its communication is 90% or more. After having imported the dll file, my programs communication is flawless on windows and linuxs except I am getting that annoying messagebox on Linux under mono.

I've never seen or heard of such an issue before. Does anyone why?

Thanks,

ThN
  • 3,235
  • 3
  • 57
  • 115

1 Answers1

4

I think there is some misunderstanding on how Mono works. WinMM.dll is a native binary for Windows. Mono will not automatically allow you to import winmm.dll and use it in a linux environment. I would guess your program does not run as it should since the timeBeginPeriod and timeEndPeriod will not execute.

Unless you have some port of the Windows Multimedia Module for linux this is not going to work. Mono ported over System.Media.SoundPlayer is there any way you can get everything you need from that?

The P/Invoke in Mono works quite well, but you still need natively built binaries for each platform.

There is an article of interest about Porting to linux - replacement for winmm

You might want to look at the LGPL LAME.

Update

The issue is that Thread.sleep is not an accurate wait to create deterministic behavior regardless of the resolution. You cannot use Thread.sleep in order to synchronize something with close to 1ms granularity. Both the JVM and .NET platform can get close to 1ms precision, however, this is not guaranteed. If the system is busy you may not get a context switch back to your thread in time, which means it might be 3ms, or 10ms, or even 30ms at worse.

There are two things you should be searching for. A high resolution timer on Linux. And how to create real-time systems. Since you need to communicate nearly ever ms, you need research real-time systems and figure out how to create a deterministic system for timing.

Most timers will only get you near 30ms resolution.

If you find a High resolution timer on linux, you'll still need to account for context switching and time time lapse to make up lost time, or slow down in the even of sub-millisecond processing.

I realize you are claiming it works great on Windows, but I am attempting to explain that it isn't really working the way you think. It works for now, but there are many scenarios that can play out on that machine that will cause your system to not process the data at 1ms intervals thus requiring you to debug the system at a later date.

Some things to back me up: How to make thread sleep less than a millisecond on Windows

Can
  • 76
  • 10
Andrew T Finnell
  • 13,417
  • 3
  • 33
  • 49
  • Andrew Finnell, I know what you are saying. However, my program does work and those methods seem to be working as expected. I couldn't get Thread.sleep granularity below 10ms for serial communication. Once I was able to do the above, serial communication has been flawless or it is solid 100% on Windows and Linux except for the issue described above, before I just couldn't get any good communication. I will look into your suggestions. – ThN Nov 01 '12 at 17:40
  • I wish people would actually give more information than just keep upvoting this answer which doesn't really help me at the moment. I need to shorten Thread.Sleep delay as close as possible to actual time delay. Is there way to do it with System.Media.SoundPlayer or LAME? – ThN Nov 02 '12 at 15:16
  • @digitalanalog Updated answer to shed some light on why you aren't getting many answers about using Thread.sleep with millisecond precision – Andrew T Finnell Nov 02 '12 at 15:52
  • Andrew - I see what your saying. I had this problem with my system ever since we upgraded to Windows 7. Even for win32 version of my application, I had to do the same. My program sends a request to an external device and it replies back in 10 ms. That's plenty of time for the program to get ready for reading the answer. The problem was this. No matter what I said the sleep to it always was greater than 10ms. If so, my program will never get a chance to read the reply back from the device. So, it timed out most of the time. Now, it doesn't. True, it times out once every 5000 cycles. – ThN Nov 02 '12 at 16:30
  • So far my serial communication has been solid and I am trying to get rid of that annoying messagebox. – ThN Nov 02 '12 at 16:31
  • @digitalanalog If your only goal is to get rid of the text box, don't call MyUtils.timeBeginPeriod(1); when running on Linux. Windows precision for Sleep is lower (meaning it won't be as precise ) than Linux by default. Thus why it works on Linux when MyUtils.timeBeginPeriod(1) is not possibily working on Linux. Just check the OS and remove the call if on Linux. Problem solved. Hope this helps. – Andrew T Finnell Nov 02 '12 at 16:39