I am using visual basic .NET and I want to play a video from a byte array that I have, but without saving it first at the disk. Directly from that array. I tried the directshow lib for a while but didn't managed to find a way to play it. WMP didn't worked either.
Any ideas?
There is no stock component to stream from memory, however the task has more or less good generic solution. A number of files/formats are playable starting from so called File Source (Async) Filter, which is a generic file/data accessor. If you could provide a similar/compatible source filter which streams from memory, it would wokd great and cover a number of formats at a time.
Provided that you are going to have hard time doing it in VB.NET, and in managed code in general, you will perhaps need a third party solution for this. So you might eventually end up with a much easier workaround to save data into temporary file and play it from there.
Related
I have an Objective-C application that I'm trying to add a means to record output generated by the application to disk. I've added a Swift bridge to my app and have currently got the epic-looking AudioKit Framework hooked-up.
How might I capture my application's audio output and dump it to disk?
Solutions using AudioKit would be nice, but really anything Swift or Objective-C works.
Ideally, I'd mix different input sources (My app's output, plus default the default system input channel), but whatever.
I'm not convinced this is actually possible in AudioKit. I've searched for hours on this. A while ago, I did have a bit of Objective-C code that did manage to record to disk, but it was kind of laggy and seemed to only record the last few seconds before I closed the recording session.
I started to check the way how I can use NAudio to play sounds using different Output devices.
Now I would like to use NAudio for the following use case:
I would like to play a ringback when a call arrives on a soft phone. The ringback audio (wav file of 3-5 sec) should be played repeatedly until the call is accepted or the caller hangs-up the call.
I found now two ways of doing it:
Following entry explains how this could be solved by playing a file in a loop:
NAudio looping an audio file
Another entry explains how to work this out by using a timer to play the file repeatedly:
NAudio - Play an audiofile, wait for 2 seconds, play the audio file again
The question is which way is the better one to go for? So does it make sense to start the playback often for a quite short-time?
Another question which arise is if there is way to make sure that in the looping case the playback is rellay stopped as it does not make sense to have the ringback played from the loudspeaker although the person is talking already to the caller.
Thank you very much for your support!
Uzay
I'd recommend using the looping solution in this scenario. It avoids the need to keep closing and opening the soundcard. Stopping works exactly the same whether you are looping or not.
I'm becoming mad trying to figure out how to resolve this task. My goal is pretty easy, copy a file on the USB stick every time that it is inserted and then release the USB stick turning off the LED. What is the best way to solve it?
1) I found this article
http://geekswithblogs.net/BruceEitman/archive/2008/06/13/windows-ce-monitoring-for-disk-insertion-to-add-support-for.aspx
or
http://geekswithblogs.net/BruceEitman/archive/2008/06/13/windows-ce-monitoring-for-disk-insertion-to-add-support-for.aspx
but I can't translate it on VB.NET project.
2) Then I read that is enough to use RequestDeviceNotifications for block devices. But How can I do that in VB.NET?
I would like to avoid OpenNetCF if possible.
Thank you
Since you don't want to "use OpenNETCF" I assume that you don't want to use any libraries or capabilities not built in to the CF. We'll skip the argument of that silliness and the "value of your time" discussion and take that as a requirement.
What you need to do is:
Use P/Invoke to call CreateMsgQueue. That's going to give you back a Handle. You'll probably want to do CloseMsgQueue as well for completeness
P/Invoke RequestDeviceNotifications and pass it the handle returned from #1 above along with the DEVCLASS GUID value for the device notifications you want - probably STORE_MOUNT_GUID. Again, adding StopDeviceNotifications for completeness is a good idea.
At that point you'll get a message on the queue whenever a insert or remove happens. You then call ReadMsgQueue to get the DEVDETAIL data in the message.
Parse the DEVDETAIL and look at the fAttached member.
It'd take me a while to write that for you, so you'll need to do this on your own.
Start writing the project, find P/Invoke routines for the calls you need (like FindFirstFile and CreateProcess). On SO, have a look at Storage Card Problem In windows mobile and How to register form for WM_DEVICECHANGE message in windows mobile.
You are only going to be dead in the water if you can not find a particular call that you can't make.
As you work through your project, post (or search for) the actual problems you run into.
Otherwise, it sounds like you are asking someone to write the project and hand it to you.
I am reading a file datafile at the launch of my application.This is just self learning drill.
On apple developers website under the heading Minimize File Access at Launch Time
it says
If you must read a file at launch time, do so only once.
So my question is that is there a standard or preferred way of doing this. At the moment I have an instance varible NSArray and I populate that in - (void)viewDidUnloadand never garbage collect it. Is that good enough ? or Should I be making use of application Object (I am not even sure if it is logical to say this.).
There is no standard way to optimize. But there are some guidelines.
One basic idea of optimization is to do less. E.g. as the advice you cited where the data of a file may be needed at multiple points in your code, it is better to read it from disk once and then distribute a data pointer within your program.
If the file is big enough to cause a stutter when you start your application, i.e. it takes more than 20ms to read and parse the file, you should consider reading the file in a background thread/task and adding a ‘loading…’-state to display to the user.
Would it be possible to take the source code from a SNES emulator (or any other game system emulator for that matter) and a game ROM for the system, and somehow create a single self-contained executable that lets you play that particular ROM without needing either the individual rom or the emulator itself to play? Would it be difficult, assuming you've already got the rom and the emulator source code to work with?
It shouldn't be too difficult if you have the emulator source code. You can use a method that is often used to store images in c source files.
Basically, what you need to do is create a char * variable in a header file, and store the contents of the rom file in that variable. You may want to write a script to automate this for you.
Then, you will need to alter the source code so that instead of reading the rom in from a file, it uses the in memory version of the rom, stored in your variable and included from your header file.
It may require a little bit of work if you need to emulate file pointers and such, or you may be lucky and find that the rom loading function just loads the whole file in at once. In this case it would probably be as simple as replacing the file load function with a function to return your pointer.
However, be careful for licensing issues. If the emulator is licensed under the GPL, you may not be legally allowed to store a proprietary file in the executable, so it would be worth checking that, especially before you release / distribute it (if you plan to do so).
Yes, more than possible, been done many times. Google: static binary translation. Graham Toal has a good howto paper on the subject, should show up early in the hits. There may be some code out there I may have left some code out there.
Completely removing the rom may be a bit more work than you think, but not using an emulator, definitely possible. Actually, both requirements are possible and you may be surprised how many of the handheld console games or set top box games are translated and not emulated. Esp platforms like those from Nintendo where there isnt enough processing power to emulate in real time.
You need a good emulator as a reference and/or write your own emulator as a reference. Then you need to write a disassembler, then you have that disassembler generate C code (please dont try to translate directly to another target, I made that mistake once, C is portable and the compilers will take care of a lot of dead code elimination for you). So an instruction of a make believe instruction set might be:
add r0,r0,#2
And that may translate into:
//add r0,r0,#2
r0=r0+2;
do_zflag(r0);
do_nflag(r0);
It looks like the SNES is related to the 6502 which is what Asteroids used, which is the translation I have been working on off and on for a while now as a hobby. The emulator you are using is probably written and tuned for runtime performance and may be difficult at best to use as a reference and to check in lock step with the translated code. The 6502 is nice because compared to say the z80 there really are not that many instructions. As with any variable word length instruction set the disassembler is your first big hurdle. Do not think linearly, think execution order, think like an emulator, you cannot linearly translate instructions from zero to N or N down to zero. You have to follow all the possible execution paths, marking bytes in the rom as being the first byte of an instruction, and not the first byte of an instruction. Some bytes you can decode as data and if you choose mark those, otherwise assume all other bytes are data or fill. Figuring out what to do with this data to get rid of the rom is the problem with getting rid of the rom. Some code addresses data directly others use register indirect meaning at translation time you have no idea where that data is or how much of it there is. Once you have marked all the starting bytes for instructions then it is a trivial task to walk the rom from zero to N disassembling and or translating.
Good luck, enjoy, it is well worth the experience.