[alsa-devel] Boss GT-001

[Clemens Ladisch]

Ricard Wanderlof wrote:
>         bEndpointAddress     0x0d  EP 13 OUT
>         bmAttributes            5
>           Transfer Type            Isochronous
>           Synch Type               Asynchronous
>           Usage Type               Data
>         wMaxPacketSize     0x0070  1x 112 bytes
>
>         bEndpointAddress     0x8e  EP 14 IN
>         bmAttributes           37
>           Transfer Type            Isochronous
>           Synch Type               Asynchronous
>           Usage Type               Implicit feedback Data
>         wMaxPacketSize     0x0070  1x 112 bytes
>
> When the Isochronous Synch Type is Asynchronous, there must be a feedback
> channel where the USB device reports back information so that it can
> adjust the output sampling rate.
>
> I might be barking up the wrong tree here as I'm new to this, but it looks
> as if endpoint 0x8e is providing the feedback data, and there doesn't seem
> to be any other isochronous endpoint defined in the lsusb dump which could
> be used for the actual capture cdata.

The first endpoint in an audio interface is for the actual samples.

> I'm not sure what 'Implicit feedback Data' means exactly though - is the
> feedback data multiplexed with the capture data perhaps?

The USB 2.0 specification says:
| 5.12.4.3 Implicit Feedback
|
| In some cases, implementing a separate explicit feedback endpoint can
| be avoided. If a device implements a group of isochronous data
| endpoints that are closely related and if:
| • All the endpoints in the group are synchronized (i.e. use sample
| clocks that are derived from a common master clock)
| • The group contains one or more isochronous data endpoints in one
| direction that normally would need explicit feedback
| • The group contains at least one isochronous data endpoint in the
| opposite direction
| Under these circumstances, the device may elect not to implement
| a separate isochronous explicit feedback endpoint. Instead, feedback
| information can be derived from the data endpoint in the opposite
| direction by observing its data rate.

In theory, the driver supports this, but there are known to be some
bugs. And in any case there should be no problem getting the capture
stream to start (it's the playback stream that would have a slightly
wrong sample clock); it's possible that this device needs some vendor-
specific commands, or a different order of commands. (The interesting
USB transactions would be everything except the isochronous ones.)


Regards,
Clemens