Audio usb switch to alternate setting 0

Audio usb switch to alternate setting 0

[Konstantinos Georgantas]

Hello,
I am trying to control from the client side which Alternate Setting to 
use. Basically I would like to be able to switch from Alternate Setting 
0 to 1 and vice versa so that I am not receiving any set interface 
requests in the meantime. From the audio class 2.0 documentation I 
understand that I should be able to do something like this by using the 
active alternate setting control, and here comes my main problem.

When I generate an interrupt to the interrupt endpoint I should expect a 
GET request which I never see in the host side (hope I am right here).

Here comes the interrupt:
interrupt->bInfo          = 0x00;
interrupt->bAttribute  = 0x01;
interrupt->wValue       = 0x0100;
interrupt->wIndex       = 0x0004;

Could you please tell me if such a functionality is supported and how 
the interrupt should look like?

Thank you,
Konstantinos

Re: Audio usb switch to alternate setting 0

[Daniel Mack]

Hi,

On 01/19/2014 02:50 PM, Konstantinos Georgantas wrote:
> I am trying to control from the client side which Alternate Setting to 
> use. Basically I would like to be able to switch from Alternate Setting 
> 0 to 1 and vice versa so that I am not receiving any set interface 
> requests in the meantime. From the audio class 2.0 documentation I 
> understand that I should be able to do something like this by using the 
> active alternate setting control, and here comes my main problem.

I'm not quite following from which side you're looking at the system,
IOW, who should be "receiving" requests. Are you talking about the
device or the host side?

As the spec says (5.2.6.1.1), such a control is read-only, and it "does
not allow an interface to change from one active Alternate Setting to
another without Host intervention". "The main purpose of this Control is
to notify the Host (through an interrupt) that the last
selected Alternate Setting is no longer valid.".

Active alt setting switching is done implictly by (de)activating the PCM
streams that are associated with them.

> When I generate an interrupt to the interrupt endpoint I should expect a 
> GET request which I never see in the host side (hope I am right here).
> 
> Here comes the interrupt:
> interrupt->bInfo          = 0x00;
> interrupt->bAttribute  = 0x01;
> interrupt->wValue       = 0x0100;
> interrupt->wIndex       = 0x0004;
> 
> Could you please tell me if such a functionality is supported and how 
> the interrupt should look like?

This type of interrupt is currently unsupported, but it should be easy
to add. Note, however, that the only interesting use case is to tear the
audio stream down and send active users XRUNs.

Not sure if this is what you want.

As always: patches are welcome :)


Daniel

Audio usb switch to alternate setting 0

[Konstantinos Georgantas]

Hello!

On 01/20/2014 11:25 AM, Daniel Mack wrote:
> Hi,
>
> On 01/19/2014 02:50 PM, Konstantinos Georgantas wrote:
>> I am trying to control from the client side which Alternate Setting to
>> use. Basically I would like to be able to switch from Alternate Setting
>> 0 to 1 and vice versa so that I am not receiving any set interface
>> requests in the meantime. From the audio class 2.0 documentation I
>> understand that I should be able to do something like this by using the
>> active alternate setting control, and here comes my main problem.
> I'm not quite following from which side you're looking at the system,
> IOW, who should be "receiving" requests. Are you talking about the
> device or the host side?
As I see it generating an interrupt from the device to the host should 
"force" the host to "take appropriate action to reactivate the interface 
by switching to a valid Alternate Setting".
> As the spec says (5.2.6.1.1), such a control is read-only, and it "does
> not allow an interface to change from one active Alternate Setting to
> another without Host intervention". "The main purpose of this Control is
> to notify the Host (through an interrupt) that the last
> selected Alternate Setting is no longer valid.".
>
> Active alt setting switching is done implictly by (de)activating the PCM
> streams that are associated with them.
That is right! But what if someone tries to play music for example? The 
host will try to set Alternate Setting 1 again thinking that it is still 
active but in this case my device happens to be in sleep mode so it 
cannot reply to the usb_set_interface requests. I thought that if I 
indicated that only Alternate Setting 0 is active I would avoid this 
request. Am I right? Of course when waking up I could issue another 
interrupt indicating that my device activates again the Alternate 
Setting 1. Please correct me if I misunderstand something.
>> When I generate an interrupt to the interrupt endpoint I should expect a
>> GET request which I never see in the host side (hope I am right here).
>>
>> Here comes the interrupt:
>> interrupt->bInfo          = 0x00;
>> interrupt->bAttribute  = 0x01;
>> interrupt->wValue       = 0x0100;
>> interrupt->wIndex       = 0x0004;
>>
>> Could you please tell me if such a functionality is supported and how
>> the interrupt should look like?
> This type of interrupt is currently unsupported, but it should be easy
> to add. Note, however, that the only interesting use case is to tear the
> audio stream down and send active users XRUNs.
>
> Not sure if this is what you want.
>
> As always: patches are welcome :)
>
>
> Daniel
>
Absolutely! I can come up with a patch but I just want to be sure I have 
understood the spec in the right way :) Thanks for your help!

