[alsa-devel] Audio usb switch to alternate setting 0
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
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
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
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
participants (2)
-
Daniel Mack -
Konstantinos Georgantas