xxxxx@gmail.com wrote:
The device does not give any video. If the device is enumerated as a multifunction device, i.e hid+audio then is the driver has to be developed by the hardware vendor suiting to his requirement correct?
Not necessarily. A device that says it is a USB HID device will
automatically use the Microsoft USB HID driver. You don’t have to write
one. Similarly, if the audio function is designed to meet the USB audio
class, then again the Microsoft USBAudio driver will handle it
automatically. No driver work is needed.
Coming to the application part, will that still be a custom application? or we can use a directsound application as the driver still has the audio function also in it?
The key point here is that YOU know your product. YOU need to sit down
with your development team and your marketing team, and decide how the
product should be used. If you want your clients to think of the data
as an audio stream, and use standard audio APIs to access it, then you
should make it an audio class device. But if you want to have complete
control over every byte, so that you provide a custom API of your own
design, supported by your own DLLs, then there is no need to make it a
standard class at all. You can write a simple KMDF or UMDF driver to
ship the data around.
If it is a custom application, then we have to enumerate the interfaces for both the functions by their GUIDs and then use hid specific functions(set and get reports) for HID and setupdi,read/write for the audio part. In the audio function, generally, what is the format of the audio generated by these ultrasound devices? pcm?
This is your decision. I don’t think there is any standard for this.
What will your users want?
If its audio only, then we have to use directsound application. Correct?
DirectSound, DirectShow, or the waveIn APIs. There are many ways to get
to an audio device.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.