[alsa-devel] USB hardware that supports implicit feedback?
[I posted this to the user list with no response; perhaps it was too technical.]
I'm having trouble getting implicit feedback working with my custom capture/playback USB audio class device, even with the latest kernel. I presume it's a problem with my device's configuration, but can't figure out exactly what the problem is (after a whole lotta investigation).
Specifically, my device captures an AES/EBU data stream (at a frame rate dictated by an external device), sends it to the computer via USB and ALSA, and then takes a processed audio stream from the computer via ALSA and USB, and sends it out at the same frame rate. The output stream should have the exact same frame rate as the input stream, governed by implicit feedback.
I understand that only recently has ALSA included support for implicit feedback. I'm running with kernel 3.6.6, which I believe includes the support, but still can't get it working. I'd really love to see something functioning in this mode so I can determine where the problem is.
Is there any commercial USB hardware out there that supports implicit feedback? I assume the ALSA developers are testing against something, but I can't find anything appropriate.
Or, is there source available that runs on some USB-capable micro board that supports it?
Thanks, Dan
Hi Daniel,
On Thu, 15 Nov 2012, Daniel Griscom wrote:
I'm having trouble getting implicit feedback working with my custom capture/playback USB audio class device, even with the latest kernel. I presume it's a problem with my device's configuration, but can't figure out exactly what the problem is (after a whole lotta investigation).
What exactly doesn't work? The "lsusb -v" output from your device might help here.
Is there any commercial USB hardware out there that supports implicit feedback? I assume the ALSA developers are testing against something, but I can't find anything appropriate.
I'm not an ALSA dev, but I recently posted a series of patches for the M-Audio Fast Track C400, which uses the implicit feedback code that was already in the tree for other devices. Take a look at sound/usb/pcm.c, there are quite a few hints to how this is discovered currently.
Cheers, Eldad
At 10:02 PM +0100 11/15/12, Eldad Zack wrote:
Hi Daniel,
On Thu, 15 Nov 2012, Daniel Griscom wrote:
I'm having trouble getting implicit feedback working with my custom capture/playback USB audio class device, even with the latest kernel. I presume it's a problem with my device's configuration, but can't figure out exactly what the problem is (after a whole lotta investigation).
What exactly doesn't work?
The audio output stream (from the computer to my device) runs at a few frames per second higher or lower rate than that of the input stream (from my device to the computer). The actual difference seems to be stable on a specific machine, but varies greatly between machines (I've seen differences from +7fps to -2fps; I presume this is due to differences in CPU clock frequencies).
The "lsusb -v" output from your device might help here.
It's long: posted at the end of this message.
Is there any commercial USB hardware out there that supports implicit feedback? I assume the ALSA developers are testing against something, but I can't find anything appropriate.
I'm not an ALSA dev, but I recently posted a series of patches for the M-Audio Fast Track C400, which uses the implicit feedback code that was already in the tree for other devices.
So, this device uses implicit feedback to tell ALSA to send output data at the same rate as its input data? Very cool; I've ordered one to test.
Take a look at sound/usb/pcm.c, there are quite a few hints to how this is discovered currently.
We've been looking there already, but will dig deeper.
Grateful for any help you may have, Dan
P.S. Here's the output of "sudo lsusb -v" for the device.
Bus 001 Device 005: ID 03eb:2311 Atmel Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x03eb Atmel Corp. idProduct 0x2311 bcdDevice 10.00 iManufacturer 1 Suitable Systems iProduct 2 USB 24-bit Stereo AudioCard iSerial 3 1.0.0.0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 266 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 0 AudioControl Interface Descriptor: bLength 10 bDescriptorType 36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 107 bInCollection 2 baInterfaceNr( 0) 2 baInterfaceNr( 1) 1 AudioControl Interface Descriptor: bLength 12 bDescriptorType 36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bNrChannels 1 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 17 AES/EBU AudioControl Interface Descriptor: bLength 12 bDescriptorType 36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 14 wTerminalType 0x0602 Digital Audio Interface bAssocTerminal 0 bNrChannels 1 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 18 SPDIF AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 2 bSourceID 1 bControlSize 1 bmaControls( 0) 0x03 Mute Volume bmaControls( 1) 0x00 iFeature 10 Output AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 3 wTerminalType 0x0301 Speaker bAssocTerminal 0 bSourceID 2 iTerminal 0 AudioControl Interface Descriptor: bLength 12 bDescriptorType 36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 4 wTerminalType 0x0201 Microphone bAssocTerminal 0 bNrChannels 1 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 7 Analog AudioControl Interface Descriptor: bLength 16 bDescriptorType 36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 8 bSourceID 4 bControlSize 1 bmaControls( 0) 0x00 bmaControls( 1) 0x80 Delay bmaControls( 2) 0x80 Delay bmaControls( 3) 0x80 Delay bmaControls( 4) 0x80 Delay bmaControls( 5) 0x80 Delay bmaControls( 6) 0x80 Delay bmaControls( 7) 0x80 Delay bmaControls( 8) 0x80 Delay iFeature 12 ADC Regs AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 5 (SELECTOR_UNIT) bUnitID 7 bNrInPins 3 baSource( 0) 8 baSource( 1) 1 baSource( 2) 14 iSelector 11 Source Select AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 5 bSourceID 7 bControlSize 1 bmaControls( 0) 0x03 Mute Volume bmaControls( 1) 0x00 iFeature 9 Input AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 6 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bSourceID 5 iTerminal 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 1 bDelay 1 frames wFormatTag 1 PCM AudioStreaming Interface Descriptor: bLength 17 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 2 bSubframeSize 2 bBitResolution 16 bSamFreqType 3 Discrete tSamFreq[ 0] 32000 tSamFreq[ 1] 44100 tSamFreq[ 2] 48000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0100 1x 256 bytes bInterval 1 bRefresh 0 bSynchAddress 2 AudioControl Endpoint Descriptor: bLength 7 bDescriptorType 37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 0 Undefined wLockDelay 0 Undefined Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 6 bDelay 1 frames wFormatTag 1 PCM AudioStreaming Interface Descriptor: bLength 17 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 2 bSubframeSize 2 bBitResolution 16 bSamFreqType 3 Discrete tSamFreq[ 0] 32000 tSamFreq[ 1] 44100 tSamFreq[ 2] 48000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 37 Transfer Type Isochronous Synch Type Asynchronous Usage Type Implicit feedback Data wMaxPacketSize 0x0100 1x 256 bytes bInterval 1 bRefresh 0 bSynchAddress 0 AudioControl Endpoint Descriptor: bLength 7 bDescriptorType 37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x00 bLockDelayUnits 0 Undefined wLockDelay 0 Undefined Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 11.01 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 39 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 2 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0001 Self Powered
Hi Daniel, Hi Elad,
On 16.11.2012 05:32, Daniel Griscom wrote:
At 10:02 PM +0100 11/15/12, Eldad Zack wrote:
Hi Daniel,
On Thu, 15 Nov 2012, Daniel Griscom wrote:
I'm having trouble getting implicit feedback working with my custom capture/playback USB audio class device, even with the latest kernel. I presume it's a problem with my device's configuration, but can't figure out exactly what the problem is (after a whole lotta investigation).
What exactly doesn't work?
The audio output stream (from the computer to my device) runs at a few frames per second higher or lower rate than that of the input stream (from my device to the computer). The actual difference seems to be stable on a specific machine, but varies greatly between machines (I've seen differences from +7fps to -2fps; I presume this is due to differences in CPU clock frequencies).
So you're saying that this is what you experience after you added code to make the driver use the implicit feedback mechanism? Over which time did you measure this and how exactly? Because frankly, I doubt that - the data rate is purely derived from the number of incoming samples.
Does your device demand the same number of *bytes* or samples/channel to be sent?
Is there any commercial USB hardware out there that supports implicit feedback? I assume the ALSA developers are testing against something, but I can't find anything appropriate.
I'm not an ALSA dev, but I recently posted a series of patches for the M-Audio Fast Track C400, which uses the implicit feedback code that was already in the tree for other devices.
Yes, sorry for not responding. I've seen this, but didn't have time yet to respond. Thanks for doing this.
So, this device uses implicit feedback to tell ALSA to send output data at the same rate as its input data? Very cool; I've ordered one to test.
The code I wrote for implicit feedback is used by the M-Audio FTU devices, although I would actually not recommend buying one.
Take a look at sound/usb/pcm.c, there are quite a few hints to how this is discovered currently.
We've been looking there already, but will dig deeper.
I might help if you posted a patch with the changes you made to support your device.
AudioStreaming Interface Descriptor: bLength 17 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 2 bSubframeSize 2 bBitResolution 16 bSamFreqType 3 Discrete tSamFreq[ 0] 32000 tSamFreq[ 1] 44100 tSamFreq[ 2] 48000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 37 Transfer Type Isochronous Synch Type Asynchronous Usage Type Implicit feedback Data
Note that I never tested the automatic discovery of that mode. The device I wrote the code for doesn't announce it that way, and so a quirk was needed in pcm.c to make it happen. Ideally though, what you did is the right thing to do, just just need to make sure the driver really obeys that setting :)
Daniel
Hi Daniel,
On Fri, 16 Nov 2012, Daniel Mack wrote:
On 16.11.2012 05:32, Daniel Griscom wrote:
At 10:02 PM +0100 11/15/12, Eldad Zack wrote:
I'm not an ALSA dev, but I recently posted a series of patches for the M-Audio Fast Track C400, which uses the implicit feedback code that was already in the tree for other devices.
Yes, sorry for not responding. I've seen this, but didn't have time yet to respond. Thanks for doing this.
Thank you for doing the heavy lifting there! After I noticed the clock drift (and read about the implicit feedback mechanism) with the first version I posted, I was able to get my hardware to work properly thanks to your work.
BTW, I took some measurements with a slightly modified jack_delay (to collect per-period statistics and more decimal precision output) and I see +/- 1 usec variation in real-world latency, so I'm very happy with it so far.
Note that I never tested the automatic discovery of that mode. The device I wrote the code for doesn't announce it that way, and so a quirk was needed in pcm.c to make it happen. Ideally though, what you did is the right thing to do, just just need to make sure the driver really obeys that setting :)
I think that Autodiscovery should fail with this amtel device because the number of endpoints is 1 for the playback ep (this is what I encountered with the C400). Maybe a info message could be added in case the attributes do say implicit feedback, but bNumEndpoints < 2?
Cheers, Eldad
At 7:22 AM +0800 11/16/12, Daniel Mack wrote:
Hi Daniel, Hi Elad,
On 16.11.2012 05:32, Daniel Griscom wrote:
At 10:02 PM +0100 11/15/12, Eldad Zack wrote:
Hi Daniel,
On Thu, 15 Nov 2012, Daniel Griscom wrote:
I'm having trouble getting implicit feedback working with my custom capture/playback USB audio class device, even with the latest kernel. I presume it's a problem with my device's configuration, but can't figure out exactly what the problem is (after a whole lotta investigation).
What exactly doesn't work?
The audio output stream (from the computer to my device) runs at a few frames per second higher or lower rate than that of the input stream (from my device to the computer). The actual difference seems to be stable on a specific machine, but varies greatly between machines (I've seen differences from +7fps to -2fps; I presume this is due to differences in CPU clock frequencies).
So you're saying that this is what you experience after you added code to make the driver use the implicit feedback mechanism? Over which time did you measure this and how exactly? Because frankly, I doubt that - the data rate is purely derived from the number of incoming samples.
This has been the case for a while; we started work with ALSA 1.0.23, but upgrading to kernel 3.6.6 (with included ALSA code) didn't change anything. We have yet to do any patching of ALSA for this matter.
Does your device demand the same number of *bytes* or samples/channel to be sent?
I'll have to check that.
Is there any commercial USB hardware out there that supports implicit feedback? I assume the ALSA developers are testing against something, but I can't find anything appropriate.
I'm not an ALSA dev, but I recently posted a series of patches for the M-Audio Fast Track C400, which uses the implicit feedback code that was already in the tree for other devices.
Yes, sorry for not responding. I've seen this, but didn't have time yet to respond. Thanks for doing this.
So, this device uses implicit feedback to tell ALSA to send output data at the same rate as its input data? Very cool; I've ordered one to test.
The code I wrote for implicit feedback is used by the M-Audio FTU devices,
So, with an FTU the implicit feedback code works? What version of kernel/ALSA should I use - the latest?
although I would actually not recommend buying one.
Too late...
Take a look at sound/usb/pcm.c, there are quite a few hints to how this is discovered currently.
We've been looking there already, but will dig deeper.
I might help if you posted a patch with the changes you made to support your device.
No such patch.
AudioStreaming Interface Descriptor: bLength 17 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 2 bSubframeSize 2 bBitResolution 16 bSamFreqType 3 Discrete tSamFreq[ 0] 32000 tSamFreq[ 1] 44100 tSamFreq[ 2] 48000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 37 Transfer Type Isochronous Synch Type Asynchronous Usage Type Implicit feedback DataNote that I never tested the automatic discovery of that mode. The device I wrote the code for doesn't announce it that way, and so a quirk was needed in pcm.c to make it happen. Ideally though, what you did is the right thing to do, just just need to make sure the driver really obeys that setting :)
Well, that's good to know anyway.
Lots to think about, and thanks, Dan
On 16.11.2012 10:39, Daniel Griscom wrote:
At 7:22 AM +0800 11/16/12, Daniel Mack wrote:
Hi Daniel, Hi Elad,
On 16.11.2012 05:32, Daniel Griscom wrote:
At 10:02 PM +0100 11/15/12, Eldad Zack wrote:
Hi Daniel,
On Thu, 15 Nov 2012, Daniel Griscom wrote:
I'm having trouble getting implicit feedback working with my custom capture/playback USB audio class device, even with the latest kernel. I presume it's a problem with my device's configuration, but can't figure out exactly what the problem is (after a whole lotta investigation).
What exactly doesn't work?
The audio output stream (from the computer to my device) runs at a few frames per second higher or lower rate than that of the input stream (from my device to the computer). The actual difference seems to be stable on a specific machine, but varies greatly between machines (I've seen differences from +7fps to -2fps; I presume this is due to differences in CPU clock frequencies).
So you're saying that this is what you experience after you added code to make the driver use the implicit feedback mechanism? Over which time did you measure this and how exactly? Because frankly, I doubt that - the data rate is purely derived from the number of incoming samples.
This has been the case for a while; we started work with ALSA 1.0.23, but upgrading to kernel 3.6.6 (with included ALSA code) didn't change anything. We have yet to do any patching of ALSA for this matter.
Well, afaik, ALSA 1.0.23 is what ships with a kernel <= 3.4, and the code for implicit feedback went in for 3.5.
Does your device demand the same number of *bytes* or samples/channel to be sent?
I'll have to check that.
Let me rephrase the question: does the number of input and output channels match? Eldad had a patch in his series that should make it work for both scenarios.
The code I wrote for implicit feedback is used by the M-Audio FTU devices,
So, with an FTU the implicit feedback code works?
Yes, it does for many others.
What version of kernel/ALSA should I use - the latest?
Yes, always use the latests from git, especially for such relatively new features.
Daniel
Hi Daniel,
On Thu, 15 Nov 2012, Daniel Griscom wrote:
The audio output stream (from the computer to my device) runs at a few frames per second higher or lower rate than that of the input stream (from my device to the computer). The actual difference seems to be stable on a specific machine, but varies greatly between machines (I've seen differences from +7fps to -2fps; I presume this is due to differences in CPU clock frequencies).
Looking at the lsusb output, I assume that the sink/source coupling doesn't work, because it's not in an interface group.
I'm not an ALSA dev, but I recently posted a series of patches for the M-Audio Fast Track C400, which uses the implicit feedback code that was already in the tree for other devices.
So, this device uses implicit feedback to tell ALSA to send output data at the same rate as its input data? Very cool; I've ordered one to test.
Yes, and it seems to work very good with my hardware. But I'm not actually sure I want to recommend a device with broken descriptors...
Try this, it *MIGHT* work (applies against mainline 3.7-rc5) - completely untested, btw.
Cheers, Eldad
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index 5c12a3f..fd766a3 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -372,6 +372,19 @@ static int set_format(struct snd_usb_substream *subs, struct audioformat *fmt) alts = &iface->altsetting[1]; goto add_sync_ep; } + break; + case USB_ID(0x03eb, 0x2311): /* AMTEL === UNTESTED === */ + if (is_playback) { + implicit_fb = 1; + ep = 0x82; + iface = usb_ifnum_to_if(dev, 2); + + if (!iface || iface->num_altsetting == 0) + return -EINVAL; + + alts = &iface->altsetting[1]; + goto add_sync_ep; + } }
if (((is_playback && attr == USB_ENDPOINT_SYNC_ASYNC) ||
At 3:08 AM +0100 11/16/12, Eldad Zack wrote:
I think that Autodiscovery should fail with this amtel device because the number of endpoints is 1 for the playback ep (this is what I encountered with the C400). Maybe a info message could be added in case the attributes do say implicit feedback, but bNumEndpoints < 2?
Good point. I'll look into changing that.
At 3:10 AM +0100 11/16/12, Eldad Zack wrote:
Hi Daniel, On Thu, 15 Nov 2012, Daniel Griscom wrote:
The audio output stream (from the computer to my device) runs at a few frames per second higher or lower rate than that of the input stream (from my device to the computer). The actual difference seems to be stable on a specific machine, but varies greatly between machines (I've seen differences from +7fps to -2fps; I presume this is due to differences in CPU clock frequencies).
Looking at the lsusb output, I assume that the sink/source coupling doesn't work, because it's not in an interface group.
And, good point number 2.
I'm not an ALSA dev, but I recently posted a series of patches for the M-Audio Fast Track C400, which uses the implicit feedback code that was already in the tree for other devices.
So, this device uses implicit feedback to tell ALSA to send output data at the same rate as its input data? Very cool; I've ordered one to test.
Yes, and it seems to work very good with my hardware. But I'm not actually sure I want to recommend a device with broken descriptors...
Try this, it *MIGHT* work (applies against mainline 3.7-rc5) - completely untested, btw.
Cheers, Eldad
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index 5c12a3f..fd766a3 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -372,6 +372,19 @@ static int set_format(struct snd_usb_substream *subs, struct audioformat *fmt) alts = &iface->altsetting[1]; goto add_sync_ep; }
break;case USB_ID(0x03eb, 0x2311): /* AMTEL === UNTESTED === */
if (is_playback) {implicit_fb = 1;ep = 0x82;iface = usb_ifnum_to_if(dev, 2);if (!iface || iface->num_altsetting == 0)return -EINVAL;alts = &iface->altsetting[1];goto add_sync_ep;}}
if (((is_playback && attr == USB_ENDPOINT_SYNC_ASYNC) ||
Very, ultra, mega-cool. Even if it doesn't work as-is, this will give me big hints on how to get it done.
Thanks for all the help, Dan
participants (3)
-
Daniel Griscom -
Daniel Mack -
Eldad Zack