[alsa-devel] Audio usb switch to alternate setting 0
k.georgantas at samsung.com
Thu Jan 23 20:31:04 CET 2014
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".
> As the spec says (220.127.116.11.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 :)
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!
More information about the Alsa-devel