How to write simpliest audio virtual device driver in WinXP? I know that one way is to write a WDM driver but I suppose it is not an easyly task. I need to implement some audio filtering for a Flash based application. Unfortunatelly it seems that it is the only way to do it - outside a Flash, by a device driver, then a Flash app can attach to my virtual device.
I was wondering if I can write a device driver using some high level API (higher that WDM), maybe UMDF as virtual usb audio device(?) or maybe only some dll which will register a virtual device. As I can see Google Talk plugin contain googleadapter.dll which provfides virtual webcams, I wonder how they wrote it.
Thanks in advance,
ternyk
For WinXP it is enough to write Installable Driver which is a simple user-mode dll. However it will not work under Vista or higher because they have different audio model.
What API? First thing i'd worry about is learning how the app(s) interface with Windows and the best way to do this is to actually learn how to code an application with audio using the same interface. So, if it uses DirectSound audio, learn how to code an application which uses DirectSound.
The reason i say this is that once you know how your code works you will also know what API need to be hooked. Then it goes from there, code the loader/dll injector so that it performs what you're after.
Finally, don't forget to use Google to do as much research on your own first:
[quote]Give a man a fish, he'll eat for a day... Teach a man to fish and he'll never go hungry again...[/quote]
Related
Working on an appliance and would like to support zero configuration feature. That way users can look for the device on the network and simply double click an icon to access the web interface without having to configure it or know its ip address.
Tried to use UPNPLib_TLB but functions seem to be read-only; am I right? I can create a device using CoUPnPDevice.Create but can't set a FriendlyName or a URL.
Tried to use Deltics Bonjour service but it crashes on create (ACCESS_VIOLATION). The demo code uses a custom test unit which complicates experimentation.
After much research it does not look like there is a component available for this and would appreciate some pointers. Has anyone successfully created a zeroconf broadcast either via UPnP or Bonjour with Delphi XE2/5.. I can go back to Delphi 7 if required. Target = Windows 7.
NOTE: To be clear, I can find existing devices on the network and don't want to enumerate existing devices but what I want is to broadcast my service so that my box behaves like a network printer for example. The only service I need to expose is the URL so that users can access an embedded web server.
Appreciate the help!
EDIT
With the tips provided I did some research and getting this done the RAD way is not possible.
Using MS APIs directly is time consuming and requires a level of understanding of C that I don't have. Porting the Delphi 5/Indy 7 component to XE2/5 will require a good amount of work and debugging.
I discovered UPnP developer tools from Intel now open source here: Developer Tools for UPnP. This tools makes it really simply to create a server in 10-15 lines of code. Intel provides a DLL that I can call from VS Express as follows and it works great:
device = UPnPDevice.CreateRootDevice();
device.FriendlyName = 'My name';
device.PresentationURL = 'URLToEmbeddedServer";
..
I tried to use headconv7 tool to convert the .h file Intel's UPNP.DLL to a pascal file and call the external functions within the DLL directly from Delphi but there were too many problems with the conversion.
It's too bad because the Intel library makes it really simple to create UPnP stacks and the approach would apply itself very well to a component but for now its quicker to use .NET and VS Express to get the job done.
When using UPNPLib_TLB, you are not supposed to create a UPnPDevice object directly. UPnpDevice describes a known device on the network, which is why its properties are read-only.
Read the documentation:
Control Point API
Finding Devices
You are supposed to create an instance of the UPnPDeviceFinder class instead. Its search methods will give you a UPnDevice object for each device that is found.
I'm writing LabVIEW software that grabs images from an IMAQ compatible GigE camera.
The problem: This is a collaborative project, so I only have intermittent access to the actual camera.I'd like to be able to keep developing this software even when the camera isn't present.
Is there a simple/fast way to create a virtual or dummy IMAQ camera in software? Ideally I'd like the dummy camera grab frames from an AVI or a stack of JPEG's. Something like this must exist, I just can't find it on Google.
I'm looking for something that won't take very long (e.g.< 2 hours effort) and that is abstracted away through the standard LabVIEW IMAQ interface, so that my software won't know or care whether its dealing with a dummy camera or an actual camera.
You can try this method using LabVIEW classes:
Hardware Emulation Using LabVIEW Classes
If you have the IMAQdx driver, you might consider just buying a cheap USB webcam for $10.
Use the IMAQdx driver (assuming you have it), and then insert the Vision Acquisition Express VI, and you can choose AVIs or even pics as a source.
Something like this: GigESim is a camera emulation software. Unfortunately it is proprietary and too expensive (>$500) for my own needs, but perhaps others will find this link useful.
Anyone know of a viable Open Source alternative?
There's an IP Camera emulator project that emulates IP camera with python. I haven't used it myself so i don't know if it can be used by IMAQ.
Let us know if it's good for you.
I know this question is really old, but hopefully this answer helps someone out.
IMAQdx also works with Windows DirectShow devices. While normally these are actual physical capture devices (think USB Webcams), there is no necessity that they have to be.
There are a few different pre-made options available on the web. I found using Open Broadcaster Studio and this Virtual Cam plugin to be easy enough. Basically:
Download and install both.
Load your media sources in the sources list.
Enable the VirtualCam stream (Tools > VirtualCam). Press Start.
I want to play a recorded movie as my webcam? How can i do this , i am a Delphi programmer it's necessary to write a device driver ?
I am waiting for ideas on getting this task done.Thank you!
You'll want to take a look at the Windows Image Acquisition service. At first glance it looks like you're correct. You will probably have to write a user mode driver to do this. Once this is accomplished you should be able to stream your movie through any software that takes advantage of a webcam.
If you want the movie to be accessible to webcam-related APIs and OS features, then yes, you would need to write (or find a thirdp-party) device driver that is usable by multimedia APIs.
Is it possible to get location data out of Google Gears, Google Gelocation API or any other web location API (such as Fire Eagle) in such a format that it appears to other software as a GPS device?
It occured to me reading these answers to my question regarding WiFi location finding, on Super User, that if I could emulate a GPS unit, many of these web services could act as a 'poor-mans' GPS to otherwise less useful software that requires it.
Is GPSD an option?
Preferably OSX & Python, but I would be interested in any implementation.
There is a very similar thread on a Python mailinglist that mentions Windows virtual COM ports and discusses Unix's pseudo-tty capabilities. If the app(s) you want to use let you type in a specific tty device file, this may be the easiest route. (Short of asking the authors to provide a plugin API for what you're trying to do, or buying yourself a $20 bluetooth GPS mouse.)
Are you using OS X?
There is a project macosxvirtualserialport on Google code that provides a graphical wrapper around some of the features of a utility called socat. I'd recommend taking a look at socat if you see potential in the pseudo-tty route. I believe you could use socat to link a pipe from a Python program to a pseudo-tty.
Most native Mac apps will be querying IOServiceMatching for a device with kIOSerialBSDRS232Type, and I doubt that a pseudo-tty will show up as an IOKit service.
In this case, unless you can find a project that has already implemented such a thing, you will need to implement a driver as described in this How to create virtual COM port thread. If you're going to the trouble of create a device driver, you would want to base it on IOKit because of that likely IOServiceMatching query. You can find the Apple16X50Serial project mentioned in that post at the top of Apple's open source code list (go to the main page and pick an older OS release if you want to target something pre-10.6).
If your app is most useful with realtime data (e.g. the RouteBuddy app mentioned in the Python mailinglist thread can log current positions) then you will want to fetch updates from your web sources (hopefully they support long-polling) and convert them to basic NMEA RMC sentences. You do not want to do this from inside your driver code. Instead, divide your work up into kernel-land and user-land pieces that can communicate, and put as little of the code as possible into the kernel part.
If you want to let apps both read and write to these web services, your best bet would probably be to simulate a Garmin device. Garmin has more-or-less documented their protocol in the IntfSpec.pdf file included with their Device Interface SDK. Again, you'd want to split as much as you could into user-space code.
I was unable to find a project or utility that implements the kernel side of an IOKit-based virtual serial interface, but I'd be surprised if there wasn't one hiding somewhere out there. Unfortunately, most of the answers I found to that question were like this, with the developer being told to get busy writing a kext.
I'm not exactly sure how to accomplish what you're asking, but I may be able to lend some insight as to how you might begin to get it done. So here goes:
A GPS device shows up to most systems as nothing more than a serial device -- a.k.a. a COM port if you're dealing with Windows, /dev/ttySx if you're in *nix. By definition, a serial port's specific duty is to stream data across a bus, one block at a time. So, it would then follow logically that if you want to emulate the presence of a GPS device, you should gather the data you're consuming and put it into a stream that somehow acts like an active serial port.
There are, however, some complications you might want to consider:
Most GPS devices don't just send out location data; there's also information on satellite locations, fix quality, bearing, and so on. Then again, nobody's made any rules saying you have to make all that data available. There's probably more to this, but I'll admit that I need to do more research in this area myself.
I'm not sure how fast you can receive data when dealing with Google Latitude, etc., but any delays in receiving would definitely result in visible pauses in your "serial port"'s data stream. Again, this may not be as big a complication as it seems, because GPS devices are known to "burst" data across the bus anyway, but I'd definitely keep an eye on that. You want to make sure there's always a surplus of data coming across, not a shortage.
Along the way you'll also have to transform the coordinates you receive into valid GPS sentences, as well. You can find specifications for those, but I would definitely make friends with the NMEA standard -- even though it is a flawed standard, it's the one everyone seems to agree on anyway.
Hope this helped you, at least a little bit. Are there anymore details specific to your problem that you think could be useful in answering this question?
Take a look to Franson GPS Gate which allows you to connect to Google Earth among other things (like simulating GPS and so on). Is windows only though but I think you could get some useful ideas from it.
I haven't looked into it very much, but have you considered using Skyhook's SDK? It might provide you with some of what you are looking for. It's available for every major desktop and mobile OS.
We have a range of PC demonstration programs for our microcontroller products. The programs typically connect to a USB HID chip on the microcontroller board. The USB chip acts as a communications bridge, allowing the programs to communicate with the micros over SPI/I2C/UART. The programs can configure the micros, and get back status information to display to the user.
We are now looking to build some standalone demonstrations using single board PCs. We would like to reuse as much as possible of our existing demo app source code. Ideally, we could just run them as-is.
Does anybody have any advice on the best way forward? The basic options seem to be WinCE or XP Embedded boards. WinCE boards seem to pull less power, which would be an advantage from a battery life point of view.
Our existing demos are built either in C++ under Borland Builder, or in Delphi.
Thanks in advance.
EDIT: see my answer below with info from a board vendor.
Free Pascal/Lazarus can compile some forms of Delphi apps to WiNCE/arm. Even visual ones.
There isn't a Delphi version for WinCE, so you would need to rewrite the applications. The same applies for the Borland Builder's control libraries. Only if you have used plain Win32 API, you would be able to port your application to WinCE easily. You may also encounter problems with the hardware access part. The Serial Port driver may not work as is. Also, you need to find a WinCE board that can act as USB host and provides HID drivers (this isn't very common).
In conclusion, I believe that you would be better of with Windows XP Embedded boards. These should run your applications as they are.
As an update, and for future reference, I thought I'd post the results of our discussions with a WinCE board vendor here. Caveat: I haven't actually tried any of this.
The bottom line is that there isn't a straightforward way to do what we were hoping for (i.e., re-compile our existing demo applications to run under WinCE). The reason is that the generic HID drivers and standard APIs that exist in desktop flavours of Windows just aren't there in WinCE.
To talk to HID devices in WinCE you need to implement a custom HID driver. This needs to support an interface allowing user mode applications to communicate with the driver, and to construct HID reports to be sent to the physical device. As this interface would itself be custom, application code needs to be updated accordingly.
WinCE application development is generally done using Visual Studio and the Microsoft compilers. The approach recommended to us was:
Create a custom HID class driver. This could be based on, for instance, the Microsoft keyboard HID driver.
Create an API for talking to the driver.
Use .net to create our GUI applications, and use PInvoke to actually talk to the API.
The end result of all this head-scratching is that to avoid the time and learning curve associated with this approach, we're going to go for a board running XP. We can then use our existing demo applications straight out of box. The trade-off is that we'll have to live with substantially reduced battery life.