On Monday 22 Jan 2018 14:06:08 Keith A. Milner wrote:
On Wednesday 23 Aug 2017 14:52:43 Clemens Ladisch wrote:
Keith A. Milner wrote:
kernel: [ 1987.452947] usb 1-1: Unable to change format on ep #8e: already in use>
So the error messages are due to a userspace app trying to open playback and capture at the same time?
For this device, playback requires a running capture stream to determine the rate of packets. This error happens when the application tries to open the capture stream after the playback stream. (If the format does not actually need to change, the error message is misleading.)
Your actual problem is that the device does not send any capture packets.
OK, I found some more time to look at this.
The background is a Roland device. The device descriptor is attached, but it seems to be common to a lot of Roland devices.
Specifically on this device, the Playback endpoint is 0x0d and there is a related Implicit feedback endpoint at 0x8e.
I have USB traces of the device operation under Windows and the (non) operation under Linux. The primary difference seems to be that, under Windows, the Implict Feedback endpoint (0x8e) is opened prior to playback commencing. Given previous discussions (and further research) on Implicit feedback, this makes sense.
Under Linux, this does not happen.
I've been studying the code in pcm.c and endpoint.c to work out why this is, and have some questions on the code function.
The flow of the code to deal with implict feedback setup in pcm.c is, roughly, as follows: set_sync_endpoint set_sync_ep_implicit_fb_quirk search_roland_implicit_fb
set_sync_ep_implicit_fb_quirk seems to deal with quirks relating to implicit feedback and, within this, is a specific check for Roland which ends up branching to "add_sync_ep" which adds a new endpoint via endpoint.c function snd_usb_add_endpoint and assigns this as as the sync endpoint:
subs->sync_endpoint = snd_usb_add_endpoint(subs->stream->chip, alts, ep, !subs->direction, SND_USB_ENDPOINT_TYPE_DATA);
subs->data_endpoint->sync_master = subs->sync_endpoint;
Within endpoint.c, this new endpoint is added to chip->ep_list :
list_add_tail(&ep->list, &chip->ep_list);
After set_sync_ep_implicit_fb_quirk has completed it returns to set_sync_endpoint which then checks that there are at least 2 endpoints:
if (altsd->bNumEndpoints < 2) return 0;
However, in the case I'm testing, on this device, this test fails as bNumEndpoints is 1, even though we've just added a second endpoint for the Implicit feedback.
Looking at the code, endpoint.c does not alter bNumEndpoints, which seems to be a fundamental piece of data held against the usb_host_interface instance and, presumably, set from the device descriptor by underlying kernel code.
My question is, is the test for bNumEndpoints correct here? From what I can gather, the whole point of the set_sync_ep_implicit_fb_quirk and search_roland_implicit_fb code is to add an endpoint that can then be used by set_sync_endpoint, but this seems to be ignored by doing the test for bNumEndpoints.
Or, perhaps, is it that the way that this endpoint is added is incorrect.
I have, by the way, tried commenting out the bNumEndpoints test, and it fails at the subsequent sync-pipe check with:
invalid sync pipe. bmAttributes 00, bLength 0, bSynchAddress 00
To me this suggests the endpoint isn't being set correctly somehow.
Any pointers gratefully received.
Answering my own question, I've just realized that the objective of set_sync_endpoint is to set the sync endpoint as follows:
subs->data_endpoint->sync_master = subs->sync_endpoint;
The quirks in set_sync_ep_implicit_fb_quirk do this directly, so the remainder of the code in set_sync_endpoint is irrelevant for these devices.
My next course of action is to try to work out why the sync endpoint doesn't seem to be opened.
Cheers,
Keith