Kostas

Re: Audio usb switch to alternate setting 0

[Daniel Mack]

On 01/23/2014 08:31 PM, Konstantinos Georgantas wrote:
> On 01/20/2014 11:25 AM, Daniel Mack wrote:
>> On 01/19/2014 02:50 PM, Konstantinos Georgantas wrote:
>>> I am trying to control from the client side which Alternate Setting to
>>> use. Basically I would like to be able to switch from Alternate Setting
>>> 0 to 1 and vice versa so that I am not receiving any set interface
>>> requests in the meantime. From the audio class 2.0 documentation I
>>> understand that I should be able to do something like this by using the
>>> active alternate setting control, and here comes my main problem.
>>
>> I'm not quite following from which side you're looking at the system,
>> IOW, who should be "receiving" requests. Are you talking about the
>> device or the host side?
>
> As I see it generating an interrupt from the device to the host should 
> "force" the host to "take appropriate action to reactivate the interface 
> by switching to a valid Alternate Setting".

Yes, that's the intended use of such an interrupt.

>> As the spec says (5.2.6.1.1), such a control is read-only, and it "does
>> not allow an interface to change from one active Alternate Setting to
>> another without Host intervention". "The main purpose of this Control is
>> to notify the Host (through an interrupt) that the last
>> selected Alternate Setting is no longer valid.".
>>
>> Active alt setting switching is done implictly by (de)activating the PCM
>> streams that are associated with them.
>
> That is right! But what if someone tries to play music for example? The 
> host will try to set Alternate Setting 1 again thinking that it is still 
> active but in this case my device happens to be in sleep mode so it 
> cannot reply to the usb_set_interface requests.

That's a different problem then. As far as the error case is concerned,
I would expect the device to stop ACKing the isochronous URBs
immediately, which would result the PCM stream to get torn down. When a
PCM interface is closed, the alternate setting 0 is selected
automatically, and things should be in sync again.

> I thought that if I 
> indicated that only Alternate Setting 0 is active I would avoid this 
> request.

Yes, but such a request should be NACKed by the device anyway if the alt
setting changed during runtime, so it shouldn't do any harm.

> Am I right? Of course when waking up I could issue another 
> interrupt indicating that my device activates again the Alternate 
> Setting 1. Please correct me if I misunderstand something.

I believe you're seeing two different effects mixed up here. The device
is not supposed to go to sleep mode in such sitations, and without being
asked to do so by the host. What exactly makes you believe it is in this
mode?

>> As always: patches are welcome :)
>
> Absolutely! I can come up with a patch but I just want to be sure I have 
> understood the spec in the right way :)

I think you did, but I have my doubts that your interpretations of what
happens is right, but you might recognize that yourself once you
implemented the code.

When cooking the patch, consider a generic interrupt handler outside of
mixer.c, and redirect to a mixer interrupt function for mixer requests.
I'd like to avoid fiddling with PCM stream details from mixer.c.


Thanks,
Daniel