[linux-audio-user] Re: Intel HDA and Jack

Lee Revell rlrevell at joe-job.com
Sat Jun 17 15:19:26 EDT 2006


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 at gmail.com> wrote:
> > On 6/14/06, I. E. Smith-Heisters <public at 0x09.com> 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
> >
> 




More information about the Linux-audio-user mailing list