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

[Patrick Shirkey]

Hi,

I haven't followed this thread until now. It reminds me of a problem I 
was seeing with my system. It turned out I had to enable DMA or a 
specific associated flag in the kernel... Are you 100% certain your 
kernel is setup for lowlat with *your* hardware?

It took me ages to figure out why it was happening for me and your 
problem is very similar to what I was experiencing...

Cheers.


I. E. Smith-Heisters wrote:
> 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
>> >
>> >
>>
> 


-- 
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://lau.linuxaudio.org - The Linux Audio Users guide
========================================

"Anything your mind can see you can manifest physically, then it will 
become reality" - Macka B