question about USB audio device

wesley · November 14, 2012, 7:18am

I need to implement a USB audio device

learn from a USB audio handset,
Now I create some/same audio dev descriptors for a handset for the AC interface:

they are:

I have some quesitons:

in the upper terminal and units:
which could omit/delete, which lead to least units but the same handset functions

Because I just want to implement a handset, just for pick up the microphone data and using the ISO pipe in , and on the other hand, using the ISO out pipe output the data to a speaker.
No other functions needs, such as volume and mute.

I try to delete the three feature unit and the select unit
the results is

from usb analyzer,

not class specific request send by host
and when after unplug device, host could not unload the device from the windows device manager tree view.

why?

how to implement the class specific request in my device firmware?
any examples?

wesley · November 14, 2012, 7:21am

sorry about the diagram is not correct when output.

out direction:

microphone
input —> feature unit(1) —> |
| (3)mixer unit —> feature unit –>speaker output

| usb stream input(2) —> |
|
|------------------> fearute unit —>select unit —>usb stream output

1 and 2 mixer to 3

wesley · November 14, 2012, 7:24am

microphone
input0 —> feature unit(1) —> |
| (3)mixer unit —> 4feature unit –>5speaker output

| usb stream input(2) —> |
|
|–> 6fearute unit —>7select unit —>8usb stream output

0 to 1
1 and 2 mixer to 3
3 to 4, 4 to 5

0 to 6 to 7 to 8

Tim_Roberts · November 14, 2012, 1:06pm

workingmailing@163.com wrote:

I need to implement a USB audio device

learn from a USB audio handset,
Now I create some/same audio dev descriptors for a handset for the AC interface:

they are:

microphone input —> feature unit —> |
| mixer unit —> feature unit –>speaker output
| usb stream input —> |
|
|------------------> fearute unit —>select unit —>usb stream output

I have some quesitons:

in the upper terminal and units:
which could omit/delete, which lead to least units but the same handset functions

Because I just want to implement a handset, just for pick up the microphone data and using the ISO pipe in , and on the other hand, using the ISO out pipe output the data to a speaker.
No other functions needs, such as volume and mute.

Does your device actually do this? What you are advertising here is
that you will accept streaming output from an application, ship it to
your device, mix that data with the incoming microphone signal, then
send the resulting mix both to the speakers in your handset and as a
microphone input stream to applications. Is that REALLY what your
hardware does?

That’s not typical. Typically, you would have two independent graphs:

microphone –> feature unit –> usb stream output
usb stream input –> feature unit –> speaker output

Applications would then rely on the Audio Engine to provide the feedback
paths.

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

wesley · November 14, 2012, 9:16pm

i got the descriptors and relationships of the units/terminals from a handset now available on the market, it is a famous company make mouse,camera and handsets.

What you give out, thats right, for each direction, we have a topology
microphone to usb out and usb input to speaker.

But I think the topology I give out also is right.
It also want to stream the audio data coming from the microphone to the speaker.

So it mixer the microphone and the usb audio streaming input.

wesley · November 15, 2012, 7:33am

BTW

implement the same descriptors of the handset in my firmware
On win8 system, both speaker and microphone appear in the dev mng tree.

I still wonder:

what to do when received the get and set class request in my firmware?
does all the feature/mixer/selector must be implemented?

Tim_Roberts · November 15, 2012, 1:23pm

workingmailing@163.com wrote:

i got the descriptors and relationships of the units/terminals from a handset now available on the market, it is a famous company make mouse,camera and handsets.

The fact that it is being sold certainly does not mean that it is correct.

What you give out, thats right, for each direction, we have a topology
microphone to usb out and usb input to speaker.

But I think the topology I give out also is right.
It also want to stream the audio data coming from the microphone to the speaker.

So it mixer the microphone and the usb audio streaming input.

But is that REALLY what your hardware will do? Remember, the
descriptors are the way you tell the system how your hardware operates.
It’s not describing how you would want Windows to operate.

