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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
