Hi, (please don't top-post) On Mon, Mar 31, 2014 at 11:08:58PM +0200, Russel Hughes wrote: > Playing any audio via spotify, youtube, BBC iplayer, XBMC causes the > problem. The problem is the audio glitches, its never crashed, as I > said the same device works flawlessly on a USB2.0 device amd has done > for about two years. Even with no music playing the buffer level > changes, the problem. I have seen this which is interesting > https://forums.presonus.com/posts/list/33427.page I will try and get > usbmon working tomorrow but it seems its a known Intel issue, I dont you really ought to use a kernel.org released kernel. v3.14 vanilla will be the best, as Greg suggested. > know if you can manage a software workaround. more of a generic xhci limitation. Matthias, do you know of any bugs/limitations WRT Isoch scheduling in our current xhci driver ? (keeping rest of message below for reference) > "Errata > 1. USB Isoch In Transfer Error Issue > > Problem: If a USB full-speed inbound isochronous transaction with a > packet length 190 bytes or > greater is started near the end of a microframe the PCH may see more > than 189 bytes > in the next microframe. > > Implication: If the PCH sees more than 189 bytes for a microframe an > error will be sent to software > and the isochronous transfer will be lost. If a single data packet is > lost no perceptible > impact for the end user is expected. > > Note: Intel has only observed the issue in a synthetic test > environment where precise control > of packet scheduling is available, and has not observed this failure > in its compatibility > validation testing. > > * Isochronous traffic is periodic and cannot be retried thus it is > considered good > practice for software to schedule isochronous transactions to start at > the beginning > of a microframe. Known software solutions follow this practice. > * To sensitize the system to the issue additional traffic such as > other isochronous > transactions or retries of asynchronous transactions would be required > to push the > inbound isochronous transaction to the end of the microframe. > > Workaround: None. > Status: No Plan to Fix." > > On 31 March 2014 22:32, Felipe Balbi <balbi@xxxxxx> wrote: > > On Mon, Mar 31, 2014 at 10:17:20PM +0200, Russel Hughes wrote: > >> Hi, > >> > >> Thanks for replying. I can use a some USB audio devices, ones based > >> around the Ti PCM2704 are fine, the DAC I want to use is called an > >> audiolab MDAC and as I said it has an elasticity buffer, this sits at > >> 50% full and is rock solid, as it should do, on USB 2.0 devices under > >> Ubuntu 12.04 LTS fully patched ASRock 330 but not on the 12.04 LTS > >> fully patched Intel NUC, where it reaches a maximum of 20% is highly > >> erratic and drops out from time to time. The lsmod output is as > > > > you need to grab information of the error. lsusb alone doesn't provide a > > lot of information (unless someone has dealt with the same error in a > > NUC). > > > > Can you describe the actual problem ? How can you trigger it ? What are > > you doing when the problem arises ? Do you hear audio glitches or does > > the device disconnect ? Do you have a crash ? Does the *same* device > > work on other setups ? > > > > Try to capture a usbmon trace of the failure, that's likely to help. > > > > -- > > balbi -- balbi
Attachment:
signature.asc
Description: Digital signature
