This question has been asked more than once before, but I have not found a satisfactory answer in any of those discussions.
I am launching a command-line process that produces a real-time measurement to STDOUT, producing a new result approximately every second. Using System.Diagnostics.Process.StandardOutput results in completely unacceptable lag (over 20 seconds) as the STDOUT data works through the 4k buffer in the Process.StandardOutput StreamReader, and there doesn't seem to be any way to get around this.
Calling Process.StandardOutput.BaseStream.Flush() doesn't work.
I've tried doing a byte-by-byte synchronous read of Process.StandardOutput, but I'm still 4k behind the actual output.
Can anyone at least verify for me that it is possible to somehow overcome all of the buffering issues I am having with redirecting STDOUT, and receive the data in my application as soon as it would have appeared in the shell window? Can I inherit from the Process class and change how the StandardOutput streamreader behaves? Do I need to be looking at raw WINAPI calls?
Somehow, this has to get done, even if I end up writing unmanaged C++ to launch the task and consume the output, and linking that in. Any help is much appreciated; I'm at my wit's end...
Edit: It appears that what I need is a .Net implementation of the "expect" libraries that are available for C/C++, Perl, Python, and Java (those are the only ones I have found so far). Does anyone know if such a beast exists?
"[I]s there a way to launch it such [that] it doesn't realize it is being redirected?" YES: that is exactly the domain of Expect. I know of no .Net implementation; it's surely feasible, though ...
Related
I have two applications, the main-app is written in ML4 (a programming language which compiles to machine language; I do not know much about this technology), the tool-app is written in C#.NET.
The main-app calls the .NET assembly via COM, invokes a delegate which does some work, shows a window, etc. So far it works pretty acceptable.
In the .NET app, I seem to have a pretty strict thread-limit. The complete application can have around 18 threads. Starting another one results in a OutOfMemoryException in Thread.StartInternal without any further information.
The question is obviously: why? Both apps run in the process of the ML4-app, but I never heard of such a thread-limit. Does maybe the COM-Interface cause it?
Or can a process be configured to have such limitation?
Typically, I wouldn't post such a question here, since it reads like a no-effort-question. The problem is, I have a very limited knowledge about processes and threads in the operating system, so I cannot really tell what possible causes could be.
I have a Windows Store app with an option to export certain data in a video file format. My app is in C#, but the encoding itself is handled by dropping into a C++ library adapted from this sample by David Catuhe and is working well. The problem is that I have found is that the encoding process can take a long time when run at high quality, and if the screen times out (say, on a Surface RT) or the user switches apps, the process fails. I'm not entirely sure what the source of the failure is and am working to verify it, but even if the process were able to survive suspension without changes, I don't know how to handle being tombstoned.
I can live with the encoding being interrupted in certain situations. What I don't want is to have to start over from scratch if the app goes away for some reason.
As far as I can tell, it isn't feasible to simply close the stream without finalizing the video and resume writing to it later. In light of this, I have considered a few options, but I can't tell which, if any, might actually work. I'd be very grateful for some direction.
1) If possible, it'd be great to be able to simply close the stream and reopen it later, picking up where I left off. At the moment I haven't been able to get this to work, but if it SHOULD work I'd love to know.
2) Push the encode process to a background task, either from the start or only when tombstoned. But is there a way to pass an open stream from my app to a background task? If not, is there a way to get my app's background task to run without CPU/memory limitations at least while my app is in the foreground? Because doing a whole encode within the very tight constraints that normally bind background tasks would take years.
3) Render segments of the video progressively while the app is in the foreground and then stitch the parts together at the end. This way, if the encode is interrupted I can pick up at the most recent segment. From my reading this should be possible in theory (I think it falls under the category of remuxing, which would avoid the need to re-encode the video). But I haven't found any samples that cover this scenario, not even in C++ (which I have almost no experience with). The Transcode API doesn't seem to cover joining multiple samples. I've looked into using SharpDX to do it, but the most likely candidate for what I'd want to use (a Media Session) is only exposed for desktop apps.
4) Push the work off to either a desktop or server app. The problem is I want to have this run on Windows RT (so desktop is out) and I don't currently have a business model that can support servers capable of handling such intensive work on my customers' behalf.
So my question is, what is my best line of attack here? Is there any way to hold onto my stream across suspension? And if, as I suspect, option #3 is my best bet, do you know of any samples or guides on how to do it? Obviously C# options would be very much preferred, so I hope I am overlooking one. C++ might be OK (as it was with Mr. Catuhe's sample that got me this far), but I'm afraid I'd need some pretty specific guidance. The MSDN documentation on this, incidentally, is so high-level that I have only a vague idea of even which pieces I would need to assemble and what each requires, let alone how to write the actual program in C++.
Any help you could offer would be very much appreciated.
Unfortunately I don't have enough reputation points on SO to just comment so I have to give this as an answer.
You could consider a combination of #3 and #4. Render in segments within your app and then upload the segments for stitching together. This would bring you back into the realms of using a commodity solution to create your final output.
I am trying to output audio samples, and do so with cswavplay from http://www.codeproject.com/KB/audio-video/cswavplay.aspx which in turn seem to use DllImports from winmm.dll.
I did get it to play using 8-bit samples, however it fails miserably when I try to feed it 16-bit samples. I dug through the code as best as I can and I understand it as this:
I get a pointer to a buffer to fill each time cswavplay finished playing the last buffer. It works for one iteration, it plays back one buffer, sometimes...
I get all sorts of funny exceptions, AccessViolationException just now for instance when I tried to use a buffer size of 44100 to hear more clearly how much gets played. But when I put breakpoints in various places inside the WaveOut class (part of cswavplay) it seems none of the objects it uses, like the buffers and an instance of AutoResetEvent, are still alive the second iteration. My best guess is that these problems are related to threading or GC. The exceptions seem pretty random, and I am far too inexperienced to comprehend fully what's going on.
I'm asking for either of the following:
1) Wild guesses as to what could be the problem
2) Educated guesses as to what could be the problem
3) Pointers to an alternative way of outputting sound in realtime using C#
I'm not asking for a thorough bug tracking of software i didn't write, so don't mind cswavplay...
At the end of the day, i might be doing something wrong here, but it's hard to know when i don't get a relevant exception (along the lines of BufferAllocationException or something)...
EDIT:
Thanks for all the suggestions about other sound API's. They all seem to assume a .wav file. I'm sorry for not being clear, i'm not playing .wav files, i synthesize samples in realtime.
DirectSound and for .NET the XNA framework comes to my mind. There are many very high quality samples out there how to play sound and animate graphics at the same time with .NET.
I have the following card and cannot get interupts working. I may not be understanding how they're supposed to work correctly... I don't do this type of programming very often.
From the looks of it though, it should be able to generate an interrupt when something comes in on one of the IO ports, right? We've got it hooked up to a bunch of switches for machine operation.
http://accesio.com/go.cgi?p=../pci/pci_dio_24d.html
I'll post some of the code I'm working with as soon as I can. I'm trying to write something to the base address (which I have) + 0xE but that doesn't help... the AIOWDM WaitForIRQ method just returns with a 0 every time I call it... nothing happens.
Any help would be appreciated... I know this is kind of a generic question.
UPDATE: Even the sample application they provide doesn't detect any interrupts, and I know I have the jumpers installed correctly, so I'm guessing it doesn't just fire interrupts for everything... I'm guessing I have to wire each switch up to a certain IO pin too and that one pin is responsible for the interrupts...
In short, C# is not an appropriate language for this kind of task, as this is low-level unmanaged code. You could theoretically do it, but it would be more painful as you have to make frequent trips to the unmanaged world to deal with interrupts. I would advise to look at this from the likes of C/C++ native code which would perform better and handle this kind of low-level stuff.
Another reason why, since C# has their own garbage collection, the last thing you would want is for the interrupt handling mechanism to be disposed of in the garbage collection a la good bye to the precious data structure used for interrupt handling, this will add considerable overhead to the code in this regard.
Personally, I have never heard of C# dealing with this kind of thing, but some of the more astute readers will say, "hang on, what about the new fangled OS called Singularity, which is written in C#?", at the end of the day, using the .NET runtime to manage this hardware task is a no-no.
Edit:
After I realized, from looking at the reference manual, on one of the C code samples it is using outp, then I latched on the idea that you need to do direct port input output, I thought this might help, it is a dll that will enable you to do exactly that, input output, you would need to find the appropriate p/invoke signature to do this. There is another DLL that can do the same thing here. Also, check this WinRing0 code.
Again, you need to dig around and find the appropriate method signature suitable for pinvoking...
Best of luck with this..feel free to post any more and I'll try help out... :)
Hope this helps,
Best regards,
Tom.
I was looking around for a tool to monitor the status of my software raid under Windows 2003 Server, but couldn't find anything suitable (i.e. not grossly oversized or needlessly complicated). So I decided to just do it myself, it's nothing spectacularly difficult.
So how can I retrieve the status of the volumes programmatically? It's been a while since I fiddled with the Windows API and I couldn't find anything right off the bat using Google. I know I can use diskpart /s and parse its output, but that gets messy fairly quickly (although it does have some advantages).
Any pointers into the right direction are highly appreciated :)
The Win32 API is the (apparently only) way to go here, Virtual Disk Service is the magic word.
Here is a good example in C++ that will get you started. The number of different COM interfaces was pretty confusing for me at first, but the How Virtual Disk Service Works article was of great help getting the big picture.
It's actually pretty easy. Despite never having done any serious C++ coding and never having even touched COM before, I was still able to get the basic functionality to work in a few hours.
Did you check WMI?
You can take a look here for a demo.
You could try monitoring the Event log for RAID events.
I don't know if RAID stuff will complicate matters, but I've used System.IO.DriveInfo.GetDrives() before and that's worked fine for my needs.