* USB hardware that supports implicit feedback?
@ 2012-11-15 20:11 Daniel Griscom
2012-11-15 21:02 ` Eldad Zack
0 siblings, 1 reply; 9+ messages in thread
From: Daniel Griscom @ 2012-11-15 20:11 UTC (permalink / raw)
To: Alsa Developer
[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
--
Daniel T. Griscom griscom@suitable.com
Suitable Systems http://www.suitable.com/
1 Centre Street, Suite 204 (781) 665-0053
Wakefield, MA 01880-2400
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: USB hardware that supports implicit feedback?
2012-11-15 20:11 USB hardware that supports implicit feedback? Daniel Griscom
@ 2012-11-15 21:02 ` Eldad Zack
2012-11-15 21:32 ` Daniel Griscom
0 siblings, 1 reply; 9+ messages in thread
From: Eldad Zack @ 2012-11-15 21:02 UTC (permalink / raw)
To: Daniel Griscom; +Cc: Alsa Developer
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: USB hardware that supports implicit feedback?
2012-11-15 21:02 ` Eldad Zack
@ 2012-11-15 21:32 ` Daniel Griscom
2012-11-15 23:22 ` Daniel Mack
2012-11-16 2:10 ` Eldad Zack
0 siblings, 2 replies; 9+ messages in thread
From: Daniel Griscom @ 2012-11-15 21:32 UTC (permalink / raw)
To: Eldad Zack; +Cc: Alsa Developer
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
--
Daniel T. Griscom griscom@suitable.com
Suitable Systems http://www.suitable.com/
1 Centre Street, Suite 204 (781) 665-0053
Wakefield, MA 01880-2400
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: USB hardware that supports implicit feedback?
2012-11-15 21:32 ` Daniel Griscom
@ 2012-11-15 23:22 ` Daniel Mack
2012-11-16 2:08 ` Eldad Zack
2012-11-16 2:39 ` Daniel Griscom
2012-11-16 2:10 ` Eldad Zack
1 sibling, 2 replies; 9+ messages in thread
From: Daniel Mack @ 2012-11-15 23:22 UTC (permalink / raw)
To: Daniel Griscom; +Cc: Eldad Zack, Alsa Developer
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: USB hardware that supports implicit feedback?
2012-11-15 23:22 ` Daniel Mack
@ 2012-11-16 2:08 ` Eldad Zack
2012-11-16 2:39 ` Daniel Griscom
1 sibling, 0 replies; 9+ messages in thread
From: Eldad Zack @ 2012-11-16 2:08 UTC (permalink / raw)
To: Daniel Mack; +Cc: Daniel Griscom, Alsa Developer
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: USB hardware that supports implicit feedback?
2012-11-15 21:32 ` Daniel Griscom
2012-11-15 23:22 ` Daniel Mack
@ 2012-11-16 2:10 ` Eldad Zack
2012-11-16 2:41 ` Daniel Griscom
1 sibling, 1 reply; 9+ messages in thread
From: Eldad Zack @ 2012-11-16 2:10 UTC (permalink / raw)
To: Daniel Griscom; +Cc: Alsa Developer, Daniel Mack
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) ||
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: USB hardware that supports implicit feedback?
2012-11-15 23:22 ` Daniel Mack
2012-11-16 2:08 ` Eldad Zack
@ 2012-11-16 2:39 ` Daniel Griscom
2012-11-18 10:10 ` Daniel Mack
1 sibling, 1 reply; 9+ messages in thread
From: Daniel Griscom @ 2012-11-16 2:39 UTC (permalink / raw)
To: Daniel Mack; +Cc: Eldad Zack, Alsa Developer
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 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 :)
Well, that's good to know anyway.
Lots to think about, and thanks,
Dan
--
Daniel T. Griscom griscom@suitable.com
Suitable Systems http://www.suitable.com/
1 Centre Street, Suite 204 (781) 665-0053
Wakefield, MA 01880-2400
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: USB hardware that supports implicit feedback?
2012-11-16 2:10 ` Eldad Zack
@ 2012-11-16 2:41 ` Daniel Griscom
0 siblings, 0 replies; 9+ messages in thread
From: Daniel Griscom @ 2012-11-16 2:41 UTC (permalink / raw)
To: Eldad Zack; +Cc: Alsa Developer, Daniel Mack
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
--
Daniel T. Griscom griscom@suitable.com
Suitable Systems http://www.suitable.com/
1 Centre Street, Suite 204 (781) 665-0053
Wakefield, MA 01880-2400
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: USB hardware that supports implicit feedback?
2012-11-16 2:39 ` Daniel Griscom
@ 2012-11-18 10:10 ` Daniel Mack
0 siblings, 0 replies; 9+ messages in thread
From: Daniel Mack @ 2012-11-18 10:10 UTC (permalink / raw)
To: Daniel Griscom; +Cc: Eldad Zack, Alsa Developer
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-11-18 10:11 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-15 20:11 USB hardware that supports implicit feedback? Daniel Griscom
2012-11-15 21:02 ` Eldad Zack
2012-11-15 21:32 ` Daniel Griscom
2012-11-15 23:22 ` Daniel Mack
2012-11-16 2:08 ` Eldad Zack
2012-11-16 2:39 ` Daniel Griscom
2012-11-18 10:10 ` Daniel Mack
2012-11-16 2:10 ` Eldad Zack
2012-11-16 2:41 ` Daniel Griscom
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.