Which Class's device is u.s.b 'Ultrasound Device'(used for medical diagnostics)?

Hi all,

To which class does the U.S.B Ultrasound Devices used for medical
diagnostics belong to?..Although It is mentioned in the HID usage
Table document of usb.org, does it not fit more under Audio Class as
it outputs audio(ultrasound)? Please direct me in right direction if i’m wrong.

Regards,
Sanjay

Who is going to consume the device’s audio and video data ? A custom app that talks directly to the driver? Or does it use built in functionality like directshow/media foundation? The answers to these ?s will dictate the class

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: xxxxx@gmail.com
Sent: Tuesday, June 09, 2009 10:25 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Which Class’s device is u.s.b ‘Ultrasound Device’(used for medical diagnostics)?

Hi all,

To which class does the U.S.B Ultrasound Devices used for medical
diagnostics belong to?..Although It is mentioned in the HID usage
Table document of usb.org, does it not fit more under Audio Class as
it outputs audio(ultrasound)? Please direct me in right direction if i’m wrong.

Regards,
Sanjay


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Thanks.
okay. I’m not sure. It could be a custom application/ a built in one, based on the feasibility. Whichever it may be, are these the only factors that decide which class it could belong to? If yes, then what could be the classes for custom app/built in application? I think it can be HID/Audio respectively. correct?

Yes, if you enumerate as a multifunction device you can split your device into hid and audio functions. If you conform to the usb audio spec, you get the audio driver for free. If you need video, you can conform to the usb video spec and get that driver for free as well

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, June 09, 2009 11:34 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Which Class’s device is u.s.b ‘Ultrasound Device’(used for medical diagnostics)?

Thanks.
okay. I’m not sure. It could be a custom application/ a built in one, based on the feasibility. Whichever it may be, are these the only factors that decide which class it could belong to? If yes, then what could be the classes for custom app/built in application? I think it can be HID/Audio respectively. correct?


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

okay.

Yes, if you enumerate as a multifunction device you can split your device into hid and audio >functions. If you conform to the usb audio spec,

you mean,2 possible classes as
1.Multifunction(hid+audio)
2.Audio Only.

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? 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?

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?

If its audio only, then we have to use directsound application. Correct?

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.

In my experience, if your data is not conventional audio data (like a typical sound card would use) I would recommend NOT using the standard audio class and the audio APIs. There’s little to gain (unless you consider using a standard Windows API an advantage) and there’s potential problems created.

I’ve seen the standard Windows audio interface introduce additional latency, for example.

Please take this as just one person’s general experience… and note that I’m not an expert in the area of the Windows USB or audio stacks.

Peter
OSR

Thanks guys.

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.

Spot on. But i have no clue how the device/driver is being developed. All I know is that i’ve to develop an application for that device, so i thought of trying for all possible solutions, so when the device is here, i should not have any hiccups! :slight_smile:

xxxxx@gmail.com wrote:

> 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.
>

Spot on. But i have no clue how the device/driver is being developed. All I know is that i’ve to develop an application for that device, so i thought of trying for all possible solutions, so when the device is here, i should not have any hiccups! :slight_smile:

This task is hopeless. You cannot hope to drive a device if you do not
have specs for how the device is to be used.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

sanjay kulkarni wrote:

But i have no clue how the device/driver is being developed. All I
know is that i’ve to develop an application for that device, so i
thought of trying for all possible solutions, so when the device is
here, i should not have any hiccups!

Simply amazing. Is this a typical outsourcing development model?

I know it is ridiculous. But at least I’m learning something because of this. :slight_smile: