Yaron

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?

@Kas Ob.I wasn't intending for my app to do the mixing, windows does it itself automatically as long as the audio device is not locked exclusively. I'm not sure if your solution is per-application or affects the entire system. I guess I have to do some more research.

@Kas Ob. Passing a volume level greater than 100 does digital amplification? If that's the case then it's a non-issue as I don't plan on allowing greater than 100 volume.

@Kas Ob. Thank you, I really appreciate your effort and time, I will try it out shortly. How does the rare mixer timing bug manifest itself, what should I be looking for?

@Kas Ob. There are currently 5 events that trigger a different .wav file playback, might be extended to 9 in the future. With regards to output devices, I mean on my PC I have speakers and a TV set, with DirectShow I can control whether the audio is played through the speakers or through the TV set.

@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.

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.

@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.

I am trying to build a system that will handle concurrent DB requests efficiently, there's not a lot of load, but it should be able to handle more than 1 query concurrently. I am using FireBird v3.0.4 and Delphi 10.3.2 with the TFDConnection component. I am hosting the code in an ISAPI DLL that runs on IIS 7.5. Right now I'm creating the DB connection using TFDConnection in the DLL's "initialization" section. However, I noticed that even under low-load (2-3 users), I occasionally get an "[FireDAC][Phys][FB]Error reading data from the connection." exception when performing a DB query (not the same DB query, it seems pretty random). I tried to research the error and didn't find anything clear, the best I got was : https://forums.embarcadero.com/thread.jspa?threadID=245750 Which seems to indicate that I should instance a copy of TFDConnection for every query. Before I make significant code changes to test this, I would welcome any tips on the best approach to handling DB concurrency.

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?

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.

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?

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.

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.

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 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?

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

I wonder if anything in my code is not thread safe as I get the occasional random freezes in the copy-background code (bitblt functions) when using multiple threads. As you can see, all the bitmaps are created within the thread's execute function and their source data is coming from bitmaps in the main thread that is copied over within a critical section. This is using Delphi 7. procedure TThumbRendererThread.Execute; var thumbBitmapDarkL : TBitmap; backgroundBitmap : TBitmap; WorkBM : TBitmap; begin thumbBitmapDarkL := TBitmap.Create; backgroundBitmap := TBitmap.Create; WorkBM := TBitmap.Create; WorkBM.Width := thumbWidth; WorkBM.Height := thumbHeightTotal; BackdropChanged := True; While (Terminated = False) do Begin If BackdropChanged = True then Begin csThumbRenderer.Enter; Try // Copy bitmaps from main thread (within Critical Section) thumbBitmapDarkL.Assign(LibNavForm.thumbBitmapDark); backgroundBitmap.Assign(s_mlBackground); Finally csThumbRenderer.Leave; End; BackdropChanged := False; End; DebugLog('Copy backgrounds (before)'); BitBlt(WorkBM.Canvas.Handle,0,0,thumbWidth,thumbHeight,thumbBitmapDarkL.Canvas.Handle,xOfs,yOfs,SRCCOPY); BitBlt(WorkBM.Canvas.Handle,0,thumbHeight,thumbWidth,thumbHeightTotal-thumbHeight,BackgroundBitmap.Canvas.Handle,xOfs,yOfs+thumbHeight,SRCCOPY); DebugLog('Copy backgrounds (after)'); // Do other things End; WorkBM.Free; backgroundBitmap.Free; thumbBitmapDarkL.Free; end;

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.