Here’s what you are saying. You are saying that your HARDWARE will
route your device’s microphone input directly to your device’s speaker
output through its internal mixer, directly, internally, with no USB
traffic involved. Will it really do that? You are also saying that you
will take the speaker data from the computer (the audio output), mix
that with your microphone’s data, and send that back to the computer as
your USB input stream, all within your device. Is that REALLY what your
hardware will do? I seriously doubt it.

I still wonder:

what to do when received the get and set class request in my firmware?

This is all described in the USB Audio Class spec. When you get a mixer
request, you adjust the parameters of your hardware’s mixer. When you
get a volume request, you adjust your hardware’s volume level. When you
get a selector request, you change the inputs for that stream.

If you don’t have a hardware mixer to adjust, then you shouldn’t be
advertising a mixer unit in your descriptors. There is no benefit to
anyone in advertising features that your hardware does not have.

does all the feature/mixer/selector must be implemented?

Again, this is in the spec. If you don’t have adjustable balance, then
don’t say that you do. If you don’t have a hardware mixer, then don’t
say that you do.

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

Tim_Roberts · November 15, 2012, 1:37pm

Tim Roberts wrote:

Here’s what you are saying. You are saying that your HARDWARE will
route your device’s microphone input directly to your device’s speaker
output through its internal mixer, directly, internally, with no USB
traffic involved. Will it really do that? You are also saying that you
will take the speaker data from the computer (the audio output), mix
that with your microphone’s data, and send that back to the computer as
your USB input stream, all within your device. Is that REALLY what your
hardware will do? I seriously doubt it.

Here’s how most handset hardware is actually implemented:

±-audio chip--------+
Microphone -|--------------------|-> USB capture stream
| |
Speaker <–| Mute <— Volume <-|-- USB playback stream
±-------------------+

Two separate hardware paths. No mixers, no selectors. In that case,
you would have two separate unit graphs. The speaker graph would have
one “feature” unit to control the mute function and the volume function.

With your descriptors, you are saying that you have a general purpose,
two-input / two-output mixer in your hardware, like this:

If you cannot identify the hardware registers that change the routing of
the signals and the balance of the inputs and outputs of that mixer,
then you do not have a mixer and should not advertise one.

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

wesley · November 15, 2012, 9:44pm

thank you Tim.

Actually,
1
I found that mixer could have multiple input, but only one output.
So I don’t believe your second graph is correct, because you have two outputs in the mixer.
2
And what i described in the graph and words is:
Microphone data to speaker and also to host by ISO in EP.
On the other hand, microphone data and ISO out EP data mixer together to the speaker.
3
In fact, my usb device only have EPs buffers not other control such as mute/volume or any other.
What I want to implement is a very easy handset for playback audio data from host and capture the microphone data.
4
Why I ask question about if I could omit/delete the feature/mixer/selector units in my former graph.
because my device hw have no these controls.
any other, when i delete the feature untis and the selector units
only keep the other 5 terminal/units, after I unplug the device, in device manager, the driver could not unloaded but restart to recover it.
But when I keep the feature and selector units, this case does not happen.

Maybe I will delete the mixer and microphone, just keep:

usb audio out –>feature –> speaker

microphone –> feature –> usb audio in

I found the microphone and audio out mixer is some bit complex and also no useful for me now.

But I still think it is right for some device such as I using now for microphone data to the speaker, which used to make other could listen what the microphone owner said.

Tim_Roberts · November 16, 2012, 1:57pm

workingmailing@163.com wrote:

Actually,
1
I found that mixer could have multiple input, but only one output.
So I don’t believe your second graph is correct, because you have two outputs in the mixer.

You are correct.

2
And what i described in the graph and words is:
Microphone data to speaker and also to host by ISO in EP.
On the other hand, microphone data and ISO out EP data mixer together to the speaker.

Yes, you are correct.

3
In fact, my usb device only have EPs buffers not other control such as mute/volume or any other.
What I want to implement is a very easy handset for playback audio data from host and capture the microphone data.

