On Sun, 4 Aug 2013, James Stone wrote:
Don't know if these syslog errors are also related?
Aug 3 18:34:06 blueberry kernel: [35122.375869] retire_capture_urb:
3189 callbacks suppressed
I don't know. I can't tell where they come from or what they mean.
Alan Stern
--
To unsubscribe from
On Fri, 2 Aug 2013, James Stone wrote:
OK - here's a trace with all patches applied. It didn't occur when the
webcam was re-plugged this time.. This one happened when opening the
trace file while it was being written to. I hope this is OK? It seems
to be a fairly consistent way to get
On Sat, Aug 3, 2013 at 11:30 PM, James Stone jamesmst...@gmail.com wrote:
On Aug 3, 2013 9:28 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 2 Aug 2013, James Stone wrote:
OK - here's a trace with all patches applied. It didn't occur when
the
webcam was re-plugged this
On Thu, Aug 1, 2013 at 5:43 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 1 Aug 2013, James Stone wrote:
SMIs are controlled by the BIOS, not by the kernel. I don't think
changing the kernel would affect their timings.
Hmm.. ok. So do I need to see if there is a bios
Steve:
Here's another irqsoff trace collected by James. It's not as extreme
as before, but I don't know how to interpret the 875-us jump in the
time value. Could this be a result of the timer being adjusted?
Also, what's the explanation for these two lines:
URL Clas-32862d... 881us :
On Fri, Aug 02, 2013 at 10:14:39AM -0400, Alan Stern wrote:
URL Clas-32862d.h.1us : local_clock -perf_event_update_userpage
URL Clas-32862d.h.2us : watchdog_overflow_callback
-__perf_event_overflow
URL Clas-32862d.h.3us : arch_trigger_all_cpu_backtrace_handler
On Fri, 2013-08-02 at 16:36 +0200, Peter Zijlstra wrote:
On Fri, Aug 02, 2013 at 10:14:39AM -0400, Alan Stern wrote:
URL Clas-32862d.h.1us : local_clock -perf_event_update_userpage
URL Clas-32862d.h.2us : watchdog_overflow_callback
-__perf_event_overflow
URL Clas-3286
On Fri, 2 Aug 2013, Steven Rostedt wrote:
On Fri, 2013-08-02 at 16:36 +0200, Peter Zijlstra wrote:
On Fri, Aug 02, 2013 at 10:14:39AM -0400, Alan Stern wrote:
URL Clas-32862d.h.1us : local_clock -perf_event_update_userpage
URL Clas-32862d.h.2us :
On Fri, 2013-08-02 at 13:59 -0400, Alan Stern wrote:
On Fri, 2 Aug 2013, Steven Rostedt wrote:
On Fri, 2013-08-02 at 16:36 +0200, Peter Zijlstra wrote:
On Fri, Aug 02, 2013 at 10:14:39AM -0400, Alan Stern wrote:
URL Clas-32862d.h.1us : local_clock -perf_event_update_userpage
On Fri, 2 Aug 2013, Steven Rostedt wrote:
On Fri, 2013-08-02 at 13:59 -0400, Alan Stern wrote:
On Fri, 2 Aug 2013, Steven Rostedt wrote:
On Fri, 2013-08-02 at 16:36 +0200, Peter Zijlstra wrote:
On Fri, Aug 02, 2013 at 10:14:39AM -0400, Alan Stern wrote:
URL Clas-32862d.h.
On Fri, 2013-08-02 at 14:41 -0400, Alan Stern wrote:
Steve:
Here's another irqsoff trace collected by James. It's not as extreme
as before, but I don't know how to interpret the 875-us jump in the
time value. Could this be a result of the timer being adjusted?
Also, what's the
On Fri, 2013-08-02 at 14:57 -0400, Steven Rostedt wrote:
The tracer started within the NMI, but out of sheer (bad) luck. That's
because the NMI code has no logic to handle tracing interrupts on or
off, due to the problems they cause. We may at most be able to just
ignore all NMIs by adding a
On Fri, Aug 2, 2013 at 8:49 AM, James Stone jamesmst...@gmail.com wrote:
On Thu, Aug 1, 2013 at 5:43 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 1 Aug 2013, James Stone wrote:
SMIs are controlled by the BIOS, not by the kernel. I don't think
changing the kernel would affect
On Fri, Aug 2, 2013 at 8:02 PM, James Stone jamesmst...@gmail.com wrote:
On Fri, Aug 2, 2013 at 8:49 AM, James Stone jamesmst...@gmail.com wrote:
On Thu, Aug 1, 2013 at 5:43 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 1 Aug 2013, James Stone wrote:
SMIs are controlled by the
On Fri, Aug 02, 2013 at 02:57:26PM -0400, Steven Rostedt wrote:
The other thing you can do is not run perf while this is going on.
URL Clas-32862d.h.1us : local_clock -perf_event_update_userpage
URL Clas-32862d.h.2us : watchdog_overflow_callback
-__perf_event_overflow
URL
On Fri, 2 Aug 2013, James Stone wrote:
Okay, so the USB controllers do share IRQ lines. Were you using the
other USB buses when the errors occurred?
Webcam microphone might have been on.
You should try testing with no other USB activity going on. Just in
case.
Not yet
On Fri, Aug 2, 2013 at 8:40 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 2 Aug 2013, James Stone wrote:
Okay, so the USB controllers do share IRQ lines. Were you using the
other USB buses when the errors occurred?
Webcam microphone might have been on.
You should try
Alan Stern wrote:
On Wed, 31 Jul 2013, James Stone wrote:
On Wed, Jul 31, 2013 at 4:48 PM, Alan Stern st...@rowland.harvard.edu
wrote:
James, see what happens with this patch. It will print a warning
message in the system log every time it detects an underrun, but it
won't cause an URB
On Wed, 31 Jul 2013, James Stone wrote:
It seems likely that the error is caused by an SMI taking too much
time. At least, we seem to have ruled out everything else. Besides,
this change has to be made eventually in any case -- underruns can
occur at any time, in principle, and they
On Thu, 1 Aug 2013, James Stone wrote:
I've got some error messages written to syslog now - with no audible
effect on audio processing:
Aug 1 01:12:36 blueberry kernel: [ 6233.028335] ehci-pci
:00:12.2: iso underrun 8800c872db00 (1407+0 1471)
That's an impressive one. It
On Thu, 1 Aug 2013, Clemens Ladisch wrote:
It seems likely that the error is caused by an SMI taking too much
time. At least, we seem to have ruled out everything else. Besides,
this change has to be made eventually in any case -- underruns can
occur at any time, in principle, and they
Alan Stern wrote:
On Thu, 1 Aug 2013, Clemens Ladisch wrote:
It seems likely that the error is caused by an SMI taking too much
time. At least, we seem to have ruled out everything else. Besides,
this change has to be made eventually in any case -- underruns can
occur at any time, in
On Tue, 30 Jul 2013, Alan Stern wrote:
I can try to ameliorate the situation. Although the 7-ms delay will
inevitably cause an underrun, it doesn't have to cause errors the way
it does now. I'll write a patch to handle this. It may take a few
days.
James, see what happens with this patch.
On Wed, Jul 31, 2013 at 4:48 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Tue, 30 Jul 2013, Alan Stern wrote:
I can try to ameliorate the situation. Although the 7-ms delay will
inevitably cause an underrun, it doesn't have to cause errors the way
it does now. I'll write a patch to
On Wed, 31 Jul 2013, James Stone wrote:
On Wed, Jul 31, 2013 at 4:48 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Tue, 30 Jul 2013, Alan Stern wrote:
I can try to ameliorate the situation. Although the 7-ms delay will
inevitably cause an underrun, it doesn't have to cause errors
On Wed, Jul 31, 2013 at 10:07 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 31 Jul 2013, James Stone wrote:
On Wed, Jul 31, 2013 at 4:48 PM, Alan Stern st...@rowland.harvard.edu
wrote:
On Tue, 30 Jul 2013, Alan Stern wrote:
I can try to ameliorate the situation. Although the
On Wed, Jul 31, 2013 at 10:07 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 31 Jul 2013, James Stone wrote:
On Wed, Jul 31, 2013 at 4:48 PM, Alan Stern st...@rowland.harvard.edu
wrote:
On Tue, 30 Jul 2013, Alan Stern wrote:
I can try to ameliorate the situation. Although the
On Mon, 29 Jul 2013, James Stone wrote:
OK, having said that, I just got it to happen - listening to audacity
and just logging into Facebook (of all things!! Meh!)
This is the contents of the trace file (as per instructions on bug #1191603)
# tracer: irqsoff
#
# irqsoff latency trace
On Tue, 2013-07-30 at 11:42 -0400, Alan Stern wrote:
On Mon, 29 Jul 2013, James Stone wrote:
Just an FYI, it is usually better to email my rost...@goodmis.org
account. I don't always read my redhat email. That's reserved for
bugzillas assigned to me ;-)
OK, having said that, I just got it
On Tue, 30 Jul 2013, Steven Rostedt wrote:
On Tue, 2013-07-30 at 11:42 -0400, Alan Stern wrote:
On Mon, 29 Jul 2013, James Stone wrote:
Just an FYI, it is usually better to email my rost...@goodmis.org
account. I don't always read my redhat email. That's reserved for
bugzillas assigned to
On Tue, Jul 30, 2013 at 02:05:29PM -0400, Steven Rostedt wrote:
On Tue, 2013-07-30 at 11:42 -0400, Alan Stern wrote:
On Mon, 29 Jul 2013, James Stone wrote:
Just an FYI, it is usually better to email my rost...@goodmis.org
account. I don't always read my redhat email. That's reserved for
On Sun, 28 Jul 2013, James Stone wrote:
On Sat, Jul 27, 2013 at 6:45 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Sat, 27 Jul 2013, James Stone wrote:
OK. So this seems to have solved the starting jack at low latencies
problem, but I am still getting sporadic cannot submit urb (err
On Mon, Jul 29, 2013 at 9:41 PM, James Stone jamesmst...@gmail.com wrote:
On Mon, Jul 29, 2013 at 4:25 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Sun, 28 Jul 2013, James Stone wrote:
On Sat, Jul 27, 2013 at 6:45 PM, Alan Stern st...@rowland.harvard.edu
wrote:
On Sat, 27 Jul 2013,
On Sat, Jul 27, 2013 at 6:45 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Sat, 27 Jul 2013, James Stone wrote:
OK. So this seems to have solved the starting jack at low latencies
problem, but I am still getting sporadic cannot submit urb (err = -18)
under normal use. Will try to add
On Fri, Jul 26, 2013 at 11:46 PM, James Stone jamesmst...@gmail.com wrote:
On Fri, Jul 26, 2013 at 11:43 PM, James Stone jamesmst...@gmail.com wrote:
On Fri, Jul 26, 2013 at 7:54 PM, Alan Stern st...@rowland.harvard.edu
wrote:
On Fri, 26 Jul 2013, Clemens Ladisch wrote:
Alan Stern wrote:
On Sat, 27 Jul 2013, James Stone wrote:
OK. So this seems to have solved the starting jack at low latencies
problem, but I am still getting sporadic cannot submit urb (err = -18)
under normal use. Will try to add some more info to the #1191603
report if I can get it to happen while logging
On Fri, 26 Jul 2013, James Stone wrote:
James, can you try this out and send me the usbmon trace? At 64
frames/period this should end up using 4 URBs, which is the minimum
requirement if there are no more than 8 packets per URB and an
incompletely filled URB can contain as few as 1
Alan Stern wrote:
On Thu, 25 Jul 2013, James Stone wrote:
The only slight difference I can see is that maybe the 3.10 uses
slightly higher CPU load than 3.5 at the ridiculously low latency of
64 frames/period duplex.
With the new patch, what you actually get is 44.1 frames/period (on
On Fri, 26 Jul 2013, Clemens Ladisch wrote:
Alan Stern wrote:
On Thu, 25 Jul 2013, James Stone wrote:
The only slight difference I can see is that maybe the 3.10 uses
slightly higher CPU load than 3.5 at the ridiculously low latency of
64 frames/period duplex.
With the new patch,
On Wed, Jul 24, 2013 at 2:42 AM, James Stone jamesmst...@gmail.com wrote:
On Wed, Jul 24, 2013 at 12:23 AM, James Stone jamesmst...@gmail.com wrote:
On Tue, Jul 23, 2013 at 11:50 PM, Torstein Hegge he...@resisty.net wrote:
On Tue, Jul 23, 2013 at 21:13:23 +0100, James Stone wrote:
On Fri, Jul
James Stone wrote:
Ok -from the bisect, the problem of not being able to get to sub
64-frames per period starts with:
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=fc600432cd23e35c85de2ff4468d816d6938a112
This is a merge, which includes this commit:
On Thu, Jul 25, 2013 at 2:12 PM, Clemens Ladisch clem...@ladisch.de wrote:
James Stone wrote:
Ok -from the bisect, the problem of not being able to get to sub
64-frames per period starts with:
James Stone wrote:
On Thu, Jul 25, 2013 at 2:12 PM, Clemens Ladisch wrote:
The commit that you found by bisection got reverted later:
http://git.kernel.org/linus/015618b902ae
Please check that the code of Fix URB cancellation at stream start is
in your current kernel.
well, in 3.10, it is
On Thu, 25 Jul 2013, James Stone wrote:
On Thu, Jul 25, 2013 at 2:12 PM, Clemens Ladisch clem...@ladisch.de wrote:
James Stone wrote:
Ok -from the bisect, the problem of not being able to get to sub
64-frames per period starts with:
On Thu, Jul 25, 2013 at 4:29 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 25 Jul 2013, James Stone wrote:
On Thu, Jul 25, 2013 at 2:12 PM, Clemens Ladisch clem...@ladisch.de wrote:
James Stone wrote:
Ok -from the bisect, the problem of not being able to get to sub
64-frames per
On Thu, 25 Jul 2013, James Stone wrote:
Please try the patch from here:
http://marc.info/?l=linux-usbm=137476385206265w=2
instead of the one I sent to you yesterday. I think it will fix this
problem.
Alan Stern
Perfect! All fixed!
Can you provide a usbmon trace
On Thu, Jul 25, 2013 at 7:26 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 25 Jul 2013, James Stone wrote:
Please try the patch from here:
http://marc.info/?l=linux-usbm=137476385206265w=2
instead of the one I sent to you yesterday. I think it will fix this
On Thu, 25 Jul 2013, James Stone wrote:
On Thu, Jul 25, 2013 at 7:26 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 25 Jul 2013, James Stone wrote:
Please try the patch from here:
http://marc.info/?l=linux-usbm=137476385206265w=2
instead of the one I sent to
On Thu, Jul 25, 2013 at 10:24 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 25 Jul 2013, James Stone wrote:
On Thu, Jul 25, 2013 at 7:26 PM, Alan Stern st...@rowland.harvard.edu
wrote:
On Thu, 25 Jul 2013, James Stone wrote:
Please try the patch from here:
On Wed, 24 Jul 2013, James Stone wrote:
Ok - this does seem to be a vast improvement over 3.8.x (and even, in
some ways the 3.6x series) - with the addition of Clemen's patch.
However, very low realtime latencies (which seemed to be somewhat
possible - 64 frames/period or lower - in the 3.6x
On Fri, Jul 19, 2013 at 4:17 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 19 Jul 2013, James Stone wrote:
The questions now are:
Why are the same requests sent over and over again?
Why does the ALSA driver attempt to set the clock frequency
while
On Tue, 23 Jul 2013, James Stone wrote:
Hi Alan,
Just tried a few old kernels, and it seems that the bug I am
experiencing was introduced at the start of 3.7 - kernel 3.6.11 is
Note that 3.6.11 came out _after_ 3.7, not before.
fine, and all the 3.7 series kernels are broken. So it seems
On Tue, Jul 23, 2013 at 21:13:23 +0100, James Stone wrote:
On Fri, Jul 19, 2013 at 4:17 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 19 Jul 2013, James Stone wrote:
The questions now are:
Why are the same requests sent over and over again?
Why does
On Tue, Jul 23, 2013 at 11:50 PM, Torstein Hegge he...@resisty.net wrote:
On Tue, Jul 23, 2013 at 21:13:23 +0100, James Stone wrote:
On Fri, Jul 19, 2013 at 4:17 PM, Alan Stern st...@rowland.harvard.edu
wrote:
On Fri, 19 Jul 2013, James Stone wrote:
The questions now are:
On Wed, Jul 24, 2013 at 12:23 AM, James Stone jamesmst...@gmail.com wrote:
On Tue, Jul 23, 2013 at 11:50 PM, Torstein Hegge he...@resisty.net wrote:
On Tue, Jul 23, 2013 at 21:13:23 +0100, James Stone wrote:
On Fri, Jul 19, 2013 at 4:17 PM, Alan Stern st...@rowland.harvard.edu
wrote:
On
On Wed, Jul 17, 2013 at 7:48 PM, Alan Stern st...@rowland.harvard.edu wrote:
The 32-frames/period trace looks just like the 64 frames/period, only
worse. Each URB has only 4 packets, and the underrun problem is
severe. This won't happen after the minimum pipeline length is fixed.
The
On Fri, 19 Jul 2013, James Stone wrote:
The questions now are:
Why are the same requests sent over and over again?
Why does the ALSA driver attempt to set the clock frequency
while the clock is actively in use?
Has this behavior changed since the
On Tue, 16 Jul 2013, James Stone wrote:
Thanks. The patch allows jack to now start at (playback only) 64
frames/period. It doesn't work with 32 frames/period though (I think
you predicted this). This is still a regression from 3.5.0-28, which
will work with 8 frames/period for playback only.
On Wed, Jul 17, 2013 at 3:59 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Tue, 16 Jul 2013, James Stone wrote:
Thanks. The patch allows jack to now start at (playback only) 64
frames/period. It doesn't work with 32 frames/period though (I think
you predicted this). This is still a
On Wed, 17 Jul 2013, James Stone wrote:
On Wed, Jul 17, 2013 at 3:59 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Tue, 16 Jul 2013, James Stone wrote:
Thanks. The patch allows jack to now start at (playback only) 64
frames/period. It doesn't work with 32 frames/period though (I
On Mon, 15 Jul 2013, James Stone wrote:
James, did you ever provide a usbmon trace for 3.8 doing playback only
and using 64 frames/period? I don't recall seeing any. It might help.
OK - will send it to you off-list.
I got it. It explains a lot.
The audio-out stream uses a pipeline
Alan Stern wrote:
The audio-out stream uses a pipeline of only 2 URBs. The URBs start
out alternating between 8 and 7 packets apiece. This yields a total
latency around 1.9 ms (equivalent to 2 periods of about 41 frames at
44.1 KHz), which is smaller than I would expect (2 periods of 64
On Tue, 16 Jul 2013, Clemens Ladisch wrote:
Alan Stern wrote:
The audio-out stream uses a pipeline of only 2 URBs. The URBs start
out alternating between 8 and 7 packets apiece. This yields a total
latency around 1.9 ms (equivalent to 2 periods of about 41 frames at
44.1 KHz), which is
On Tue, Jul 16, 2013 at 7:36 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 15 Jul 2013, James Stone wrote:
James, did you ever provide a usbmon trace for 3.8 doing playback only
and using 64 frames/period? I don't recall seeing any. It might help.
OK - will send it to you
Alan Stern wrote:
On Sat, 13 Jul 2013, Clemens Ladisch wrote:
James Stone wrote:
On Mon, Jul 8, 2013 at 2:12 PM, James Stone jamesmst...@gmail.com wrote:
configuring for 44100Hz, period = 64 frames (1.5 ms), buffer = 2 periods
JackAudioDriver::ProcessAsync: read error, stopping...
Some
On Mon, 15 Jul 2013, Clemens Ladisch wrote:
The interrupts shouldn't differ by more than the duration of one URB,
which would be 1 ms. There is an initial delay when a stream is first
started, which generally lasts 5-10 ms. But I think that hasn't
changed since the 3.5 kernel. Would it
On Mon, Jul 15, 2013 at 9:42 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 15 Jul 2013, Clemens Ladisch wrote:
The interrupts shouldn't differ by more than the duration of one URB,
which would be 1 ms. There is an initial delay when a stream is first
started, which generally
James Stone wrote:
On Mon, Jul 8, 2013 at 2:12 PM, James Stone jamesmst...@gmail.com wrote:
configuring for 44100Hz, period = 64 frames (1.5 ms), buffer = 2 periods
JackAudioDriver::ProcessAsync: read error, stopping...
Some further info - on 3.5.0-28, I can start jackd in playback only
with
On Sat, 13 Jul 2013, Clemens Ladisch wrote:
James Stone wrote:
On Mon, Jul 8, 2013 at 2:12 PM, James Stone jamesmst...@gmail.com wrote:
configuring for 44100Hz, period = 64 frames (1.5 ms), buffer = 2 periods
JackAudioDriver::ProcessAsync: read error, stopping...
Some further info - on
On Thu, 11 Jul 2013, James Stone wrote:
Hi Clemens,
On Mon, Jul 8, 2013 at 2:12 PM, James Stone jamesmst...@gmail.com wrote:
Snip!
Acquire audio card Audio0
creating alsa driver ... hw:USB,0|-|64|2|44100|0|0|nomon|swmeter|-|16bit
Using ALSA driver USB-Audio running on card 0 -
James Stone wrote:
On Mon, Jul 8, 2013 at 2:12 PM, James Stone jamesmst...@gmail.com wrote:
ALSA: poll time out, polled for 2176094 usecs
JackAudioDriver::ProcessAsync: read error, stopping...
This is a definite reduction in performance compared to earlier kernels.
In theory, poll time out
Hi Clemens,
On Mon, Jul 8, 2013 at 2:12 PM, James Stone jamesmst...@gmail.com wrote:
Snip!
Acquire audio card Audio0
creating alsa driver ... hw:USB,0|-|64|2|44100|0|0|nomon|swmeter|-|16bit
Using ALSA driver USB-Audio running on card 0 - Focusrite Scarlett 2i4
USB at usb-:00:12.2-3, high
On Sat, Jul 6, 2013 at 9:39 PM, James Stone jamesmst...@gmail.com wrote:
On Sat, Jul 6, 2013 at 9:36 PM, James Stone jamesmst...@gmail.com wrote:
On Sat, Jul 6, 2013 at 3:41 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Sat, 6 Jul 2013, James Stone wrote:
The output when I try to start
Alan Stern wrote:
The first half is audio-out only. About 2 seconds after the start, the
audio-in stream starts up. After 2 URBs (2 ms) of data, everything
is shut down for no apparent reason -- there were no I/O errors.
[...]
I can't tell whether all these starts and stops are caused by
On Sat, Jul 6, 2013 at 9:57 AM, Clemens Ladisch clem...@ladisch.de wrote:
Alan Stern wrote:
The first half is audio-out only. About 2 seconds after the start, the
audio-in stream starts up. After 2 URBs (2 ms) of data, everything
is shut down for no apparent reason -- there were no I/O
On Sat, Jul 6, 2013 at 10:36 AM, James Stone jamesmst...@gmail.com wrote:
On Sat, Jul 6, 2013 at 9:57 AM, Clemens Ladisch clem...@ladisch.de wrote:
Alan Stern wrote:
The first half is audio-out only. About 2 seconds after the start, the
audio-in stream starts up. After 2 URBs (2 ms) of data,
On Sat, Jul 6, 2013 at 3:41 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Sat, 6 Jul 2013, James Stone wrote:
The output when I try to start jack with 128 frames/period is:
/usr/bin/jackd -dalsa -r44100 -p128 -n2 -D -Chw:USB,0 -Phw:USB,0 -I512 -O512
-S
jackdmp 1.9.9.5
Copyright
On Sat, Jul 6, 2013 at 9:36 PM, James Stone jamesmst...@gmail.com wrote:
On Sat, Jul 6, 2013 at 3:41 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Sat, 6 Jul 2013, James Stone wrote:
The output when I try to start jack with 128 frames/period is:
/usr/bin/jackd -dalsa -r44100 -p128 -n2
On Fri, Jul 5, 2013 at 3:31 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 4 Jul 2013, James Stone wrote:
Can you post the part of the trace showing where the audio-in Zi lines
first appear?
I think this is the start of the Zi lines:
8800b3585f00 3572683229 C Ci:1:004:0 0
On Fri, 5 Jul 2013, James Stone wrote:
I agree the original unable to submit urb bug has been fixed. I have
gone through the output trace, but I can't see anything like you were
suggesting.
I can submit the whole file (700k) somewhere if you like?
You can email it to me off-list.
Alan
On Fri, 5 Jul 2013, James Stone wrote:
On Fri, Jul 5, 2013 at 3:32 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 5 Jul 2013, James Stone wrote:
I agree the original unable to submit urb bug has been fixed. I have
gone through the output trace, but I can't see anything like you
On Thu, 4 Jul 2013, James Stone wrote:
Apologies - I realised I hadn't also applied the 1ms usb patch. With that
applied, it will start OK at 256, but not at 128 frames/period. (on earlier
kernels it can start at 64 frames/period).
Output file (for 128 frames/period) attached.
The part of
On Thu, Jul 4, 2013 at 4:19 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 4 Jul 2013, James Stone wrote:
Apologies - I realised I hadn't also applied the 1ms usb patch. With that
applied, it will start OK at 256, but not at 128 frames/period. (on earlier
kernels it can start at
On Thu, 4 Jul 2013, James Stone wrote:
Another hint: The important lines are the ones containing Zi:1:002:2
-- the actual string may be slightly different, but it will definitely
contain Zi and it will match the E lines.
OK. So I think this is something else then. There are no E
On Thu, Jul 4, 2013 at 9:12 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 4 Jul 2013, James Stone wrote:
Another hint: The important lines are the ones containing Zi:1:002:2
-- the actual string may be slightly different, but it will definitely
contain Zi and it will match the E
On Thu, 4 Jul 2013, James Stone wrote:
OK.. How is this:
8800a4976200 3574521627 S Zi:1:004:2 -115:1:3144 8 -18:0:63
-18:63:63 -18:126:63 -18:189:63 -18:252:63 504
8800a49dc600 3574521634 C Zi:1:004:1 0:8:3151:0 1 0:0:4 4 = 08830500
8800a49dc600 3574521636 S Zi:1:004:1
On Thu, Jul 4, 2013 at 10:13 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 4 Jul 2013, James Stone wrote:
OK.. How is this:
-71:63:0 -71:126:0 -71:189:0 -71:252:0 504 =
To all appearances, this shows what
On Thu, 4 Jul 2013, James Stone wrote:
Can you post the part of the trace showing where the audio-in Zi lines
first appear?
I think this is the start of the Zi lines:
8800b3585f00 3572683229 C Ci:1:004:0 0 4 = 44ac
8800a4976200 3572683283 S Zi:1:004:2 -115:1:1680 8
I wrote:
I'll fix this in the driver.
James, please test this patch.
Regards,
Clemens
--88--
ALSA: usb-audio: do not trust too-big wMaxPacketSize values
The driver used to assume that the streaming endpoint's wMaxPacketSize
On Thu, 4 Jul 2013, James Stone wrote:
Just tested, and it doesn't seem to work for fixing the problem on my
system. Device still locks up when trying jack frames/period of less than
512.
Can you post a short (a few hundred lines will be enough) usbmon trace
showing what happens with
Alan Stern wrote:
256 samples/period / (44100 samples/second) * 8000 microframes/second
= 46.44 microframes/period.
Therefore I would expect to see snd-usb-audio submitting isochronous
URBs with 46 or 47 packets, with a pipeline depth of 2 URBs.
However, that's not what actually
On Tue, 2 Jul 2013, Clemens Ladisch wrote:
Alan Stern wrote:
256 samples/period / (44100 samples/second) * 8000 microframes/second
= 46.44 microframes/period.
Therefore I would expect to see snd-usb-audio submitting isochronous
URBs with 46 or 47 packets, with a pipeline depth
92 matches
Mail list logo
