Yaron

@Kas Ob.

VCP looks like a massive library, I looked at the waveplayer demo and it doesn't seem to support output device selection.

If you have experience with VCP, can you give me a few pointers, my goal is play .wav files asynchronously in the background as the user is traversing the menu.

I currently use this function structure "PlaySound(sAudio : WideString; sDevice : String; iVolumeLevel : Integer);"

Where sAudio is the ".wav" filename, sDevice is the audio device name and iVolumeLevel is a volume value from 0 - 100.

@Vincent Parrett I'm using the latest version of FastMM

@Kas Ob. For clarity, Sound FX is ".wav" file playback and I only use GDI+ to decode JPEG files.

Delphi 7, Windows 10.

I wrote a menu system that plays SoundFX (basically WAV files) based on user actions.

I need to be able to control the playback device, volume and support asynchronous concurrent playback of multiple SFX.

To do this, I decided to go with DirectShow and it worked like a charm. However, each time you play an audio through DirectShow it creates multiple threads which are then terminated as the DirectShow graph is stopped.

So even if you play a single SFX, each time the SFX is triggered, Directshow will create and destroy several threads in the process.

I believe this behavior is contributing to memory fragmentation in my app.

Is there a method other than DirectShow to asynchronously play WAV files with volume control and allowing audio device selection for output?

I'm using Delphi 7, 16GB ram, Windows 10.

I needed to write a SoundFX playback module that supported multiple audio devices, volume level, and multiple effects playing.

I thought the smartest/cleanest way would be to create a new thread for each SFX, play it using DirectShow and then let the thread clean itself up.

It seemed like an elegant solution, just fire and forget, windows took care of the sound mixing and it worked reasonably well.

That is, until my GDI+ based JPEG decoding code started exhibiting random memory allocation issues.

I'm not too familiar with underlying windows memory management, but it seems that there is memory defrag operation that works in the background, otherwise the memory allocation issues would be constant and not random (working, not working and working again in the span of a second).

Is there a WinAPI function I can call to defrag my app's memory?

In the meanwhile I'm trying to work around this issue by reusing threads instead of going through many create/destroy cycles, but I'm still interested if there's an answer to my defrag question.

1 minute ago, luebbe said:

The grijjy timer queue works fine. I'm using it to draw on screen in regular intervals. You shouldn't allow VCL style changes while drawing, It got me into all kinds of trouble.

The code I'm calling is very thread-unsafe, I would have to completely rewrite several sub-systems to make it thread safe, I think it would be more beneficial if I could somehow instantly synchronize the code.

Thing is, how does synchronize work, is it only triggered on a system tick? If so, I'm stuck at again at the 16ms tick timing and this whole approach is pointless unless I rewrite a lot of code.

I discovered a few things regarding timeBeginPeriod :
1. From MSDN: "Prior to Windows 10, version 2004, this function affects a global Windows setting. For all processes Windows uses the lowest value (that is, highest resolution) requested by any process. Starting with Windows 10, version 2004, this function no longer affects global timer resolution. For processes which call this function, Windows uses the lowest value (that is, highest resolution) requested by any process. For processes which have not called this function, Windows does not guarantee a higher resolution than the default system resolution."

2. timeBeginPeriod doesn't work as advertised. If i use timeBeginPeriod(16), you'll get the usual 16ms timer accuracy, however, at least on my system (fully patched win10), calling timeBeginPeriod(15) is enough to set an actual timer accuracy of 1-2ms.

So if I can't find a way to synchronize callbacks without changing periodic timer accuracy, I believe using timeBeginPeriod with tthread/Sleep/synchronize is the safest approach I can use.

According to the GitHub sample I linked above, "The stdcall [callback] procedure will be called for each interval for each and every timer in the queue. In other words, you can expect this event to be called by multiple threads and it needs to be completely thread safe".

So this brings up my previous question, how can I synchronize the actions I want to take with the main thread?, otherwise my code will not be thread safe.

7 minutes ago, FPiette said:

I don't know what you draw on screen, but have you considered off-loading everything to the GPU? Much like a game.

I can't use the GPU, it would mean rewriting A LOT of code and in my use-case I actually prefer the GPU to be free to do other things.

Does anyone know if the callback function in CreateTimerQueueTimer runs within my app's main process thread or in a completely different thread?

If it's in a different thread, how do I synchronize the call to make sure it's running in the main thread? Using critical sections or is there another mechanism I'm not thinking of?

Just now, Anders Melander said:

Yes, I understood that but if you're concerned about not wasting resources, as you state, then there's no reason to refresh more often than what the monitor can handle.

I don't care about wasting resources while there's screen updates to generate, I'm concerned about wasting resources when doing nothing but waiting for the next update.

Trying to work with v-sync is a pain, if you miss an update window there's serious judder.

I found a good resource at https://github.com/grijjy/DelphiTimerQueue

Hopefully it will resolve my issue, the workaround I'm currently using is having multiple thread that keep trying to update the screen if at least 1ms passed since another thread triggered an update. Not really the best approach.

