[alsa-devel] 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