We Keep Coding

C# multithreaded program hangs when doing multiple audio sample collection

Good evening guys,
I have issue with multithreading. I'm doing multiple audio samples collection using a parallel.foreach. I want to be able to do the collection simultaneously. I'm doing a sort of a producer consumer pattern. But the producer section, which is the audio samples collection is hanging soft of.
In each of the parallel threads:
A blocking collection is created to collect audio samples
A progress bar is created to monitor mic input
Lastly a Record function for recording/collecting audio input
I created a blocking collection array for each process, and using naudio WaveInEvent for recording from mic.
The challenge i'm facing is that
The program does not resume when I minimize the window
Sometimes the program hangs, other times it takes a while before hanging, but overall, the responsiveness is not good at all (Jerky)
Apart from all these the program is working fine.
What can I do for better performance.
Please check my code below. Thanks
using System;
using System.Collections.Concurrent;
using System.Collections.Generic;
using System.Data;
using System.Data.OleDb;
using System.Diagnostics;
using System.IO;
using System.Linq;
using System.Threading;
using System.Threading.Tasks;
using System.Windows.Forms;
using Microsoft.Win32;
using NAudio.Wave;
public partial class frmAudioDetector : Form
{
//static BlockingCollection<AudioSamples> realtimeSource;
BlockingCollection<AudioSamples>[] realtimeSource;
static WaveInEvent waveSource;
static readonly int sampleRate = 5512;
private void frmAudioDetector_Load(object sender, EventArgs e)
{
try
{
var tokenSource = new CancellationTokenSource();
TabControl.TabPageCollection pages = tabControl1.TabPages;
//Tabs pages.Count is 8
List<int> integerList = Enumerable.Range(0, pages.Count).ToList();
//Parallel.foreach for simultaneous threads at the same time
Parallel.ForEach<int>(integerList, i =>
{
realtimeSource[i] = new BlockingCollection<AudioSamples>();
var firstProgressBar = (from t in pages[i].Controls.OfType<ProgressBar>()
select t).FirstOrDefault();
var firstEmptyComboBox = (from c in pages[i].Controls.OfType<ComboBox>()
select c).FirstOrDefault();
int deviceNum = firstEmptyComboBox.SelectedIndex;
//create a separate task for each tab for recording
_ = Task.Factory.StartNew(() => RecordMicNAudio(deviceNum, firstProgressBar, i));
});
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
}
//Record audio or store audio samples
void RecordMicNAudio(int deviceNum, ProgressBar progressBar, int t)
{
waveSource = new WaveInEvent();
waveSource.DeviceNumber = deviceNum;
waveSource.WaveFormat = new NAudio.Wave.WaveFormat(rate: sampleRate, bits: 16, channels: 1);
waveSource.DataAvailable += (_, e) =>
{
// using short because 16 bits per sample is used as input wave format
short[] samples = new short[e.BytesRecorded / 2];
Buffer.BlockCopy(e.Buffer, 0, samples, 0, e.BytesRecorded);
// converting to [-1, +1] range
float[] floats = Array.ConvertAll(samples, (sample => (float)sample / short.MaxValue));
//collect realtime audio samples
realtimeSource[t].Add(new AudioSamples(floats, string.Empty, sampleRate));
//Display volume meter in progress bar below
float maxValue = 32767;
int peakValue = 0;
int bytesPerSample = 2;
for (int index = 0; index < e.BytesRecorded; index += bytesPerSample)
{
int value = BitConverter.ToInt16(e.Buffer, index);
peakValue = Math.Max(peakValue, value);
}
var fraction = peakValue / maxValue;
int barCount = 35;
if (progressBar.InvokeRequired)
{
Action action = () => progressBar.Value = (int)(barCount * fraction);
this.BeginInvoke(action);
}
else progressBar.Value = (int)(barCount * fraction);
};
waveSource.RecordingStopped += (_, _) => Debug.WriteLine("Sound Stopped! Cannot capture sound from device...");
waveSource.BufferMilliseconds = 1000;
waveSource.StartRecording();
}
}

To access pages[i].Controls from a non-UI thread (e.g. a threadpool threat that will come from Parallel.ForEach) seems wrong.
The NAudio object already uses event driven programming (you provide a DataAvailable handler and RecordingStopped handler) So there's no need to do that setup work in parallel or in any thread other than the main UI thread.
I would not invoke the volume indicator (progress bar) update directly from the DataAvailable handler. Rather I'd update the control on a Timer tick, and just update a shared variable in the DataAvailable handler. This is event driven programming -- there are no threads or tasks are required that I can see apart from the ones that are already used by the wave source IO threads.
e.g.: Use a variable with a simple lock. Access to this data must be governed with a lock because the DataAvailable handler will be invoked on an IO thread to store the current volume, but the value read on the UI thread by the Timer Tick handler, which you can update at a modest rate, certainly no faster than your screen refresh rate. 4 or 5 times per second is likely frequently enough. Your BufferMilliseconds is already 1000 milliseconds (one second) so you may only be getting sample buffers once per second anyway.
Form-level fields
object sharedAccess = new object();
float sharedVolume;
WaveInEvent DataAvailable handler
lock (sharedAccess) {
sharedVolume= ...;
}
Timer Tick handler
int volume = 0;
lock(sharedAccess) {
volume = sharedVolume;
}
progressBar.Value = /* something based on...*/ volume;
Goals:
do a little work as possible in all event handlers on the UI thread.
do as little work as possible in the IO threads (WaveInEvent.DataAvailable handler).
minimize synchronization between threads when it must occur (try to block the other thread for the least amount of time possible).
With the volume meter out of the way, I'm similarly suspicious about how BlockingCollection coordinates access when calling realtimeSource[t].Add(new AudioSamples(floats, string.Empty, sampleRate)); Who is reading from this collection? There is contention here between the IO thread on which the bytes are arriving and whatever thread may be consuming these samples.
If you are just recording the samples and don't need to use them until recording is complete, then you don't need any kind of special synchronization or blocking collection to accumulate each buffer into a collection. You can just add the buffers into a traditional List - provided you don't access it from any other threads until recording is completed. There may be overhead in managing access to that blocking collection that you don't need to incur.
I get a little nervous when I see all the format conversion you've done:
from incoming buffer to array of shorts
from array of shorts to array of floats
from array of floats to AudioSamples object
from incoming buffer to Int16 during the volume computation (Why not use re-use your array of shorts?)
Seems like you could cut out a buffer copy here by going directly from the incoming format to the array of floats, and perform your volume computation on the array of floats or on a pinned pointer to the original buffer data in unsafe mode.

How to stop a thread when a new one is initiated? [duplicate]

This question already has answers here:
How to Cancel a Thread?
(4 answers)
Closed 5 years ago.
I'm improving the performance of a 3d engine i created, introducing LockBits and parallel processing. I have a class for the engine with the following method to update a bitmap with the result:
public void draw() {
clearbmp();
// locking bmp
BitmapData bitmapData = bmp.LockBits(new Rectangle(0, 0, W, H), ImageLockMode.ReadWrite, bmp.PixelFormat);
IntPtr FirstPixel = bitmapData.Scan0;
int bytes = Math.Abs(bitmapData.Stride) * H;
bpp = Bitmap.GetPixelFormatSize(bmp.PixelFormat) / 8;
rgbarray = new byte[bytes];
System.Runtime.InteropServices.Marshal.Copy(FirstPixel, rgbarray, 0, bytes);
int count = 0;
for (int k = 0; k < solidos.Count; k++)
{
if (solidos[k] != null && solidos[k].draw)
{
// separating faces of the solid into different threads
Parallel.ForEach(solidos[k].side, f =>
{
// ... do the operations...
});
}
}
// copy the array to the bitmap and unlock
System.Runtime.InteropServices.Marshal.Copy(rgbarray, 0, FirstPixel, bytes);
bmp.UnlockBits(bitmapData);
The code runs as intended to generate a image, but fails when the main program requires it to update several times in a quick succession, the error occurs in bmp.UnlockBits(bitmapData) with the excepion "Generic error in GDI+"
From what i gathered from my research I suppose this happens because the method runs a second time before it finished the first one, thus trying to unlock data that is already unlocked.
If that is correct then how can i abort the running thread when the new one is created? The last call is always the important one

Before starting a new call, wait for the existing call to complete. You could do that by simply using a lock region. This solves the correctness issue. Maybe it's easier to make each computation run into a Task using Task.Run. The resulting Task object is a handle to that computation and can be used to wait for it to complete.
If you want to speed up finishing an old computation run that is no longer needed, add a cancellation mechanism. Here, you could use a volatile bool cancel = false;. Set it to true to cancel. In your parallel loop (and possibly elsewhere), check that boolean variable periodically and terminate if it is found true. You can also use a CancellationTokenSource.

reduce CPU overhead while proccessing Video Stream

I am developing C# WPF Auto Number Plate Recognition Using an OCR.
The Flow is, i am getting a pictures from a video stream MJPEG and this images should be passed to the OCR to get the plate number and other details.
The problem is : the Video stream is producing about 30 Frame/second and the CPU can't handle this much of processing also it will take around 1 Sec to process 1 frame, Also when i will get many frames on the Queue the CPU will be 70% used (Intel I7 4th G).
Can anyone suggest solution and better implementation.
//This is the queue where it will hold the frames
// produced from the video streaming(video_Newfram1)
private readonly Queue<byte[]> _anpr1Produces = new Queue<byte[]>();
//I am using AForg.Video to read the MJPEG Streaming
//this event will be triggered for every frame
private void video_NewFrame1(object sender, NewFrameEventArgs eventArgs)
{
var frameDataAnpr = new Bitmap(eventArgs.Frame);
AnprCam1.Source = GetBitmapimage(frameDataAnpr);
//add current fram to the queue
_anpr1Produces.Enqueue(imgByteAnpr);
//this worker is the consumer that will
//take the frames from the queue to the OCR processing
if (!_workerAnpr1.IsBusy)
{
_workerAnpr1.RunWorkerAsync(imgByteAnpr);
}
}
//This is the consumer, it will take the frames from the queue to the OCR
private void WorkerAnpr1_DoWork(object sender, DoWorkEventArgs e)
{
while (true)
{
if (_anpr1Produces.Count <= 0) continue;
BgWorker1(_anpr1Produces.Dequeue());
}
}
//This method will process the frames that sent from the consumer
private void BgWorker1(byte[] imageByteAnpr)
{
var anpr = new cmAnpr("default");
var objgxImage = new gxImage("default");
if (imageByteAnpr != null)
{
objgxImage.LoadFromMem(imageByteAnpr, 1);
if (anpr.FindFirst(objgxImage) && anpr.GetConfidence() >= Configs.ConfidanceLevel)
{
var vehicleNumber = anpr.GetText();
var vehicleType = anpr.GetType().ToString();
if (vehicleType == "0") return;
var imagename = string.Format("{0:yyyy_MMM_dd_HHmmssfff}", currentDateTime) + "-1-" +
vehicleNumber + ".png";
//this task will run async to do the rest of the process which is saving the vehicle image, getting vehicle color, storing to the database ... etc
var tsk = ProcessVehicle("1", vehicleType, vehicleNumber, imageByteAnpr, imagename, currentDateTime, anpr, _anpr1Produces);
}
else
{
GC.Collect();
}
}
}

What you should do is this:
First, figure out if a frame is worth processing or not. If you're using a compressed video stream, you can usually quickly read the frame's compressed size. It stores the difference between the current frame and the previous one.
When it's small, not much changed (i.e: no car drove by).
That's a low-tech way to do motion detection, without even having to decode a frame, and it should be extremely fast.
That way, you can probably decide to skip 80% of the frames in a couple of milliseconds.
Once and a while you'll get frames that need processing. Make sure that you can buffer enough frames so that you can keep recording while you're doing your slow processing.
The next thing to do is find a region of interest, and focus on those first. You could do that by simply looking at areas where the color changed, or try to find rectangular shapes.
Finally, one second of processing is SLOW if you need to process 30 fps. You need to make things faster, or you'll have to build up a gigantic buffer, and hope that you'll ever catch up if it's busy on the road.
Make sure to make proper use of multiple cores if they are available, but in the end, knowing which pieces of the image are NOT relevant is the key to faster performance here.

WriteableBitmap.Lock() Performance Issue

I have an application where performance-sensitive drawings occur using a WriteableBitmap. An event is called with CompositionTarget.Rendering to actually update the back buffer of the WriteableBitmap. From the MSDN documentation, that means the event is fired once per frame, right before the control is rendered.
The issue that I am having is that the WriteableBitmap's Lock() function takes an extremely long time, especially at larger bitmap sizes. I have previously read that AddDirtyRegion() has a bug that causes the entire bitmap to invalidate, leading to poor performance. However, that doesn't seem to be the case here. From a good bit of low-level checking, it seems that Lock() opens the bitmap's backbuffer for writing on the render thread, which means every time my event handler is called, it has to thread block until the render thread is ready for it. This leads to a noticeable lag when updating the graphics of the bitmap.
I have already tried adding a timeout to the event handler, using TryLock(), so that it won't block for such a long time and cause the performance degradation. This, however, causes a similar effect in that it appears to lag, because larger numbers of bitmap updates get lumped together.
Here is the relevant code from the event handler to show what exactly I am doing. The UpdatePixels() function was written to avoid using the potentially bugged AddDirtyRect():
void updateBitmap(object sender, EventArgs e)
{
if (!form.ResizingWindow)
{
// Lock and unlock are important... Make sure to keep them outside of the loop for performance reasons.
if (canvasUpdates.Count > 0)
{
//bool locked = scaledDrawingMap.TryLock(bitmapLockDuration);
scaledDrawingMap.Lock();
//if (locked)
//{
unsafe
{
int* pixData = (int*)scaledDrawingMap.BackBuffer;
foreach (Int32Rect i in canvasUpdates)
{
// The graphics object isn't directly shown, so this isn't actually necessary. We do a sort of manual copy from the drawingMap, which acts similarly
// to a back buffer.
Int32Rect temp = GetValidDirtyRegion(i);
UpdatePixels(temp, pixData);
}
scaledDrawingMap.Unlock();
canvasUpdates.Clear();
}
//}
}
}
}
private unsafe void UpdatePixels(Int32Rect temp, int* pixData)
{
//int* pixData = (int*)scaledDrawingMap.BackBuffer;
// Directly copy the backbuffer into a new buffer, to use WritePixels().
var stride = temp.Width * scaledDrawingMap.Format.BitsPerPixel / 8;
int[] relevantPixData = new int[stride * temp.Height];
int srcIdx = 0;
int pWidth = scaledDrawingMap.PixelWidth;
int yLess = temp.Y + temp.Height;
int xLess = temp.X + temp.Width;
for (int y = temp.Y; y < yLess; y++)
{
for (int x = temp.X; x < xLess; x++)
{
relevantPixData[srcIdx++] = pixData[y * pWidth + x];
}
}
scaledDrawingMap.WritePixels(temp, relevantPixData, stride, 0);
}
I can't seem to figure out how to avoid the issue of thread blocking with the WriteableBitmap, and I can't see any obvious faults in the code I have written. Any help or pointers would be much appreciated.

Looks like you are not actually using the BackBuffer to write - only to read.
WritePixels writes to the "front" buffer and does not require a lock.
I don't know if you have some other reason to lock it (other threads doing something), but for the code that's here i don't see why you would need to.

I guess I was wrong about not needing a lock to read from BackBuffer (*pixData) - I thought it was only for writes, but I am positive you do not need to to call Lock for WritePixels.
As far as I can tell, you are doing:
Lock the back buffer
Copy something from it to an array
Call WritePixels using this new array
Unlock the back buffer.
How about switching 3 and 4?
WritePixels may internally cause rendering thread (which has higher priority on the message queue) to get a lock on its behalf which is probably a factor in the delay you are seeing.

Processing large bitmap images in WPF

I need to process (change brightness, contrast etc) very large high-quality bitmaps (often over 10MPx) several times per second and need to update it on screen every time ( on Image control in WPF). Currently I'm using AForge.NET library for unmanaged image processing, but there are some problems I cannot solve. First of all, one operation takes ~300ms (without updating the screen) which is not acceptable for me. Here's sample code:
UnmanagedImage _img;
BrightnessCorrection _brightness = new BrightnessCorrection();
void Load()
{
_img = UnmanagedImage.FromManagedImage((Bitmap)Bitmap.FromFile("image.jpg"));
}
void ChangeBrightness(int val) // this method is invoked by changing Slider value - several times per second
{
_brightness.AdjustValue = val;
_brightness.ApplyInPlace(_img); // it takes ~300ms for image 22MPx, no screen update - just change brightness "in background"
}
I have no experience in image processing, but I think it cannot be much faster since it is very high resolution. Am I right?
Another problem - how to efficiently update the screen? At the moment I have the following (ofc very bad) solution:
void ChangeBrightness(int val)
{
_brightness.AdjustValue = val;
_brightness.ApplyInPlace(_img);
using (MemoryStream ms = new MemoryStream())
{
using (Bitmap b = _img.ToManagedImage())
{
b.Save(ms, ImageFormat.Bmp);
ms.Seek(0, SeekOrigin.Begin);
var bmp = new BitmapImage();
bmp.BeginInit();
bmp.StreamSource = ms;
bmp.CacheOption = BitmapCacheOption.OnLoad;
bmp.EndInit();
MyImageControl.Source = new WriteableBitmap(bmp); // !!!
}
}
}
As you can see, every time new WriteableBitmap is created (you can imagine what is happenin). Instead of these "usings" I tried that way:
WriteableBitmapSource.Lock(); // this object (of type WriteableBitmap) is just MVVM ViewModel's property which is binded to MyImageControl.Source
WriteableBitmapSource.Source.WritePixels(new Int32Rect(0, 0, _img.Width, _img.Height), _img.ImageData, _img.Stride * _img.Height * 3, _img.Stride, 0, 0); // image's PixelFormat is 24bppRgb
... but WritePixels method throws "Value does not fall within the expected range." Any ideas why?
Any help will be much appreciated :)
P.S.
Is AForge.NET a good choice at all? Maybe there is better image processing lib?
sorry for my english ;P

~300ms for image 22MPx is about 20 ns per pixel. That should be about right.
You need to consider CPU cost and memory access cost.
If you want to improve this further, consider:
1) Use multiple threads, each responsible for a section of the bitmap.
2) Write your own implementation, using SIMD instructions.
3) Do not pre-process the bitmap, transform bitmap scanline when they're needed.