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