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

[I. E. Smith-Heisters]

Well.. just in case someone sees something that I don't, I thought I'd
include a transcript of a failed session. But I don't see any errors
there, except that it crashes, of course.
# jackd -v -R -dalsa -dhw:0 -r48000 -p1024 -n2 -S
getting driver descriptor from /usr/lib/libjack0.100.0-0/jack_alsa.so
getting driver descriptor from /usr/lib/libjack0.100.0-0/jack_dummy.so
getting driver descriptor from /usr/lib/libjack0.100.0-0/jack_oss.so
jackd 0.100.0
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

JACK compiled with System V SHM support.
server `default' registered
loading driver ..
apparent rate = 48000
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|16bit
control device hw:0
registered builtin port type 32 bit float mono audio
running with uid=0 and euid=0, will not try to use capabilites
new client: alsa_pcm, id = 1 type 1 @ 0x8058a78 fd = -1
configuring for 48000Hz, period = 1024 frames, buffer = 2 periods
nperiods = 2 for capture
nperiods = 2 for playback
new buffer size 1024
registered port alsa_pcm:capture_1, offset = 4096
registered port alsa_pcm:capture_2, offset = 8192
registered port alsa_pcm:playback_1, offset = 0
registered port alsa_pcm:playback_2, offset = 0
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
-- jack_rechain_graph()
6316 waiting for signals
jackd watchdog: timeout - killing jackd
Aborted
#

Thanks for any tips you might have. I'm quite stumped. Either no one
has tried to use jack with an ICH7 family chipset (highly
unlikely--it's quite common), or no one's run into this problem, since
I can't find a single post about problems with ICH7 and Jack through
Google.

Thanks again,
ian

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).
>
> hmm....
>
> thanks for the advice.
>
> -Ian
>
> On 6/13/06, Lee Revell <rlrevell at joe-job.com> wrote:
> > On Tue, 2006-06-13 at 16:17 -0400, I. E. Smith-Heisters wrote:
> > > I've futzed around a bit more. I'd done this before, but I'd forgotten
> > > the exact results except that it didn't work. Tried all this both with
> > > and without RT and 16bit mode forced:
> > >
> > > upping frames/period to 4096 reduces the number of xruns to several/second.
> > > upping periods/buffer to 3 still gives xruns, as well as "usecs
> > > exceeds estimated spare time" messages.
> > > upping periods/buffer to 4 makes initialization fail with "ALSA: got
> > > smaller periods 2 than 4 for playback"
> > > putting it into non-duplex (ie. playback only) has no effect on behavior.
> > >
> > > So, yeah, that's why it's mysterious. In the past I sacrifice latency
> > > for no xruns, and everything's dandy. Not so, this time...
> > >
> > > Thanks for the suggestions.
> >
> > Are you saying that RT mode has no effect on the xruns?  I find this
> > hard to believe.
> >
> > Check the messages from JACK - maybe it's failing to set RT mode (thisis
> > a bug that's fixed in the development tree).
> >
> > Try these tests in RT mode as root to be sure.
> >
> > Are you using the proprietary ATI or Nvidia drivers?
> >
> > Lee
> >
> >
>