I've got a few video converter boxes (Marshall VAC-11SU3, Marshall VAC-11HU3, Magewell USB Capture SDI, Blackmagic UltraStudio Express) and no cameras.
They all have an incoming video signal plugged into their respective SDI or HDMI ports.
The issue is that GetNativeMediaType always returns the same format as GetMediaTypeByIndex does for index 0 regardless of the actual video format that is coming into the SDI/HDMI port.
Every Media Foundation example I've seen so far has a UI to pick the "correct" native format. This menu is populated from GetMediaTypeCount and GetMediaTypeByIndex for the device.
My users will not know what to pick!
We've been using Blackmagic's DeckLink APIs and our users see the incoming video signal format in the UI.
We'd like to expand support for multiple device manufacturers but this one has me stumped.
Media Foundation does not employ a concept of signal format detection you have with recent Blackmagic hardware (earlier Blackmagic products, by the way, did not offer detection).
A video source driver could indeed enumerate the media type it sees on the wire as first GetNativeMediaType output and/or offer dynamic format change during streaming session to such format. Media Foundation video sources are mostly assuming however webcamera-like devices and have a fixed type enumeration order.
I would not assume Blackmagic driver to be different because it mostly mimics a webcamera, so that with a WDM driver Blackmagic device inputs could be consumed using standard APIs. If one needs extended functionality, such as signal detection, Blackmagic suggests using their DeckLink SDK (which is good by the way).
Related
I need a software or application with API support to capture USB packet and data buffer. I would like to analyse the captured data using LabVIEW.
Suggest applications for usb packet and data capture with API support, so that I can access them using LabVIEW.
Or
Alternate methods to capture and analyse usb data using LabVIEW
I had tried a approach using logman.exe . But that doesn't log all the USB packets. Has anyone tried logman to capture the usb packets?
you can consider using VISA functions.
A few examples are shipped with Labview (open example finder and look for USB).
Here is a starting point giving instructions about how to give VISA access to the device.
You need find out some windows dll's and use it in labview. the examples provided for NI USB devices.
I am working on a product with an LPC1788 which needs the following USB features:
Firmware download (from host PC to device, not through a USB
key).
File upload (from device to host).
Ideally we'd also be able to get some information from the device like serial number etc.
The device should only work with a custom Windows application, so simply using a mass-storage device as-is will not do. There are quite a lot of data to upload (200MB +), so using USB bulk transfers seem necessary to me.
What is the best way to approach this? I imagine I would need to create some sort of USB composite device(?). However, I was hoping to use nxpUSBlib or winUSB so I don't have to go through the Windows driver validation process.... What are my options? Perhaps there some way to make the mass-storage device invisible for Windows?
Thanks!
Dirk
I think you'll definitely want to go with a vendor specific bulk device and you can easily use WinUSB for all of this. This should be sufficient for everything you've specified here.
For your firmware loader I'd recommend looking at the DFU (device firmware update) specification. You'll probably want make some command for your device that when sent will cause it to reenumerate itself in to DFU mode for update (rather than a composite device that is always exposed - this restricts the issue of the other interface being in use while you're flashing your device). Then you can flash it and reset it so it will reenumerate as your vendor specific bulk device again.
I wouldn't recommend mucking with mass storage, from your requirements it will be better to implement your own protocol and create some application or DLL that consumes the WinUSB API to communicate with your device, including the firmware update.
I successfully use WasapiLoopbackCapture() for recording audio played on system, but I'm looking for a way to record what the user would actually hear through the speakers.
I'll explain: If a certain application plays music, WASAPI Loopback shall intercept music samples, even if Windows main volume-control is set to 0, meaning: even if no sound is actually heard through audio-card's output-jack (speakers/headphone/etc).
I'd like to intercept the audio actually "reaching" the output-jack (after ALL mixers on the audio-path have "done their job").
Is this possible using NAudio (or other infrastructure)?
A code-sample or a link to a such could come in handy.
Thanks much.
No, this is not directly possible. The loopback capture provided by WASAPI is the stream of data being sent to the audio hardware. It is the hardware that controls the actual output sound, and this is where the volume level is applied to change the output signal strength. Apart from some hardware- and driver-specific options - or some interesting hardware solutions like loopback cables or external ADC - there is no direct method to get the true output data.
One option is to get the volume level from the mixer and apply it as a scaling factor on any data you receive from the loopback stream. This is not a perfect solution, but possibly the best you can do without specific hardware support.
I am pretty new to Naudio, trying to understand it,
I require the following to be done in my application
I have couple of devices connected to my system
say
1) head set - with a mic
2) inbuilt system mic and speakers
I require to do the following
the audio from the two input devices(headset mic and system mic) should be mixed and a byte array needs to be constructed. how can this be done using naudio
Also, the system speakers and headset would receive a stream that needs to played on both
any concept ? or classes that i can use ?
That depends on the type of headset:
If the headset plugs into the sound-card's audio jacks (with a pair of 3.5mm plugs for instance) then you can't target the headset's speakers and microphones as distinct from the system's speakers and microphone. They are indistinguishable, except in very rare configurations.
If the headset is connected via USB then you can use the device enumeration options to select the device to attach to. In this case you might be able to independently address the different microphones and speakers... try it out and see.
In a Windows 8 Store App I would like to read Data from a SmartCard. After installing the SmartCard reader (USB Device) I can read its device path and connection state via the Windows.Devices.Enumeration namespace. Even the device interface id is retrievable (50dd5230-ba8a-11d1-bf5d-0000f805f530) and I put this as a required capability in the App's manifest file.
For the interaction with the device I use a C++ Component calling the CreateDeviceAccessInstance Method. But this call always results in an ACCESS_DENIED exception.
Further research taught me, that interacting with a custom hardware device (everything that is not a printer, microphone, mouse, ...) would need several adjustments in the device driver published to the windows 8 driver store.
I'd be glad to do so, but I am no IHV and would like to use the generic driver and the generic interface.
Could anyone give me a hint how to proceed from here and use the generic interface for USB SmartCard devices?
This is not a real answer, but I have the same problem and I have spent quite some time looking for the hard-to-find bits of information on this subject around the internet, and I'd like to share my results.
Windows 8.1 has some specific APIs for (virtual) SmartCards (API reference, sample), but it seems like they can only be used for authentication and there is no way to send APDU commands to a card at the moment (see this comment by Himanshu Soni). I guess one could use the new USB APIs to talk to the reader directly, but then you'd have to implement the whole protocol yourself.