I won't give a definite answer, but here are my thoughts on this.
Firstly, while C# and VB.Net perform practically the same, there is much more code available for C#, so I would recommend learning it. It's not hard if you already have a C++ background.
Secondly, C# (or VB.Net for that matter) might be fine for what you're doing. The performance of C# is often underrated. Parallels are drawn to Java, believing they both run in a virtual machine, but C# is in fact compiled into native code at runtime, which is fundamentally faster. It is often even comparable to C/C++ in some cases. However, signal processing might indeed be a weak spot for C#. If you have time to try it out and do some tests, then I'd recommend doing so.
A pretty good solution is to create two assemblies. The main executable written in C# and another .dll in C++/CLI that does the performance-critical stuff. So you get the convenience of .Net with the power of native C++ and also the chance to do custom optimizations in x86 assembly. This is probably your best bet as well. Note that IntelliSense as well as WinForms support was dropped for VC++ in VS 2010, so it's definitely easier to write most .Net stuff in C#.
The C++/CLI assembly can also be linked to other native static or dynamic libraries. Native dynamic libraries (.dlls) can be called directly from C# using P/Invoke
(platform invoke), but that's somewhat slower and less convenient.
Microsoft discontinued Java because of legal issues
, but I see no reason for MS to drop C#/VB.Net, because these languages have become a major selling point for them. Actually, C++/CLI is less of a priority, which is why IntelliSense for C++/CLI was dropped, but it's still the best way to do interop with native code. Microsoft's policy is probably to enforce C# as the main language for .Net development, VB.Net as an easy starting point for beginners and to keep C++/CLI for the native stuff.
I'm not a big fan of QT or GTK+, since they're kind of bloatware. They're fine for cross-platform development though.