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

On 6/17/06, Lee Revell <rlrevell@email-addr-hidden-job.com> wrote:
>
> 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.

Strange, Intel is no nice with OSS video drivers..

>
> Can you try the -rt kernel and enable latency tracing?
>

You mean compile a custom kernel? Sure, I'll get back once I've tried it.

> Does it make any difference if you boot with ACPI disabled?

No apparent change.

>
> Check /proc/interrupts for your soundcard - when you launch JACK in
> realtime mode does the interrupt count increase?
>

I *think* so, I'm not sure what the format of /proc/interrupts is.
Here's what I saw:

*jack not started*
 11: 852 XT-PIC uhci_hcd:usb2, HDA Intel
*started jack*
 11: 1010 XT-PIC uhci_hcd:usb2, HDA Intel
 11: 1106 XT-PIC uhci_hcd:usb2, HDA Intel
 11: 1325 XT-PIC uhci_hcd:usb2, HDA Intel
 11: 1537 XT-PIC uhci_hcd:usb2, HDA Intel
 11: 1591 XT-PIC uhci_hcd:usb2, HDA Intel
*jack crashed*
 11: 1591 XT-PIC uhci_hcd:usb2, HDA Intel

Alright, I'll go try a custom kernel. Ugh, I was really hoping I could
go with packaged kernels.

> Lee
>
> > Thanks!
> >
> > On 6/17/06, Jack O'Quin <jack.oquin@email-addr-hidden> wrote:
> > > On 6/14/06, I. E. Smith-Heisters <public@email-addr-hidden> 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
> > >
> >
>
>
Received on Mon Jun 19 00:15:01 2006