On 22.11.2012 20:40, Daniel Mack wrote: > On 07.11.2012 18:05, Jeffrey Barish wrote: >> On Wed 07 November 2012 10:04:14 Daniel Mack wrote: >>> On 07.11.2012 10:01, Daniel Mack wrote: >>>> On 07.11.2012 00:54, Jeffrey Barish wrote: >>>>> I guess that snd_usb_pcm_prepare is called by the core usb system to >>>>> prepare the snd driver. Anyway, snd_usb_pcm_prepare calls >>>>> configure_endpoint with a substream. Then configure_endpoint calls >>>>> snd_usb_endpoint_set_params with the data endpoint that corresponds to >>>>> the substream. snd_usb_endpoint_set_params calls data_ep_set_params >>>>> with the data ep and data_ep_set_params sets nurbs to 2 for the data >>>>> endpoint. >>>>> >>>>> snd_usb_endpoint_set_params has code to call sync_ep_set_params when the >>>>> endpoint is type sync. sync_ep_set_params sets nurbs to 4 (why?). >>>>> However, snd_usb_endpoint_set_params never invokes the call to >>>>> sync_ep_set_params because ep->type is always data. Back up: >>>>> snd_usb_endpoint_set_params is called from configure_endpoint. It is >>>>> called from an if block contingent on the substream's having a sync >>>>> endpoint. It does. However, the call to snd_usb_endpoint_set_params >>>>> passes subs->data_endpoint as the first argument, so >>>>> snd_usb_endpoint_set_params simply repeats the operations it performed >>>>> as a result of the previous invocation. I presume that the first >>>>> argument to the second call to snd_usb_endpoint_set_params should be >>>>> subs->sync_endpoint.> >>>> Eh. You clearly spotted a bug here. The rally interesting thing is that >>>> that it didn't bite us earlier, as it's in since 3.6. >>>> >>>>> I >>>>> >>>>> made that change. Now freqm does change. However, I am getting tons of >>>>> ticks. Now it sounds as if the payload size is always wrong. >>>>> >>>>> Oh, 44.1 kHz works. 48 kHz works. 88.2 and 96 don't work. >>>> >>>> That's a different issue. Would you like to prepare a patch for the >>>> issue above please? >> >> I don't know how to prepare a patch, so I'm inclined to fix the remaining >> problem before stopping to figure out the patch problem. >> >> I didn't get your previous email. I hope that it contained some suggestions >> on what to look for to solve the remaining problem. Please send it again. >> The problem seems to be related to timing considering that the driver works >> perfectly 5-10% of the time, but timing of what? I don't know what to look >> for. > > So with the first problem sorted out, I guess the other one is related > to to inexactly reported data feedback from the device. Some explanation > about the current code. > > The code in the lower half in snd_usb_handle_sync_urb(), endpoint.c does > some auto-detection of the feedback rate format. This is done in order > to cope with all the many devices use have all sorts of rate formats. > When called for the first time after a stream start, it shifts the > received value until it matches the nominal sampling frequency with an > accuracy of +50% or -25%. Once the shift value is determined, it is > saved for later reference. In case the values get badly of of bounds > over subsequent calls, the code falls back to the auto-detection mode again. > > In other words: if the device reports a bogus value in the very first > feedback packet, but stays inside the limits of the thresholds that > would make it fall back to auto-detection, the shift value will always > be wrong for the duration of that stream, resulting in bogus data rates > produced by the driver. > > This is where I would have a look. Add some printk()s in the "if > (unlikely(ep->freqshift == INT_MIN))" case and dump the values that are > detected, for both a working and non-working case. Btw - if that is the case, and the device stabilizes after a while, one way to fix that problem is to simply ignore the first x packets that are received. And there's already a quirks framework for that: initalize ep->skip_packets from snd_usb_endpoint_start_quirk(). Daniel ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
