13 Jun
2006
13 Jun
'06
4:24 p.m.
Hi all,
I'm having problems with my Intel HD Audio chipset and jack, and was
wondering if any of you might have some tips. I'm running Ubuntu
Dapper, and everything works fine out of the box. ESD works, aplay
works, etc.. When I start jackd the xruns fly by about as fast as they
can. If I start it with RT enabled, it just times out and crashes.
I've experimented with lots of different flags, but this is an
example:
jackd -dhw:0 -p256 -r48000 -n2
Of course, the snd-hda-intel module is loaded, or basic alsa stuff
wouldn't work. Also, I've been sure to start in fluxbox and do a 'ps
ax' just to be sure no other audio apps were interfering with device.
I've never run into this sort of thing before, where jackd won't work,
but aplay will. Any suggestions for troubleshooting?
Thanks,
Ian Smith-Heisters
--
http://0x09.com
13 Jun
13 Jun
5:24 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
2006/6/13, I. E. Smith-Heisters <public(a)0x09.com>om>:
I'm having problems with my Intel HD Audio chipset
and jack, and was
wondering if any of you might have some tips. I'm running Ubuntu
Dapper, and everything works fine out of the box. ESD works, aplay
works, etc.. When I start jackd the xruns fly by about as fast as they
can. If I start it with RT enabled, it just times out and crashes.
Any suggestions for troubleshooting?
Is that a laptop?
If yes: {
Is it your first experience with jack on laptop-builtins?
If yes: {
Get used to it. And get a real sounddevice for professional usage...
}
}
Arnold
--
visit http://dillenburg.dyndns.org/~arnold/
---
Wenn man mit Raubkopien Bands wie Brosis oder Britney Spears wirklich
verhindern könnte, würde ich mir noch heute einen Stapel Brenner und
einen Sack Rohlinge kaufen.
5:28 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
On Tue, 2006-06-13 at 21:24 +0200, Arnold Krille wrote:
2006/6/13, I. E. Smith-Heisters
<public(a)0x09.com>om>:
Eh... although onboard hardware is bad and getting worse, it should
really be possible.
Sounds like your hardware does not support those JACK settings.
First try a bigger buffer, leaving the periods set to 2. If that fails,
go back to a small buffer and try to increase the periods. If both of
those fail try to increase both.
Do all these tests in realtime mode.
Lee
I'm having problems with my Intel HD Audio
chipset and jack, and was
wondering if any of you might have some tips. I'm running Ubuntu
Dapper, and everything works fine out of the box. ESD works, aplay
works, etc.. When I start jackd the xruns fly by about as fast as they
can. If I start it with RT enabled, it just times out and crashes.
Any suggestions for troubleshooting?
Is that a laptop?
If yes: {
Is it your first experience with jack on laptop-builtins?
If yes: {
Get used to it. And get a real sounddevice for professional usage...
}
}
5:34 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
lol.
Yes, it's a laptop. No, it's not my first time dealing with
consumer-grade integrated audio chipsets. No, I don't have money for a
Hammerfall or an FA-66. And yes, I think it should be possible to at
least get it *working*, if not with sub 10ms latency.
Thanks anyhow.
On 6/13/06, Arnold Krille <arnold.krille(a)gmail.com> wrote:
2006/6/13, I. E. Smith-Heisters
<public(a)0x09.com>om>:
I'm having problems with my Intel HD Audio
chipset and jack, and was
wondering if any of you might have some tips. I'm running Ubuntu
Dapper, and everything works fine out of the box. ESD works, aplay
works, etc.. When I start jackd the xruns fly by about as fast as they
can. If I start it with RT enabled, it just times out and crashes.
Any suggestions for troubleshooting?
Is that a laptop?
If yes: {
Is it your first experience with jack on laptop-builtins?
If yes: {
Get used to it. And get a real sounddevice for professional usage...
}
}
Arnold
--
visit http://dillenburg.dyndns.org/~arnold/
---
Wenn man mit Raubkopien Bands wie Brosis oder Britney Spears wirklich
verhindern könnte, würde ich mir noch heute einen Stapel Brenner und
einen Sack Rohlinge kaufen.
5:57 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
On Tue, 13 Jun 2006 15:34:39 -0400
"I. E. Smith-Heisters" <public(a)0x09.com> wrote:
lol.
Yes, it's a laptop. No, it's not my first time dealing with
consumer-grade integrated audio chipsets. No, I don't have money for a
Hammerfall or an FA-66. And yes, I think it should be possible to at
least get it *working*, if not with sub 10ms latency.
Try playback only. not full duplex. some of these cheapo soundcards
still have problems with duplex in 2006.
flo
--
Palimm Palimm!
http://tapas.affenbande.org
5:59 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
On Tue, 2006-06-13 at 21:57 +0200, Florian Paul Schmidt wrote:
On Tue, 13 Jun 2006 15:34:39 -0400
"I. E. Smith-Heisters" <public(a)0x09.com> wrote:
It would have to be a software issue right? Seems like even the
cheapest of the cheap vendors must test by installing Windows and
running Skype.
Lee
lol.
Yes, it's a laptop. No, it's not my first time dealing with
consumer-grade integrated audio chipsets. No, I don't have money for a
Hammerfall or an FA-66. And yes, I think it should be possible to at
least get it *working*, if not with sub 10ms latency.
Try playback only. not full duplex. some of these cheapo soundcards
still have problems with duplex in 2006. 
6:17 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
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.
On 6/13/06, Christoph Eckert <ce(a)christeck.de> wrote:
Try playback only. not full duplex. some of these
cheapo soundcards
still have problems with duplex in 2006.
Full duplex is part of the HDA specs.
Best regards
ce
6:20 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
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
14 Jun
14 Jun
11:56 a.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
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(a)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
16 Jun
16 Jun
7:14 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
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(a)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(a)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
19 Jun
19 Jun
2:47 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
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(a)0x09.com> wrote:
--
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
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(a)joe-job.com> wrote:
(thisis
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 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
2:54 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
On Mon, 2006-06-19 at 23:46 +0700, Patrick Shirkey wrote:
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?
Sorry, this makes no sense at all. DMA for soundcards cannot be enabled
or disabled. And no special setup should be required to get this to
work.
How *exactly* did you fix your problem?
Lee
3:11 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
Lee Revell wrote:
On Mon, 2006-06-19 at 23:46 +0700, Patrick Shirkey
wrote:
DMA doesn't affect soundcards directly but it does cause latency issues.
The exact details of how I fixed it have been forgotten but the process
required me to go through my kernel with a finetooth comb. That's what
I'm suggesting for Ian.
--
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
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?
Sorry, this makes no sense at all. DMA for soundcards cannot be enabled
or disabled. And no special setup should be required to get this to
work.
How *exactly* did you fix your problem?
3:33 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
On Tue, 2006-06-20 at 00:10 +0700, Patrick Shirkey wrote:
Lee Revell wrote:
Sorry, your advice is so vague as to be useless.
How exactly does one "set up a kernel for lowlat with $FOO hardware"?
Lee
On Mon, 2006-06-19 at 23:46 +0700, Patrick
Shirkey wrote:
DMA doesn't affect soundcards directly but it does cause latency issues.
The exact details of how I fixed it have been forgotten but the process
required me to go through my kernel with a finetooth comb. That's what
I'm suggesting for Ian. 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?
Sorry, this makes no sense at all. DMA for soundcards cannot be enabled
or disabled. And no special setup should be required to get this to
work.
How *exactly* did you fix your problem?
3:56 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
Lee Revell wrote:
How exactly does one "set up a kernel for lowlat with $FOO hardware"?
In a previous message Ian stated that the hardware works well with
native alsa and that the problem only occurs with jack.
If you are 100% certain that it is a hardware problem then you are
discounting a plethora of variables that might be affecting the situation.
--
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
3:59 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
On Tue, 2006-06-20 at 00:54 +0700, Patrick Shirkey wrote:
Lee Revell wrote:
I am not certain it is a hardware problem. But vague advice like "check
your kernel config" does more harm than good.
Lee
How exactly does one "set up a kernel for lowlat with $FOO hardware"?
In a previous message Ian stated that the hardware works well with
native alsa and that the problem only occurs with jack.
If you are 100% certain that it is a hardware problem then you are
discounting a plethora of variables that might be affecting the situation.
4:57 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
Lee Revell wrote:
On Tue, 2006-06-20 at 00:54 +0700, Patrick Shirkey
wrote:
Well you know I don't suggest that to everyone on this forum. In this
case though I had a very similar problem that was fixed by delving into
the kernel config.
YMMV.
--
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
Lee Revell wrote:
I am not certain it is a hardware problem. But vague advice like "check
your kernel config" does more harm than good.
How exactly does one "set up a kernel for
lowlat with $FOO hardware"?
In a previous message Ian stated that the hardware works well with
native alsa and that the problem only occurs with jack.
If you are 100% certain that it is a hardware problem then you are
discounting a plethora of variables that might be affecting the situation.
5:13 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
On Tue, 2006-06-20 at 01:55 +0700, Patrick Shirkey wrote:
Well you know I don't suggest that to everyone on
this forum. In this
case though I had a very similar problem that was fixed by delving
into the kernel config.
Unless you can explain exactly what you changed, you are just confusing
people. It's a bad idea to just go changing random kernel config
options.
Lee
5:28 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
Lee Revell wrote:
On Tue, 2006-06-20 at 01:55 +0700, Patrick Shirkey
wrote:
I merely suggested he look at his config and possibly the DMA settings.
I didn't say he should do a Russian roulette.
--
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
Well you know I don't suggest that to
everyone on this forum. In this
case though I had a very similar problem that was fixed by delving
into the kernel config.
Unless you can explain exactly what you changed, you are just confusing
people. It's a bad idea to just go changing random kernel config
options.
6:10 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
On Tue, 2006-06-20 at 02:27 +0700, Patrick Shirkey wrote:
Lee Revell wrote:
These are the only DMA related settings in my kernel config. I doubt
that any of them could be related to the inability to run JACK in RT
mode.
$ zgrep DMA /proc/config.gz
CONFIG_GENERIC_ISA_DMA=y
CONFIG_ISA_DMA_API=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
Lee
On Tue, 2006-06-20 at 01:55 +0700, Patrick
Shirkey wrote:
I merely suggested he look at his config and possibly the DMA settings.
I didn't say he should do a Russian roulette.
Well you know I don't suggest that to
everyone on this forum. In this
case though I had a very similar problem that was fixed by delving
into the kernel config.
Unless you can explain exactly what you changed, you are just confusing
people. It's a bad idea to just go changing random kernel config
options.
17 Jun
17 Jun
2:51 a.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
On 6/14/06, I. E. Smith-Heisters <public(a)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
5:05 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
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.
Thanks!
On 6/17/06, Jack O'Quin <jack.oquin(a)gmail.com> wrote:
On 6/14/06, I. E. Smith-Heisters
<public(a)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
5:19 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
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(a)gmail.com> wrote:
On 6/14/06, I. E. Smith-Heisters
<public(a)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
8:30 p.m.
New subject: [linux-audio-user] RME Multiface II
Hi there,
I am new to this list and currently planing to shift
from Windows to Linux because of the inacceptable
future plans regarding DRM etc. .
For the audiocard I plan to use a RME Multiface II
which is not listed in the ALSA soundcard matrix:
http://www.alsa-project.org/alsa-doc/index.php?vendor=vendor-RME#matrix
AFAIK the changes didn't affect the driver so that the
from the driver view it should be possible to use the Multiface II
with the driver used for the Multiface (I).
Does anyone already use the Multiface II successfully in a Linux system?
Thanks in advance.
Cheers,
Joachim
10:31 p.m.
New subject: [linux-audio-user] RME Multiface II
On Sat, June 17, 2006 5:35 pm, Joachim wrote:
Hi there,
I am new to this list and currently planing to shift
from Windows to Linux because of the inacceptable
future plans regarding DRM etc. .
For the audiocard I plan to use a RME Multiface II
which is not listed in the ALSA soundcard matrix:
http://www.alsa-project.org/alsa-doc/index.php?vendor=vendor-RME#matrix
AFAIK the changes didn't affect the driver so that the
from the driver view it should be possible to use the Multiface II
with the driver used for the Multiface (I).
Does anyone already use the Multiface II successfully in a Linux system?
I use the Multiface II/HDSP PCI card with my Fedora Core 5 Planet CCRMA
system and everything works beautifully. The HDSP mixer and HDSP conf
utilities are installed automatically with alsa and work "out of the box"
for me. The versatility and quality is amazing.
This is actually weird timing for you to ask about this because I was
planning on listing my Multiface II/HDSP PCI system on eBay tomorrow in
order to pay my rent and car insurance (booo) :(
To respect the integrity of this list, please email me privately if you
are interested.
Hope this helps
Link
Thanks in advance.
Cheers,
Joachim
--
e-mail is . . .
18 Jun
18 Jun
2:33 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
On 6/17/06, Lee Revell <rlrevell(a)joe-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(a)gmail.com> wrote:
On 6/14/06, I. E. Smith-Heisters
<public(a)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
2:47 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
On Sun, 2006-06-18 at 12:33 -0400, I. E. Smith-Heisters wrote:
On 6/17/06, Lee Revell <rlrevell(a)joe-job.com>
wrote:
I don't think the video driver has anything at all to do with this.
Can you post the output of "dmesg" after trying JACK in realtime mode?
Lee
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..
4:38 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
Strange, Intel is no nice with OSS video drivers..
I don't think the video driver has anything at all to do with this.
Can you post the output of "dmesg" after trying JACK in realtime mode?
Nothing in there. The following is exactly the same as it was before
trying to start jack.
[17179691.824000] ACPI: Video Device [VID] (multi-head: yes rom: no post: no)
[17179691.824000] ACPI: Video Device [VID2] (multi-head: yes rom: no post: no)
[17179695.124000] ppdev: user-space parallel port driver
[17179695.352000] apm: BIOS not found.
[17179698.448000] Bluetooth: L2CAP ver 2.8
[17179698.448000] Bluetooth: L2CAP socket layer initialized
[17179698.452000] Bluetooth: RFCOMM socket layer initialized
[17179698.452000] Bluetooth: RFCOMM TTY layer initialized
[17179698.452000] Bluetooth: RFCOMM ver 1.7
I tried compiling the RT kernel (just running the default Ubuntu
PREEMPT right now), but ran into some problems, so I'll have to play
with it some more.
Thanks for helping out with this.
-Ian
Lee
4:43 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
On Sun, 2006-06-18 at 14:38 -0400, I. E. Smith-Heisters wrote:
Oh, no, I was referring, rather, to their OSS support of their 950
video chipset; I would think their linux-friendliness would extend to
their audio chipsets.
Intel is fine. They wrote and released a perfectly good HDA driver.
It's just that the vendors have a LOT of latitude to make small
variations on the chipset and they don't help with ALSA drivers.
It seems to work for many users but there are a lot of laptops that just
get no sound or bad sound.
Maybe you could recompile the standard Ubuntu kernel and enable ALSA
debugging?
Lee
Strange, Intel is no nice with OSS video drivers..
I don't think the video driver has anything at all to do with this.
Can you post the output of "dmesg" after trying JACK in realtime mode?
Nothing in there. The following is exactly the same as it was before
trying to start jack.
[17179691.824000] ACPI: Video Device [VID] (multi-head: yes rom: no post: no)
[17179691.824000] ACPI: Video Device [VID2] (multi-head: yes rom: no post: no)
[17179695.124000] ppdev: user-space parallel port driver
[17179695.352000] apm: BIOS not found.
[17179698.448000] Bluetooth: L2CAP ver 2.8
[17179698.448000] Bluetooth: L2CAP socket layer initialized
[17179698.452000] Bluetooth: RFCOMM socket layer initialized
[17179698.452000] Bluetooth: RFCOMM TTY layer initialized
[17179698.452000] Bluetooth: RFCOMM ver 1.7
I tried compiling the RT kernel (just running the default Ubuntu
PREEMPT right now), but ran into some problems, so I'll have to play
with it some more.
20 Jun
20 Jun
4:05 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
Okay, so I enabled ALSA debugging, as well as debug detect:
CONFIG_SND_DEBUG and CONFIG_SND_DEBUG_DETECT. Here's the /var/messages
tail produced by trying to start Jack:
Jun 20 14:00:26 localhost kernel: [17179738.108000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:26 localhost kernel: [17179738.108000]
hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.116000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.120000]
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.156000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.156000]
hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.164000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.164000]
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.196000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.196000]
hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.204000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.204000]
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.244000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.244000]
hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.252000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.252000]
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.292000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.292000]
hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.300000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.300000]
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.340000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.340000]
hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.348000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.348000]
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
*snip*
Jun 20 14:00:32 localhost kernel: [17179743.156000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:32 localhost kernel: [17179743.156000]
hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x11
Jun 20 14:00:32 localhost kernel: [17179743.164000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:32 localhost kernel: [17179743.164000]
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
Jun 20 14:00:32 localhost kernel: [17179743.180000]
hda_codec_setup_stream: NID=0x2, stream=0x0, channel=0, format=0x0
Jun 20 14:00:32 localhost kernel: [17179743.188000]
hda_codec_setup_stream: NID=0x3, stream=0x0, channel=0, format=0x0
I can't make heads or tails of that; hopefully it means something to
you. I'll try compiling the RT vanilla kernel now and see if that
shows anything..
Thanks for the help.
On 6/18/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Sun, 2006-06-18 at 14:38 -0400, I. E.
Smith-Heisters wrote:
Oh, no, I was referring, rather, to their OSS support of their 950
video chipset; I would think their linux-friendliness would extend to
their audio chipsets.
Intel is fine. They wrote and released a perfectly good HDA driver.
It's just that the vendors have a LOT of latitude to make small
variations on the chipset and they don't help with ALSA drivers.
It seems to work for many users but there are a lot of laptops that just
get no sound or bad sound.
Maybe you could recompile the standard Ubuntu kernel and enable ALSA
debugging?
Lee
Strange, Intel is no nice with OSS video drivers..
I don't think the video driver has anything at all to do with this.
Can you post the output of "dmesg" after trying JACK in realtime mode?
Nothing in there. The following is exactly the same as it was before
trying to start jack.
[17179691.824000] ACPI: Video Device [VID] (multi-head: yes rom: no post: no)
[17179691.824000] ACPI: Video Device [VID2] (multi-head: yes rom: no post: no)
[17179695.124000] ppdev: user-space parallel port driver
[17179695.352000] apm: BIOS not found.
[17179698.448000] Bluetooth: L2CAP ver 2.8
[17179698.448000] Bluetooth: L2CAP socket layer initialized
[17179698.452000] Bluetooth: RFCOMM socket layer initialized
[17179698.452000] Bluetooth: RFCOMM TTY layer initialized
[17179698.452000] Bluetooth: RFCOMM ver 1.7
I tried compiling the RT kernel (just running the default Ubuntu
PREEMPT right now), but ran into some problems, so I'll have to play
with it some more.
23 Jun
23 Jun
1:01 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
I can't seem to get any of the vanilla kernels to run on my machine--I
must need some Ubuntu patch, but I haven't any idea which one. I'll
look into it further, but for the time being it looks like my
debugging abilities will be limited to what can be done by compiling
the Ubuntu kernel (eg. no RT or latency tracing..)
Thanks again.
On 6/20/06, I. E. Smith-Heisters <public(a)0x09.com> wrote:
Okay, so I enabled ALSA debugging, as well as debug
detect:
CONFIG_SND_DEBUG and CONFIG_SND_DEBUG_DETECT. Here's the /var/messages
tail produced by trying to start Jack:
Jun 20 14:00:26 localhost kernel: [17179738.108000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:26 localhost kernel: [17179738.108000]
hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.116000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.120000]
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.156000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.156000]
hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.164000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.164000]
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.196000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.196000]
hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.204000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.204000]
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.244000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.244000]
hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.252000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.252000]
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.292000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.292000]
hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.300000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.300000]
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.340000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.340000]
hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.348000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.348000]
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
*snip*
Jun 20 14:00:32 localhost kernel: [17179743.156000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:32 localhost kernel: [17179743.156000]
hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x11
Jun 20 14:00:32 localhost kernel: [17179743.164000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:32 localhost kernel: [17179743.164000]
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
Jun 20 14:00:32 localhost kernel: [17179743.180000]
hda_codec_setup_stream: NID=0x2, stream=0x0, channel=0, format=0x0
Jun 20 14:00:32 localhost kernel: [17179743.188000]
hda_codec_setup_stream: NID=0x3, stream=0x0, channel=0, format=0x0
I can't make heads or tails of that; hopefully it means something to
you. I'll try compiling the RT vanilla kernel now and see if that
shows anything..
Thanks for the help.
On 6/18/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Sun, 2006-06-18 at 14:38 -0400, I. E.
Smith-Heisters wrote:
Intel is fine. They wrote and released a perfectly good HDA driver.
It's just that the vendors have a LOT of latitude to make small
variations on the chipset and they don't help with ALSA drivers.
It seems to work for many users but there are a lot of laptops that just
get no sound or bad sound.
Maybe you could recompile the standard Ubuntu kernel and enable ALSA
debugging?
Lee
>
> Strange, Intel is no nice with OSS video drivers..
>
I don't think the video driver has anything at all to do with this.
Oh, no, I was referring, rather, to their OSS support of their 950
video chipset; I would think their linux-friendliness would extend to
their audio chipsets.
Can you post the output of "dmesg" after trying JACK in realtime mode?
Nothing in there. The following is exactly the same as it was before
trying to start jack.
[17179691.824000] ACPI: Video Device [VID] (multi-head: yes rom: no post: no)
[17179691.824000] ACPI: Video Device [VID2] (multi-head: yes rom: no post: no)
[17179695.124000] ppdev: user-space parallel port driver
[17179695.352000] apm: BIOS not found.
[17179698.448000] Bluetooth: L2CAP ver 2.8
[17179698.448000] Bluetooth: L2CAP socket layer initialized
[17179698.452000] Bluetooth: RFCOMM socket layer initialized
[17179698.452000] Bluetooth: RFCOMM TTY layer initialized
[17179698.452000] Bluetooth: RFCOMM ver 1.7
I tried compiling the RT kernel (just running the default Ubuntu
PREEMPT right now), but ran into some problems, so I'll have to play
with it some more.
5 Jul
5 Jul
1:04 p.m.
New subject: [linux-audio-user] Re: Intel HDA and Jack
Any more thoughts on this? I'm at a loss.
TIA,
Ian
On 6/23/06, I. E. Smith-Heisters <public(a)0x09.com> wrote:
I can't seem to get any of the vanilla kernels to
run on my machine--I
must need some Ubuntu patch, but I haven't any idea which one. I'll
look into it further, but for the time being it looks like my
debugging abilities will be limited to what can be done by compiling
the Ubuntu kernel (eg. no RT or latency tracing..)
Thanks again.
On 6/20/06, I. E. Smith-Heisters <public(a)0x09.com> wrote:
Okay, so I enabled ALSA debugging, as well as
debug detect:
CONFIG_SND_DEBUG and CONFIG_SND_DEBUG_DETECT. Here's the /var/messages
tail produced by trying to start Jack:
Jun 20 14:00:26 localhost kernel: [17179738.108000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:26 localhost kernel: [17179738.108000]
hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.116000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.120000]
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.156000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.156000]
hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.164000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.164000]
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.196000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.196000]
hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.204000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.204000]
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.244000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.244000]
hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.252000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.252000]
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.292000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.292000]
hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.300000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.300000]
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.340000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.340000]
hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.348000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:27 localhost kernel: [17179738.348000]
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
*snip*
Jun 20 14:00:32 localhost kernel: [17179743.156000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:32 localhost kernel: [17179743.156000]
hda_codec_setup_stream: NID=0x3, stream=0x1, channel=0, format=0x11
Jun 20 14:00:32 localhost kernel: [17179743.164000] azx_pcm_prepare:
bufsize=0x1000, fragsize=0x800, format=0x11
Jun 20 14:00:32 localhost kernel: [17179743.164000]
hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x11
Jun 20 14:00:32 localhost kernel: [17179743.180000]
hda_codec_setup_stream: NID=0x2, stream=0x0, channel=0, format=0x0
Jun 20 14:00:32 localhost kernel: [17179743.188000]
hda_codec_setup_stream: NID=0x3, stream=0x0, channel=0, format=0x0
I can't make heads or tails of that; hopefully it means something to
you. I'll try compiling the RT vanilla kernel now and see if that
shows anything..
Thanks for the help.
On 6/18/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Sun, 2006-06-18 at 14:38 -0400, I. E.
Smith-Heisters wrote:
> >
> > Strange, Intel is no nice with OSS video drivers..
> >
>
> I don't think the video driver has anything at all to do with this.
Oh, no, I was referring, rather, to their OSS support of their 950
video chipset; I would think their linux-friendliness would extend to
their audio chipsets.
Intel is fine. They wrote and released a perfectly good HDA driver.
It's just that the vendors have a LOT of latitude to make small
variations on the chipset and they don't help with ALSA drivers.
It seems to work for many users but there are a lot of laptops that just
get no sound or bad sound.
>
> Can you post the output of "dmesg" after trying JACK in realtime mode?
>
Nothing in there. The following is exactly the same as it was before
trying to start jack.
[17179691.824000] ACPI: Video Device [VID] (multi-head: yes rom: no post: no)
[17179691.824000] ACPI: Video Device [VID2] (multi-head: yes rom: no post: no)
[17179695.124000] ppdev: user-space parallel port driver
[17179695.352000] apm: BIOS not found.
[17179698.448000] Bluetooth: L2CAP ver 2.8
[17179698.448000] Bluetooth: L2CAP socket layer initialized
[17179698.452000] Bluetooth: RFCOMM socket layer initialized
[17179698.452000] Bluetooth: RFCOMM TTY layer initialized
[17179698.452000] Bluetooth: RFCOMM ver 1.7
I tried compiling the RT kernel (just running the default Ubuntu
PREEMPT right now), but ran into some problems, so I'll have to play
with it some more.
Maybe you could recompile the standard Ubuntu kernel and enable ALSA
debugging?
Lee
22 Jun
22 Jun
2:37 p.m.
New subject: [linux-audio-user] fst-1.8 triggers wine-preloader processes using a lot of ram
Hi all,
ive made some more progress on the madi vst server.
now ive got following problem. i am planing on being
able to run a large amount of plugins as i route 64 channels
of audio i/o.
fst seems to start a dedicated wine-preloader process for every
plugin that is loaded. this causes my ram to decimate very
quickly and thats one thing i dont have a lot of. 512MB - Ramdisk
(running kind of an embedded system).
after starting 15 - 17 plug instances there is none
left obviously. is there a possibility of using only one shared wine
process or does anybody out there know a different work around to this
problem?
any help is welcome,
cheers,
..ben
--
-------------------
Benjamin Fabricius
German Student
Lawo AG
2:53 p.m.
New subject: [linux-audio-user] fst-1.8 triggers wine-preloader processes using a lot of ram
On Thu, 2006-06-22 at 18:37 +0200, Benjamin Fabricius wrote:
Hi all,
ive made some more progress on the madi vst server.
now ive got following problem. i am planing on being
able to run a large amount of plugins as i route 64 channels
of audio i/o.
fst seems to start a dedicated wine-preloader process for every
plugin that is loaded. this causes my ram to decimate very
quickly and thats one thing i dont have a lot of. 512MB - Ramdisk
(running kind of an embedded system).
after starting 15 - 17 plug instances there is none
left obviously. is there a possibility of using only one shared wine
process or does anybody out there know a different work around to this
problem?
kjetil's vstserver design works this way.
not totally sure what you're doing, but keep in mind that Muse put a lot
of effort into making this work reliably across many plugins. don't
expect to see this happen "easily".
6499
days inactive
6521
days old
linux-audio-user@lists.linuxaudio.org
35 comments
12 participants
participants (12)
-
Arnold Krille -
Benjamin Fabricius -
Christoph Eckert -
Florian Paul Schmidt -
I. E. Smith-Heisters -
Jack O'Quin -
Joachim -
Lee Revell -
Link Swanson -
Patrick Shirkey -
Paul Davis -
yves_p＠nnx.com