Re: Audio I/O parameters

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 fro

Re: Audio I/O parameters

On Sat, Aug 3, 2013 at 11:30 PM, James Stone wrote: > > On Aug 3, 2013 9:28 PM, "Alan Stern" 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 time.. This one happened when

Re: Audio I/O parameters

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

Re: Audio I/O parameters

On Fri, Aug 2, 2013 at 8:40 PM, Alan Stern 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 sh

Re: Audio I/O parameters

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

Re: Audio I/O parameters

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 Clas

Re: Audio I/O parameters

On Fri, Aug 2, 2013 at 8:02 PM, James Stone wrote: > On Fri, Aug 2, 2013 at 8:49 AM, James Stone wrote: >> On Thu, Aug 1, 2013 at 5:43 PM, Alan Stern wrote: >>> On Thu, 1 Aug 2013, James Stone wrote: >>> > SMIs are controlled by the BIOS, not by the kernel. I don't think > changing th

Re: Audio I/O parameters

On Fri, Aug 2, 2013 at 8:49 AM, James Stone wrote: > On Thu, Aug 1, 2013 at 5:43 PM, Alan Stern 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

Re: Audio I/O parameters

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

Re: Audio I/O parameters

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 e

Re: Audio I/O parameters

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-

Re: Audio I/O parameters

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_

Re: Audio I/O parameters

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 : watchdog_overflo

Re: Audio I/O parameters

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 Cla

Re: Audio I/O parameters

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 >

Re: Audio I/O parameters

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 : ji

Re: Audio I/O parameters

On Thu, Aug 1, 2013 at 5:43 PM, Alan Stern 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 update/report this t

Re: Audio I/O parameters

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 tim

Re: Audio I/O parameters

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 update/report this to > motherboard manufacturer? If there's an update availa

Re: Audio I/O parameters

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, an

Re: Audio I/O parameters

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 indi

Re: Audio I/O parameters

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 t

Re: Audio I/O parameters

Alan Stern wrote: > On Wed, 31 Jul 2013, James Stone wrote: >> On Wed, Jul 31, 2013 at 4:48 PM, Alan Stern >> 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 submission fail

Re: Audio I/O parameters

On Wed, Jul 31, 2013 at 10:07 PM, Alan Stern wrote: > On Wed, 31 Jul 2013, James Stone wrote: > >> On Wed, Jul 31, 2013 at 4:48 PM, Alan Stern >> wrote: >> > On Tue, 30 Jul 2013, Alan Stern wrote: >> > >> >> I can try to ameliorate the situation. Although the 7-ms delay will >> >> inevitably ca

Re: Audio I/O parameters

On Wed, Jul 31, 2013 at 10:07 PM, Alan Stern wrote: > On Wed, 31 Jul 2013, James Stone wrote: > >> On Wed, Jul 31, 2013 at 4:48 PM, Alan Stern >> wrote: >> > On Tue, 30 Jul 2013, Alan Stern wrote: >> > >> >> I can try to ameliorate the situation. Although the 7-ms delay will >> >> inevitably ca

Re: Audio I/O parameters

On Wed, 31 Jul 2013, James Stone wrote: > On Wed, Jul 31, 2013 at 4:48 PM, Alan Stern 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

Re: Audio I/O parameters

On Wed, Jul 31, 2013 at 4:48 PM, Alan Stern 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 handle this. It may

Re: Audio I/O parameters

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 pat

Re: Audio I/O parameters

On Tue, 2013-07-30 at 14:41 -0400, Alan Stern wrote: > 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

Re: Audio I/O parameters

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 f

Re: Audio I/O parameters

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 assig

Re: Audio I/O parameters

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 i

Re: Audio I/O parameters

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 t

Re: Audio I/O parameters

On Mon, Jul 29, 2013 at 9:41 PM, James Stone wrote: > On Mon, Jul 29, 2013 at 4:25 PM, Alan Stern wrote: >> On Sun, 28 Jul 2013, James Stone wrote: >> >>> On Sat, Jul 27, 2013 at 6:45 PM, Alan Stern >>> wrote: >>> > On Sat, 27 Jul 2013, James Stone wrote: >>> > >>> >> OK. So this seems to have

Re: Audio I/O parameters

On Mon, Jul 29, 2013 at 4:25 PM, Alan Stern wrote: > On Sun, 28 Jul 2013, James Stone wrote: > >> On Sat, Jul 27, 2013 at 6:45 PM, 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

Re: Audio I/O parameters

On Sun, 28 Jul 2013, James Stone wrote: > On Sat, Jul 27, 2013 at 6:45 PM, 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) > >> un

Re: Audio I/O parameters

On Sat, Jul 27, 2013 at 6:45 PM, 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