That’s the simple graph I described before, with two separate paths.

So, does this mean your hardware does NOT automatically route the
microphone to the speaker on its own? In that case, you cannot claim to
have a mixer.

4
Why I ask question about if I could omit/delete the feature/mixer/selector units in my former graph.
because my device hw have no these controls.
any other, when i delete the feature untis and the selector units
only keep the other 5 terminal/units, after I unplug the device, in device manager, the driver could not unloaded but restart to recover it.
But when I keep the feature and selector units, this case does not happen.

That usually means some system component still had your device open.
Perhaps a control panel?

Maybe I will delete the mixer and microphone, just keep:

usb audio out –>feature –> speaker
microphone –> feature –> usb audio in

You shouldn’t even have the feature units in there, if you don’t have
any features to control. Just USB audio out to speaker, and microphone
to USB audio in.

But I still think it is right for some device such as I using now for microphone data to the speaker, which used to make other could listen what the microphone owner said.

Yes, that was one of the tricks that the phone company used to use in
telephone handsets. A little bit of feedback seemed to help people
communicate. But here is the critical point: if you advertise that
connection in your descriptors, then your hardware must actually make
that connection. You cannot advertise that connection your descriptors
based on the hope that the operating system will make that feedback loop
happen.

The descriptors describe how your hardware actually works, not how you
hope it will be used.

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

wesley · November 17, 2012, 12:30am

thank you Tim.

i have implement the simplified topology:

usb audio out –>feature –> speaker
microphone –> feature –> usb audio in

both speaker and microphone and the composite driver are loaded.

Next step is trying to delete the former two feature units, to test if the three driver could also loaded. I still have doubt.

Last time:

I make the topology from:
microphone
input0 —> feature unit(1) —> |
| (3)mixer unit —> 4feature unit –>5speaker output
| usb stream input(2) —> |
|
|–> 6fearute unit —>7select unit —>8usb stream output

0 to 1
1 and 2 mixer to 3
3 to 4, 4 to 5

0 to 6 to 7 to 8

0 and 2 mixer to 3
3 to 5

0 to 8

in this case, driver loaded, but when unplug, driver could not unloaded.I still not known why.

At least, it is not what you said:
That usually means some system component still had your device open.
Perhaps a control panel?

wesley · November 19, 2012, 1:56am

hello every body.

Now I have simplified the topology from 9 terminal/units to 6 terminal/units then to only 4 terminals.

For 9, I have list above.
For 6:
microphone
input(0d)—>fearute unit(02)—>usb stream output(a)
usb stream input(0c)—>feature unit(01)–>speaker output(0e)

And for 4:
microphone input(0d)—>usb stream output(a)
usb stream input(0c) –>speaker output(0e)

for all three topology, on win7 and Win8 xHCI host
both composite and audio class driver loaded successfully.
But there are also two issue appears:

On win7 with xHCI nec host
when I play a mp3 file, Interface 1,1 is selected, before is interface 1,0(no bandwidth)
the ISO out EP/pipe could sent out data watch by USB analyzer, data packets are 176/180bytes, but the contents are allzero, why?
Where should I fix this issue in my code, descriptors, or class requests processing functions?

On win8 with xHCI nec host
when I play a mp3 file, Interface 1,1 is selected, before is interface 1,0(no bandwidth)
No ISO out pipe send out data, why?

another question:
When is host select interface 2,1?
I found when I play mp3 file, with the example handset, host will set interface 1,1, and 2,1 instead of 1,0 and 2,0
but in my device, when host set 2,1?

wesley · November 19, 2012, 2:15am

Sorry, i made a mistake:
When I review the USB analyzer, on Win7 system
xHCI nec host, ISO pipe send out data have non-zero packets.

wesley · November 20, 2012, 6:17am

another update
when seletct the control panel, voice.
Select the microphone, it will set interface 2,1.

Now only the quesion of Win8 do not out put data issue.