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