Re: Audio I/O parameters

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

Re: Audio I/O parameters

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

Re: Audio I/O parameters

On Fri, Jul 26, 2013 at 11:46 PM, James Stone wrote: > On Fri, Jul 26, 2013 at 11:43 PM, James Stone wrote: >> On Fri, Jul 26, 2013 at 7:54 PM, Alan Stern >> wrote: >>> On Fri, 26 Jul 2013, Clemens Ladisch wrote: >>> Alan Stern wrote: > On Thu, 25 Jul 2013, James Stone wrote: >>

Re: Audio I/O parameters

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

Re: Audio I/O parameters

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

Re: Audio I/O parameters

On Thu, Jul 25, 2013 at 10:24 PM, Alan Stern wrote: > On Thu, 25 Jul 2013, James Stone wrote: > >> On Thu, Jul 25, 2013 at 7:26 PM, Alan Stern >> wrote: >> > On Thu, 25 Jul 2013, James Stone wrote: >> > >> >> > Please try the patch from here: >> >> > >> >> > http://marc.info/?l=linux-usb

Re: Audio I/O parameters

On Thu, 25 Jul 2013, James Stone wrote: > On Thu, Jul 25, 2013 at 7:26 PM, Alan Stern wrote: > > On Thu, 25 Jul 2013, James Stone wrote: > > > >> > Please try the patch from here: > >> > > >> > http://marc.info/?l=linux-usb&m=137476385206265&w=2 > >> > > >> > instead of the one I sent to

Re: Audio I/O parameters

On Thu, Jul 25, 2013 at 7:26 PM, Alan Stern wrote: > On Thu, 25 Jul 2013, James Stone wrote: > >> > Please try the patch from here: >> > >> > http://marc.info/?l=linux-usb&m=137476385206265&w=2 >> > >> > instead of the one I sent to you yesterday. I think it will fix this >> > problem. >>

Re: Audio I/O parameters

On Thu, 25 Jul 2013, James Stone wrote: > > Please try the patch from here: > > > > http://marc.info/?l=linux-usb&m=137476385206265&w=2 > > > > instead of the one I sent to you yesterday. I think it will fix this > > problem. > > > > Alan Stern > > > > Perfect! All fixed! Can you provid

Re: Audio I/O parameters

On Thu, Jul 25, 2013 at 4:29 PM, Alan Stern wrote: > On Thu, 25 Jul 2013, James Stone wrote: > >> On Thu, Jul 25, 2013 at 2:12 PM, Clemens Ladisch wrote: >> > James Stone wrote: >> >> Ok -from the bisect, the problem of not being able to get to sub >> >> 64-frames per period starts with: >> >> >>

Re: Audio I/O parameters

On Thu, 25 Jul 2013, James Stone wrote: > On Thu, Jul 25, 2013 at 2:12 PM, Clemens Ladisch wrote: > > 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-

Re: Audio I/O parameters

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: >> >> >> Please check that the code of "Fix URB cancellation at stream start" is >> in your current kernel. > > well,

Re: Audio I/O parameters

On Thu, Jul 25, 2013 at 2:12 PM, Clemens Ladisch wrote: > 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=fc600432cd23e35c85de2ff4468d816

Re: Audio I/O parameters

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:

Re: Audio I/O parameters

On Wed, Jul 24, 2013 at 2:42 AM, James Stone wrote: > On Wed, Jul 24, 2013 at 12:23 AM, James Stone wrote: >> On Tue, Jul 23, 2013 at 11:50 PM, Torstein Hegge 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 wrote:

Re: Audio I/O parameters

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.

Re: Audio I/O parameters

On Wed, Jul 24, 2013 at 12:23 AM, James Stone wrote: > On Tue, Jul 23, 2013 at 11:50 PM, Torstein Hegge 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 >>> wrote: >>> > On Fri, 19 Jul 2013, James Stone wrote: >>> > >>> >> > Th

Re: Audio I/O parameters

On Tue, Jul 23, 2013 at 11:50 PM, Torstein Hegge 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 >> wrote: >> > On Fri, 19 Jul 2013, James Stone wrote: >> > >> >> > The questions now are: >> >> > >> >> > Why are the same

Re: Audio I/O parameters

On Tue, Jul 23, 2013 at 21:13:23 +0100, James Stone wrote: > On Fri, Jul 19, 2013 at 4:17 PM, Alan Stern 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

Re: Audio I/O parameters

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 se

Re: Audio I/O parameters

On Fri, Jul 19, 2013 at 4:17 PM, Alan Stern 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 the cloc

Re: Audio I/O parameters

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 chang

Re: Audio I/O parameters

On Wed, Jul 17, 2013 at 7:48 PM, Alan Stern 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 256-frames/period duplex t

