On Sat, 2006-06-17 at 15:05 -0400, I. E. Smith-Heisters wrote: > Unfortunately, changing to the OSS "nv" driver doesn't have any > observable effect on Jack's behavior.... I'll try futzing around with > that possibility some more though... maybe VESA drivers? ick. > It's probably a sound driver bug. This HDA intel crap is really getting to be a nightmare. It seems like sound is broken on every other new laptop. Can you try the -rt kernel and enable latency tracing? Does it make any difference if you boot with ACPI disabled? Check /proc/interrupts for your soundcard - when you launch JACK in realtime mode does the interrupt count increase? Lee > Thanks! > > On 6/17/06, Jack O'Quin <jack.oquin@xxxxxxxxx> wrote: > > On 6/14/06, I. E. Smith-Heisters <public@xxxxxxxx> wrote: > > > Okay, looked at it some more. When RT is enabled, jack just locks up > > > and the watchdog terminates the process, regardless of the buffer > > > size. When RT is disabled the xruns are allowed to continue, and the > > > number of xruns decreases with a higher buffer size (but never go > > > below about 10/second). There's no evidence that RT mode has failed to > > > be set. This is all as root. > > > > > > I am using the proprietary NVIDIA drivers, as gotten from the Ubuntu > > > repositories. I would be surprised if this had anything to do with it > > > though, since direct alsa works fine with the same xOrg drivers. > > > Unless, of course, there's some software conflict between the video > > > drivers and jack itself (as opposed to there being a hardware-level > > > conflict). > > > > It would not surprise me for the proprietary drivers to behave in > > a non-realtime-safe manner. This would affect JACK much worse > > than some heavily-buffered ALSA application. > > > > Can you try it with the open source driver to compare? > > -- > > joq > > >