1 minute ago, Anders Melander said:

Okay, that makes better sense.

Instead of updating at a fixed 120 Hz I think you'll want to sync your refresh to the monitors vertical retrace. I don't know how to do that but I found this: http://masm32.com/board/index.php?topic=4410.0

I don't want to block for v-sync, I don't care if there's tearing. I just want to get 60+fps screen updates without bogging down a CPU core.

I'm looking at queue timers as FPiette mentioned (looks like multimedia timers were depreciated in favor of queue timers), if anyone has a sample using "CreateTimerQueueTimer" in Delphi (compatible with Delphi7), that would be cool.

Just now, Anders Melander said:

If a regular WM_PAINT handler will not update fast enough I can't see how a timer controlled paint will. What am I missing?

The problem is not the frame-update speed (which on my PC is about 3ms), it's about how to time the call to update the screen within a specific time-frame and not in 16/32ms intervals.

I want smooth scrolling, using Sleep(1), I measure 15-30ms delay per frame, resulting in unstable scrolling because the delay between screen-updates is inconsistent/juddery and ~33fps which looks really bad.

I have a function I'd like to call 120 times per seconds using TThread.Synchronize (as the function updates the screen).

I don't want to completely bog down a CPU core by constantly calling "QueryPerformanceFrequency" in a loop until the time is right to trigger the function.

I originally envisioned using Sleep(1), but in reality, Sleep(1) usually means 15.6ms unless I change the entire system's Tick accuracy using "TimeBeginPeriod/TimeEndPeriod".

However, I don't want to affect the entire system as I've read there's a harsh 25% battery impact when switching the accuracy and I don't want to drain the client's battery.

So what is the best, most precise way to time/trigger synchronized calls from a thread?

Nevermind, I replaced Sleep with WaitForSingleObject and used an event to break out of the wait when closing the dialog.

I use a thread to update an animated 'please wait' dialog while doing other things in the background.

The issue is, I want to be able to dismiss the please wait dialog instantly and since I use animations, I use "Sleep" commands to to time the animation and take minimum CPU time.

However, for some reason, doing Sleep(10) returns a vastly different result than calling For I := 0 to 1 do If Terminated = False then Sleep(5); which for some reasons takes ~30ms to complete.

For reference, calling For I := 0 to 9 do If Terminated = False then Sleep(1); takes ~150ms.

My problem is with Delphi 7, but I doubt it's specific to this version of Delphi, any ideas?

No, I don't use TJPEGImage at all, I'm basically compositing several tbitmaps, writing a bit of text on an image and using 'fill' to draw a small box (for Zoom Player's media library thumbnails),

The canvas are all locked and the issue only seems related to brush colors.

I ended up writing my own bitmap based fill function, since it has a lot less overhead (my code needs less sanity checks as the input values are always in valid ranges), it's about 40% faster than Delphi's implementation, so win-win.

Although I resolved the issue, if anyone knows the "recommended" method of using brushes with threads, I'd be interested.

@David Heffernan

The entire threaded code is written within the canvas's lock section and works without any issues (font drawing and bitmap operations), except for the brush color which occasionally seems to use the wrong color.

I didn't paste the entire code for simplicity.

Looks like I have to raise this thread from the dead.

Even though I'm calling Bitmap.Canvas.lock and no other thread is writing to the canvas, I rarely get a weird fill color issue.

This is a subset of the code:
 

WorkBM.Canvas.Lock;

Try

   WorkBM.Canvas.Brush.Color := clRed;
   WorkBM.Canvas.FillRect(barRect);

Finally

  WorkBM.Canvas.Unlock; 

End;

Somehow, the fillrect colors occasionally (very rarely) swaps to a different color.

Do brushes require a separate type of lock?

I'm not using any external java files.

I've noticed 2 new warnings when uploading to the play store:

This App Bundle contains native code, and you've not uploaded debug symbols. We recommend you upload a symbol file to make your crashes and ANRs easier to analyze and debug.

---

These warnings only affect ANR reports, but should I take steps to correct them?

@aehimselfnot using a VM

@dummzeuchI changed the folder permission to allow full control to the user-account, had the same setup in Win7.

@rvk Thank you, I've disabled exploit protection for "c:\Program Files (x86)\Borland\Delphi7\Bin\delphi32.exe" and my app's executable to see if it helps.

@Arnaud Bouchez I wasn't ware of delphispeedup, I'll give it a shot.

And by "slow", I mean about 50% slower compile times and longer load time when running the app from within Delphi.

I've added the entire Delphi folder and my entire development partition (all my projects are on a separate drive) to the Exclusion list, but it didn't have an impact on the compilation/execution slowdowns.

I tried the compatibility troubleshooter which suggested running as Win XP SP3, but when doing so, I couldn't even run my applications from Delphi, it just froze.  Trying Win7 compatibility now to see if it works any better (at least apps run).