On Thu, 8 May 2014, Russel Hughes wrote:
> Hi,
>
>Some more information from someone who has the same DAC as me and
> has got it working on USB3.0 under Linux. I dont know if this helps
> with a workround or just points to some fundamental problem with the
> Intel hardware.
>
> "I was right
> Does your computer have any USB-2 ports? Or is it possible to disable
> the USB-3 controllers in the BIOS? It would be worthwhile to see if
> the audio works when the device is attached to a non-USB-3 controller.
>
Hi,
Some more information from someone who has the same DAC as me and
has g
>
> I got it. There doesn't seem to be anything wrong with the data in the
> file. This means whatever the problem is, there's a good chance we
> can't find it through software.
>
> Does your computer have any USB-2 ports? Or is it possible to disable
> the USB-3 controllers in the BIOS? It wou
On Mon, 5 May 2014, Russel Hughes wrote:
> >
> > Can you put the entire file some place where I can download it?
> >
> Hi,
>
> You should have a link now to the file.
I got it. There doesn't seem to be anything wrong with the data in the
file. This means whatever the problem is, there's a goo
On Sun, 4 May 2014, Russel Hughes wrote:
> > The audio data is contained in the lines that have a 'Z'. Just search
> > for the first such line and then go back twenty or so lines before that
> > to provide some context.
> >
> > Alan Stern
>
> This OK?
Yep, that's what I wanted. However, this s
> The audio data is contained in the lines that have a 'Z'. Just search
> for the first such line and then go back twenty or so lines before that
> to provide some context.
>
> Alan Stern
This OK?
BR
Russel
fff880211c1e000 2991052997 S Ii:2:002:3 -115:32 2 <
880036d09480 2991060964 C Ii:
On Sun, 4 May 2014, Russel Hughes wrote:
> > It looks like you started the usbmon trace after the audio data
> > transfer was running. I need to see what happens when the audio data
> > transfer begins.
> >
> > Also, is there any way you can turn off the audio-in channel while
> > running the tes
On Sat, 3 May 2014, Russel Hughes wrote:
> sudo cat /sys/kernel/debug/usb/usbmon/2u > /tmp/1.mon.out
>
> first few hundred lines
>
> 880200adef00 2596394321 C Zi:2:004:1 0:1:1833:0 1 0:0:3 4 = 00030b00
> 880200adef00 2596394330 S Zi:2:004:1 -115:1:1833 1 -18:0:3 4 <
> 8801f3c8e600 2
> The patch was made against 3.15-rc2, which is no longer the latest
> kernel version.
>
> However, the nature of those error messages suggests that the patch
> file you tried to apply was messed up somehow, probably by your email
> client. You can get the unmodified original here:
>
> htt
On Sat, 3 May 2014, Russel Hughes wrote:
> Hi,
>
> We tried downloading the latest kernel 3.15 and got this when
> applying the patch
>
> File to patch: ^C
> :~/linux kernel/usb-3.15.orig$ patch -p1 < patch.dif
> patching file drivers/usb/host/xhci-ring.c
> Hunk #1 FAILED at 3153.
> Hunk #2
>
> Russel, here's a patch you can test. It's only a partial fix for the
> problem, because it doesn't handle over/underruns. Still, it would be
> nice to see if the patch makes any difference in normal operation.
>
> Even if it doesn't fix the problem, please post a short stretch (a few
> hundre
On Tue, 22 Apr 2014, Russel Hughes wrote:
> > More importantly, the routine sets urb->start_frame to the current
> > value of the frame counter. This is completely wrong; urb->start_frame
> > is supposed to be the (micro-)frame number for when the transfer
> > begins, not when the transfer was su
On 04/21/2014 11:49 PM, Alan Stern wrote:
Mathias:
I noticed a couple of things wrong in xhci_queue_isoc_tx_prepare().
One of them isn't too serious: The code checks in several places
whether the device is running at low speed. This is useless, because
USB does not support isochronous transfers
> More importantly, the routine sets urb->start_frame to the current
> value of the frame counter. This is completely wrong; urb->start_frame
> is supposed to be the (micro-)frame number for when the transfer
> begins, not when the transfer was submitted.
>
> As far as I can tell, the only way to
Mathias:
I noticed a couple of things wrong in xhci_queue_isoc_tx_prepare().
One of them isn't too serious: The code checks in several places
whether the device is running at low speed. This is useless, because
USB does not support isochronous transfers at low speed.
More importantly, the ro
15 matches
Mail list logo