Re: Audio I/O parameters

On Wed, 17 Jul 2013, James Stone wrote: > On Wed, Jul 17, 2013 at 3:59 PM, Alan Stern 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 pre

Re: Audio I/O parameters

On Wed, Jul 17, 2013 at 3:59 PM, Alan Stern 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 regression from 3.5.0-2

Re: Audio I/O parameters

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 onl

Re: Audio I/O parameters

On Tue, Jul 16, 2013 at 7:36 PM, Alan Stern 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 off-lis

Re: Audio I/O parameters

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),

Re: Audio I/O parameters

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 f

Re: Audio I/O parameters

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

Re: Audio I/O parameters

On Mon, Jul 15, 2013 at 9:42 PM, Alan Stern 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 lasts 5-10 ms. Bu

Re: Audio I/O parameters

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. W

Re: Audio I/O parameters

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 wrote: > configuring for 44100Hz, period = 64 frames (1.5 ms), buffer = 2 periods > JackAudioDriver::ProcessAsync: read error, stopping... Some fu

Re: Audio I/O parameters

On Sat, 13 Jul 2013, Clemens Ladisch wrote: > James Stone wrote: > > On Mon, Jul 8, 2013 at 2:12 PM, James Stone wrote: > >>> configuring for 44100Hz, period = 64 frames (1.5 ms), buffer = 2 periods > >>> JackAudioDriver::ProcessAsync: read error, stopping... > >> > >> Some further info - on 3.5.

Re: Audio I/O parameters

James Stone wrote: > On Mon, Jul 8, 2013 at 2:12 PM, James Stone 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 8 frames

Re: Audio I/O parameters

James Stone wrote: > On Mon, Jul 8, 2013 at 2:12 PM, James Stone 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" indicate

Re: Audio I/O parameters

On Thu, 11 Jul 2013, James Stone wrote: > Hi Clemens, > > On Mon, Jul 8, 2013 at 2:12 PM, James Stone wrote: > > >> 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

Re: Audio I/O parameters

Hi Clemens, On Mon, Jul 8, 2013 at 2:12 PM, James Stone wrote: >> 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 speed >> configurin

Re: Audio I/O parameters

On Sat, Jul 6, 2013 at 9:39 PM, James Stone wrote: > On Sat, Jul 6, 2013 at 9:36 PM, James Stone wrote: >> On Sat, Jul 6, 2013 at 3:41 PM, Alan Stern 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

Re: Audio I/O parameters

On Sat, Jul 6, 2013 at 9:36 PM, James Stone wrote: > On Sat, Jul 6, 2013 at 3:41 PM, Alan Stern 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 >>

Re: Audio I/O parameters

On Sat, Jul 6, 2013 at 3:41 PM, Alan Stern 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 2001-2005 Paul Da

Re: Audio I/O parameters

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 2001-2005 Paul Davis and others. > Copyright 2004-2012 Grame. > jackdmp come

Re: Audio I/O parameters

On Sat, Jul 6, 2013 at 10:36 AM, James Stone wrote: > On Sat, Jul 6, 2013 at 9:57 AM, Clemens Ladisch 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 fo

Re: Audio I/O parameters

On Sat, Jul 6, 2013 at 9:57 AM, Clemens Ladisch 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 errors. >> [...]

Re: Audio I/O parameters

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 b

Re: Audio I/O parameters

On Fri, 5 Jul 2013, James Stone wrote: > On Fri, Jul 5, 2013 at 3:32 PM, Alan Stern 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 were > >> sugge

Re: Audio I/O parameters

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

Re: Audio I/O parameters

On Fri, Jul 5, 2013 at 3:31 AM, Alan Stern 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 4 = 44a

Re: Audio I/O parameters

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:168

Re: Audio I/O parameters

On Thu, Jul 4, 2013 at 10:13 PM, Alan Stern 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 happens when you

Re: Audio I/O parameters

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 -

Re: Audio I/O parameters

On Thu, Jul 4, 2013 at 9:12 PM, Alan Stern 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 " lines.

Re: Audio I/O parameters

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.

Re: Audio I/O parameters

On Thu, Jul 4, 2013 at 4:19 PM, Alan Stern 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 64 frames/period)

Re: Audio I/O parameters

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

Re: Audio I/O parameters

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 frames

Re: Audio I/O parameters

I wrote: > I'll fix this in the driver. James, please test this patch. Regards, Clemens --8<>8-- ALSA: usb-audio: do not trust too-big wMaxPacketSize values The driver used to assume that the streaming endpoint's wMaxPacketSize va

Re: Audio I/O parameters

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 pipeli

Re: Audio I/O parameters

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 actua