Hi,
I've been running 2.6.14-rt1 today. For the most part there seem to
be no changes for me from 2.6.14-rc5-rt3. One place I saw xruns
earlier is still there and I do not understand why this situation
should be able to create xruns.
I really think there is something to be learned from this problem.
The way I see it What's going on with Myth is completely separate from
what's going on with Jack, but Myth is causing xruns somehow.
1) I have Jack running. It is using sound card #2, my RME HDSP 9652. I
can run for hours and see no xruns.
2) I start MythTV using sound card #1. Within MythTV there are
essentially 3 types of operation:
a) Basic menus
b) Preview menu
c) Full screen video watching
What I'm seeing is that when using basic menus, or when watching
videos I get no xruns. However, if I'm in the preview menu I get an
xrun every few minutes. In the following snippet I started Jack and
ran for about 20 minutes with no problems. I was using MythTV and
watching videos. I spent very little time in the preview menu:
16:19:26.184 Server configuration saved to "/home/mark/.jackdrc".
16:19:26.185 Statistics reset.
16:19:26.411 Client activated.
16:19:26.412 Audio connection change.
16:19:26.415 Audio connection graph change.
16:20:34.918 Audio connection graph change.
16:20:34.977 Audio connection change.
16:20:37.842 Audio connection graph change.
At about 4:45PM I exited the videos and left Myth sitting in a preview
menu. In this mode Myth puts a small video screen in the bottom right
corner where oyu get a low quality picture so you can see what the
start of the program looks like. While sitting in this mode for about
45 minutes I got 10 xruns:
16:45:45.670 XRUN callback (1).
**** alsa_pcm: xrun of at least 0.663 msecs
16:47:41.697 XRUN callback (2).
**** alsa_pcm: xrun of at least 0.415 msecs
subgraph starting at qjackctl-8363 timed out (subgraph_wait_fd=17,
status = 0, state = Finished)
17:06:47.023 XRUN callback (3).
**** alsa_pcm: xrun of at least 0.781 msecs
**** alsa_pcm: xrun of at least 4.924 msecs
17:06:49.003 XRUN callback (1 skipped).
subgraph starting at qjackctl-8363 timed out (subgraph_wait_fd=17,
status = 0, state = Finished)
17:15:36.697 XRUN callback (5).
**** alsa_pcm: xrun of at least 0.831 msecs
**** alsa_pcm: xrun of at least 2.850 msecs
17:15:37.707 XRUN callback (1 skipped).
17:17:38.387 XRUN callback (7).
**** alsa_pcm: xrun of at least 0.617 msecs
subgraph starting at qjackctl-8363 timed out (subgraph_wait_fd=17,
status = 0, state = Finished)
17:18:52.275 XRUN callback (8).
**** alsa_pcm: xrun of at least 1.654 msecs
17:20:44.214 XRUN callback (9).
**** alsa_pcm: xrun of at least 0.664 msecs
17:28:00.610 XRUN callback (10).
**** alsa_pcm: xrun of at least 0.244 msecs
subgraph starting at qjackctl-8363 timed out (subgraph_wait_fd=17,
status = 0, state = Finished)
At this point I exited the preview menu and went to a higher level
menu and just let the machine sit in Myth for about 20 minutes. No
xruns: At about 5:50PM I went back into the preview menu and got an
xrun within 2 minutes:
17:51:59.548 XRUN callback (11).
**** alsa_pcm: xrun of at least 1.156 msecs
17:52:32.464 XRUN callback (12).
subgraph starting at qjackctl-8363 timed out (subgraph_wait_fd=17,
status = 0, state = Finished)
**** alsa_pcm: xrun of at least 1.326 msecs
Note that on this machine I can browse the web, transfer files via
the network, build kernels, do an emerge world, run cpuburn, etc., and
I get no xruns. However, if I run MythTV in the preview menu I get
them consistently.
Also note that the MythTV server is actually located over a
wireless connection. There is no wireless on my machine - the
connection is between the router and the machines in another part of
the house. I bring this up in case it indirectly bears upon the
networking, etc.
I look forward to hearing what you all think I should look at here.
I have not yet turned on the preempt debugging stuff. I'll work on
that after I hear back that I'm not wasting my time.
Thanks,
Mark
On Sun, 2005-10-30 at 18:28 -0800, Mark Knecht wrote:
> Hi,
> I've been running 2.6.14-rt1 today. For the most part there seem to
> be no changes for me from 2.6.14-rc5-rt3. One place I saw xruns
> earlier is still there and I do not understand why this situation
> should be able to create xruns.
>
> I really think there is something to be learned from this problem.
> The way I see it What's going on with Myth is completely separate from
> what's going on with Jack, but Myth is causing xruns somehow.
Some buggy video drivers can cause this.
Are you using a DRI driver? What video driver are you using?
Try setting:
Option "NoAccel"
in the Device section of your xorg.conf.
Lee
* Mark Knecht <[email protected]> wrote:
> What I'm seeing is that when using basic menus, or when watching
> videos I get no xruns. However, if I'm in the preview menu I get an
> xrun every few minutes. [...]
this could be some sort of hardware latency, as Lee suspects. Videocards
are known to be pretty agressively holding the system bus, for the last
few percentiles of Quake performance ... Also, mainboard chipsets are
sometimes not that good at enforcing fairness between DMA agents -
possibly starving the CPU itself for lengthly amounts of time. We have
seen such incidents before, and latency tracing ought to be able to show
this with reasonable certainty. If it's some sort of generic hardware
latency then you ought to see weird traces when enabling WAKEUP_TIMING
and LATENCY_TRACING in the .config. No need for any other debug options
or Jack level hackery at this point - just enable these and do a:
echo 0 > /proc/sys/kernel/preempt_max_latency
and try to trigger as large latencies as possible via MythTV. (you wont
necessarily see a large latency reported by the kernel when you see an
xrun. We can trace xruns too, but that needs Jackd changes and is more
effort to set up.)
Ingo
> Hi,
> I've been running 2.6.14-rt1 today. For the most part there seem to
> be no changes for me from 2.6.14-rc5-rt3. One place I saw xruns
> earlier is still there and I do not understand why this situation
> should be able to create xruns.
>
> I really think there is something to be learned from this problem.
> The way I see it What's going on with Myth is completely separate from
> what's going on with Jack, but Myth is causing xruns somehow.
>
> 1) I have Jack running. It is using sound card #2, my RME HDSP 9652. I
> can run for hours and see no xruns.
>
> 2) I start MythTV using sound card #1. Within MythTV there are
> essentially 3 types of operation:
>
> a) Basic menus
> b) Preview menu
> c) Full screen video watching
>
> What I'm seeing is that when using basic menus, or when watching
> videos I get no xruns. However, if I'm in the preview menu I get an
> xrun every few minutes. In the following snippet I started Jack and
> ran for about 20 minutes with no problems. I was using MythTV and
> watching videos. I spent very little time in the preview menu:
>
> 16:19:26.184 Server configuration saved to "/home/mark/.jackdrc".
> 16:19:26.185 Statistics reset.
> 16:19:26.411 Client activated.
> 16:19:26.412 Audio connection change.
> 16:19:26.415 Audio connection graph change.
> 16:20:34.918 Audio connection graph change.
> 16:20:34.977 Audio connection change.
> 16:20:37.842 Audio connection graph change.
>
> At about 4:45PM I exited the videos and left Myth sitting in a preview
> menu. In this mode Myth puts a small video screen in the bottom right
> corner where oyu get a low quality picture so you can see what the
> start of the program looks like. While sitting in this mode for about
> 45 minutes I got 10 xruns:
>
> 16:45:45.670 XRUN callback (1).
> **** alsa_pcm: xrun of at least 0.663 msecs
> 16:47:41.697 XRUN callback (2).
> **** alsa_pcm: xrun of at least 0.415 msecs
> subgraph starting at qjackctl-8363 timed out (subgraph_wait_fd=17,
> status = 0, state = Finished)
> 17:06:47.023 XRUN callback (3).
> **** alsa_pcm: xrun of at least 0.781 msecs
> **** alsa_pcm: xrun of at least 4.924 msecs
> 17:06:49.003 XRUN callback (1 skipped).
> subgraph starting at qjackctl-8363 timed out (subgraph_wait_fd=17,
> status = 0, state = Finished)
> 17:15:36.697 XRUN callback (5).
> **** alsa_pcm: xrun of at least 0.831 msecs
> **** alsa_pcm: xrun of at least 2.850 msecs
> 17:15:37.707 XRUN callback (1 skipped).
> 17:17:38.387 XRUN callback (7).
> **** alsa_pcm: xrun of at least 0.617 msecs
> subgraph starting at qjackctl-8363 timed out (subgraph_wait_fd=17,
> status = 0, state = Finished)
> 17:18:52.275 XRUN callback (8).
> **** alsa_pcm: xrun of at least 1.654 msecs
> 17:20:44.214 XRUN callback (9).
> **** alsa_pcm: xrun of at least 0.664 msecs
> 17:28:00.610 XRUN callback (10).
> **** alsa_pcm: xrun of at least 0.244 msecs
> subgraph starting at qjackctl-8363 timed out (subgraph_wait_fd=17,
> status = 0, state = Finished)
>
> At this point I exited the preview menu and went to a higher level
> menu and just let the machine sit in Myth for about 20 minutes. No
> xruns: At about 5:50PM I went back into the preview menu and got an
> xrun within 2 minutes:
>
> 17:51:59.548 XRUN callback (11).
> **** alsa_pcm: xrun of at least 1.156 msecs
> 17:52:32.464 XRUN callback (12).
> subgraph starting at qjackctl-8363 timed out (subgraph_wait_fd=17,
> status = 0, state = Finished)
> **** alsa_pcm: xrun of at least 1.326 msecs
>
> Note that on this machine I can browse the web, transfer files via
> the network, build kernels, do an emerge world, run cpuburn, etc., and
> I get no xruns. However, if I run MythTV in the preview menu I get
> them consistently.
>
> Also note that the MythTV server is actually located over a
> wireless connection. There is no wireless on my machine - the
> connection is between the router and the machines in another part of
> the house. I bring this up in case it indirectly bears upon the
> networking, etc.
>
> I look forward to hearing what you all think I should look at here.
>
> I have not yet turned on the preempt debugging stuff. I'll work on
> that after I hear back that I'm not wasting my time.
>
> Thanks,
> Mark
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
Mark,
If I am not mistaken, aren't you running the ivtv driver for your video
card (I think I have seen you on that list also)? Since that driver is
being developed outside the mainline kernel, isn't it likely that it
hasn't received many of the improvements that the rest of the kernel has
(latency and preemption wise)? Just a thought.
--
kr
On 10/31/05, K.R. Foley <[email protected]> wrote:
>
> > Hi,
> > I've been running 2.6.14-rt1 today. For the most part there seem to
> > be no changes for me from 2.6.14-rc5-rt3. One place I saw xruns
> > earlier is still there and I do not understand why this situation
> > should be able to create xruns.
> >
> > I really think there is something to be learned from this problem.
> > The way I see it What's going on with Myth is completely separate from
> > what's going on with Jack, but Myth is causing xruns somehow.
> >
> > 1) I have Jack running. It is using sound card #2, my RME HDSP 9652. I
> > can run for hours and see no xruns.
> >
> > 2) I start MythTV using sound card #1. Within MythTV there are
> > essentially 3 types of operation:
> >
> > a) Basic menus
> > b) Preview menu
> > c) Full screen video watching
> >
> > What I'm seeing is that when using basic menus, or when watching
> > videos I get no xruns. However, if I'm in the preview menu I get an
> > xrun every few minutes. In the following snippet I started Jack and
> > ran for about 20 minutes with no problems. I was using MythTV and
> > watching videos. I spent very little time in the preview menu:
> >
> > 16:19:26.184 Server configuration saved to "/home/mark/.jackdrc".
> > 16:19:26.185 Statistics reset.
> > 16:19:26.411 Client activated.
> > 16:19:26.412 Audio connection change.
> > 16:19:26.415 Audio connection graph change.
> > 16:20:34.918 Audio connection graph change.
> > 16:20:34.977 Audio connection change.
> > 16:20:37.842 Audio connection graph change.
> >
> > At about 4:45PM I exited the videos and left Myth sitting in a preview
> > menu. In this mode Myth puts a small video screen in the bottom right
> > corner where oyu get a low quality picture so you can see what the
> > start of the program looks like. While sitting in this mode for about
> > 45 minutes I got 10 xruns:
> >
> > 16:45:45.670 XRUN callback (1).
> > **** alsa_pcm: xrun of at least 0.663 msecs
> > 16:47:41.697 XRUN callback (2).
> > **** alsa_pcm: xrun of at least 0.415 msecs
> > subgraph starting at qjackctl-8363 timed out (subgraph_wait_fd=17,
> > status = 0, state = Finished)
> > 17:06:47.023 XRUN callback (3).
> > **** alsa_pcm: xrun of at least 0.781 msecs
> > **** alsa_pcm: xrun of at least 4.924 msecs
> > 17:06:49.003 XRUN callback (1 skipped).
> > subgraph starting at qjackctl-8363 timed out (subgraph_wait_fd=17,
> > status = 0, state = Finished)
> > 17:15:36.697 XRUN callback (5).
> > **** alsa_pcm: xrun of at least 0.831 msecs
> > **** alsa_pcm: xrun of at least 2.850 msecs
> > 17:15:37.707 XRUN callback (1 skipped).
> > 17:17:38.387 XRUN callback (7).
> > **** alsa_pcm: xrun of at least 0.617 msecs
> > subgraph starting at qjackctl-8363 timed out (subgraph_wait_fd=17,
> > status = 0, state = Finished)
> > 17:18:52.275 XRUN callback (8).
> > **** alsa_pcm: xrun of at least 1.654 msecs
> > 17:20:44.214 XRUN callback (9).
> > **** alsa_pcm: xrun of at least 0.664 msecs
> > 17:28:00.610 XRUN callback (10).
> > **** alsa_pcm: xrun of at least 0.244 msecs
> > subgraph starting at qjackctl-8363 timed out (subgraph_wait_fd=17,
> > status = 0, state = Finished)
> >
> > At this point I exited the preview menu and went to a higher level
> > menu and just let the machine sit in Myth for about 20 minutes. No
> > xruns: At about 5:50PM I went back into the preview menu and got an
> > xrun within 2 minutes:
> >
> > 17:51:59.548 XRUN callback (11).
> > **** alsa_pcm: xrun of at least 1.156 msecs
> > 17:52:32.464 XRUN callback (12).
> > subgraph starting at qjackctl-8363 timed out (subgraph_wait_fd=17,
> > status = 0, state = Finished)
> > **** alsa_pcm: xrun of at least 1.326 msecs
> >
> > Note that on this machine I can browse the web, transfer files via
> > the network, build kernels, do an emerge world, run cpuburn, etc., and
> > I get no xruns. However, if I run MythTV in the preview menu I get
> > them consistently.
> >
> > Also note that the MythTV server is actually located over a
> > wireless connection. There is no wireless on my machine - the
> > connection is between the router and the machines in another part of
> > the house. I bring this up in case it indirectly bears upon the
> > networking, etc.
> >
> > I look forward to hearing what you all think I should look at here.
> >
> > I have not yet turned on the preempt debugging stuff. I'll work on
> > that after I hear back that I'm not wasting my time.
> >
> > Thanks,
> > Mark
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
> >
>
> Mark,
>
> If I am not mistaken, aren't you running the ivtv driver for your video
> card (I think I have seen you on that list also)? Since that driver is
> being developed outside the mainline kernel, isn't it likely that it
> hasn't received many of the improvements that the rest of the kernel has
> (latency and preemption wise)? Just a thought.
> --
>
> kr
Hi,
No, the ivtv driver is running on a different machine. Not this
one. When I was speaking of MythTV here it's a frontend only machine.
True, I did try putting 2.6.14-rcX-rtY on my MythTV backend server
but the ivtv driver wouldn't compile so I axed it and left that
machine running a standard kernel. (Now running 2.6.14-gentoo)
So, this is a frontend only problem.
I'm going to do as Lee and Ingo suggest, now that I have a test
that seems to create xruns pretty qickly. Hopefully I'll capture
something of interest. However I'm questioning exactly what the video
problem would be since I don't create xruns when watching MythTV full
screen. Only get them when watching in this preview window. That said
it is an ATI PCI-Express card but since it's 2.6.14 there is no ATI
driver support. My kernel is currently trying to load fglrx (the ATI
driver) and failing since it doesn't support this kernel. I'll clean
up the video driver setup and retest.
Anyway, we'll see later today.
Thanks for all the responses.
Cheers,
Mark
> On 10/31/05, K.R. Foley <[email protected]> wrote:
>>
>> > Hi,
>> > I've been running 2.6.14-rt1 today. For the most part there seem to
>> > be no changes for me from 2.6.14-rc5-rt3. One place I saw xruns
>> > earlier is still there and I do not understand why this situation
>> > should be able to create xruns.
>> >
>> > I really think there is something to be learned from this problem.
>> > The way I see it What's going on with Myth is completely separate from
>> > what's going on with Jack, but Myth is causing xruns somehow.
>> >
>> > 1) I have Jack running. It is using sound card #2, my RME HDSP 9652. I
>> > can run for hours and see no xruns.
>> >
>> > 2) I start MythTV using sound card #1. Within MythTV there are
>> > essentially 3 types of operation:
>> >
>> > a) Basic menus
>> > b) Preview menu
>> > c) Full screen video watching
>> >
>> > What I'm seeing is that when using basic menus, or when watching
>> > videos I get no xruns. However, if I'm in the preview menu I get an
>> > xrun every few minutes. In the following snippet I started Jack and
>> > ran for about 20 minutes with no problems. I was using MythTV and
>> > watching videos. I spent very little time in the preview menu:
>> >
>> > 16:19:26.184 Server configuration saved to "/home/mark/.jackdrc".
>> > 16:19:26.185 Statistics reset.
>> > 16:19:26.411 Client activated.
>> > 16:19:26.412 Audio connection change.
>> > 16:19:26.415 Audio connection graph change.
>> > 16:20:34.918 Audio connection graph change.
>> > 16:20:34.977 Audio connection change.
>> > 16:20:37.842 Audio connection graph change.
>> >
>> > At about 4:45PM I exited the videos and left Myth sitting in a preview
>> > menu. In this mode Myth puts a small video screen in the bottom right
>> > corner where oyu get a low quality picture so you can see what the
>> > start of the program looks like. While sitting in this mode for about
>> > 45 minutes I got 10 xruns:
>> >
>> > 16:45:45.670 XRUN callback (1).
>> > **** alsa_pcm: xrun of at least 0.663 msecs
>> > 16:47:41.697 XRUN callback (2).
>> > **** alsa_pcm: xrun of at least 0.415 msecs
>> > subgraph starting at qjackctl-8363 timed out (subgraph_wait_fd=17,
>> > status = 0, state = Finished)
>> > 17:06:47.023 XRUN callback (3).
>> > **** alsa_pcm: xrun of at least 0.781 msecs
>> > **** alsa_pcm: xrun of at least 4.924 msecs
>> > 17:06:49.003 XRUN callback (1 skipped).
>> > subgraph starting at qjackctl-8363 timed out (subgraph_wait_fd=17,
>> > status = 0, state = Finished)
>> > 17:15:36.697 XRUN callback (5).
>> > **** alsa_pcm: xrun of at least 0.831 msecs
>> > **** alsa_pcm: xrun of at least 2.850 msecs
>> > 17:15:37.707 XRUN callback (1 skipped).
>> > 17:17:38.387 XRUN callback (7).
>> > **** alsa_pcm: xrun of at least 0.617 msecs
>> > subgraph starting at qjackctl-8363 timed out (subgraph_wait_fd=17,
>> > status = 0, state = Finished)
>> > 17:18:52.275 XRUN callback (8).
>> > **** alsa_pcm: xrun of at least 1.654 msecs
>> > 17:20:44.214 XRUN callback (9).
>> > **** alsa_pcm: xrun of at least 0.664 msecs
>> > 17:28:00.610 XRUN callback (10).
>> > **** alsa_pcm: xrun of at least 0.244 msecs
>> > subgraph starting at qjackctl-8363 timed out (subgraph_wait_fd=17,
>> > status = 0, state = Finished)
>> >
>> > At this point I exited the preview menu and went to a higher level
>> > menu and just let the machine sit in Myth for about 20 minutes. No
>> > xruns: At about 5:50PM I went back into the preview menu and got an
>> > xrun within 2 minutes:
>> >
>> > 17:51:59.548 XRUN callback (11).
>> > **** alsa_pcm: xrun of at least 1.156 msecs
>> > 17:52:32.464 XRUN callback (12).
>> > subgraph starting at qjackctl-8363 timed out (subgraph_wait_fd=17,
>> > status = 0, state = Finished)
>> > **** alsa_pcm: xrun of at least 1.326 msecs
>> >
>> > Note that on this machine I can browse the web, transfer files via
>> > the network, build kernels, do an emerge world, run cpuburn, etc., and
>> > I get no xruns. However, if I run MythTV in the preview menu I get
>> > them consistently.
>> >
>> > Also note that the MythTV server is actually located over a
>> > wireless connection. There is no wireless on my machine - the
>> > connection is between the router and the machines in another part of
>> > the house. I bring this up in case it indirectly bears upon the
>> > networking, etc.
>> >
>> > I look forward to hearing what you all think I should look at here.
>> >
>> > I have not yet turned on the preempt debugging stuff. I'll work on
>> > that after I hear back that I'm not wasting my time.
>> >
>> > Thanks,
>> > Mark
>> > -
>> > To unsubscribe from this list: send the line "unsubscribe
>> linux-kernel" in
>> > the body of a message to [email protected]
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>> > Please read the FAQ at http://www.tux.org/lkml/
>> >
>> >
>>
>> Mark,
>>
>> If I am not mistaken, aren't you running the ivtv driver for your video
>> card (I think I have seen you on that list also)? Since that driver is
>> being developed outside the mainline kernel, isn't it likely that it
>> hasn't received many of the improvements that the rest of the kernel has
>> (latency and preemption wise)? Just a thought.
>> --
>>
>> kr
>
> Hi,
> No, the ivtv driver is running on a different machine. Not this
> one. When I was speaking of MythTV here it's a frontend only machine.
>
> True, I did try putting 2.6.14-rcX-rtY on my MythTV backend server
> but the ivtv driver wouldn't compile so I axed it and left that
> machine running a standard kernel. (Now running 2.6.14-gentoo)
>
> So, this is a frontend only problem.
Sorry for the speculation.
>
> I'm going to do as Lee and Ingo suggest, now that I have a test
> that seems to create xruns pretty qickly. Hopefully I'll capture
> something of interest. However I'm questioning exactly what the video
> problem would be since I don't create xruns when watching MythTV full
> screen. Only get them when watching in this preview window. That said
> it is an ATI PCI-Express card but since it's 2.6.14 there is no ATI
> driver support. My kernel is currently trying to load fglrx (the ATI
> driver) and failing since it doesn't support this kernel. I'll clean
> up the video driver setup and retest.
>
> Anyway, we'll see later today.
>
> Thanks for all the responses.
>
> Cheers,
> Mark
--
K.R. Foley
[email protected]
On Mon, 2005-10-31 at 15:22 +0100, Ingo Molnar wrote:
> this could be some sort of hardware latency, as Lee suspects.
> Videocards are known to be pretty agressively holding the system bus,
> for the last few percentiles of Quake performance ... Also, mainboard
> chipsets are sometimes not that good at enforcing fairness between DMA
> agents - possibly starving the CPU itself for lengthly amounts of
> time. We have seen such incidents before, and latency tracing ought to
> be able to show this with reasonable certainty.
Ingo,
IIRC when I had this problem with the via X driver the latency traces
actually didn't show anything useful. The disk controller induced DMA
starvation problems did show up in the tracer.
Lee
On Mon, 2005-10-31 at 07:26 -0800, Mark Knecht wrote:
> I'm going to do as Lee and Ingo suggest, now that I have a test
> that seems to create xruns pretty qickly. Hopefully I'll capture
> something of interest. However I'm questioning exactly what the video
> problem would be since I don't create xruns when watching MythTV full
> screen. Only get them when watching in this preview window. That said
> it is an ATI PCI-Express card but since it's 2.6.14 there is no ATI
> driver support. My kernel is currently trying to load fglrx (the ATI
> driver) and failing since it doesn't support this kernel. I'll clean
> up the video driver setup and retest.
Please try my first suggestion, just set Option "NoAccel" to the Device
section of your xorg.conf.
Lee
On 10/31/05, Lee Revell <[email protected]> wrote:
> On Mon, 2005-10-31 at 07:26 -0800, Mark Knecht wrote:
> > I'm going to do as Lee and Ingo suggest, now that I have a test
> > that seems to create xruns pretty qickly. Hopefully I'll capture
> > something of interest. However I'm questioning exactly what the video
> > problem would be since I don't create xruns when watching MythTV full
> > screen. Only get them when watching in this preview window. That said
> > it is an ATI PCI-Express card but since it's 2.6.14 there is no ATI
> > driver support. My kernel is currently trying to load fglrx (the ATI
> > driver) and failing since it doesn't support this kernel. I'll clean
> > up the video driver setup and retest.
>
> Please try my first suggestion, just set Option "NoAccel" to the Device
> section of your xorg.conf.
Too bad I didn't remember that from last evening. Sorry.
Anyway, I've switched to the Xorg-X11 radeon driver and have been
running about 20 minutes in the preview mode. No xruns so far so
that's an improvement over last evening. This is at 64/2, so sub-3mS:
09:10:31.830 /usr/bin/jackd -R -P80 -p512 -dalsa -dhw:1 -r44100 -p64 -n2
09:10:31.842 JACK was started with PID=8175 (0x1fef).
jackd 0.100.5
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.
loading driver ..
apparent rate = 44100
creating alsa driver ... hw:1|hw:1|64|2|44100|0|0|nomon|swmeter|-|32bit
control device hw:1
configuring for 44100Hz, period = 64 frames, buffer = 2 periods
nperiods = 2 for capture
nperiods = 2 for playback
09:10:33.858 Server configuration saved to "/home/mark/.jackdrc".
09:10:33.859 Statistics reset.
09:10:34.022 Client activated.
09:10:34.023 Audio connection change.
09:10:34.027 Audio connection graph change.
09:10:36.942 Audio connection graph change.
09:10:37.038 Audio connection change.
09:10:39.062 Audio connection graph change.
mark@lightning ~ $ date
Mon Oct 31 09:32:36 PST 2005
mark@lightning ~ $
Last evening I would have had 5-10 xruns by now.
I'm kicking myself for not cleaning that up earlier. It's one of those
lingering things about ATI drivers and testing new kernels. You load
fglrx because you're running 2.6.13 and it works. You jump to a
testing kernel and the ATI drivers don't support it but you go on
leaving the fglrx call in, and you see the driver load fail at boot
time. I got lazy and never cleaned it up.
My bad...
I wish modprobe.conf was in /lib/modules/XXX so that the modules
loaded could be changed from kernel to kernel.
Anyway, better and better. We'll see how today goes.
Thanks!
- Mark
On 10/31/05, Lee Revell <[email protected]> wrote:
> On Mon, 2005-10-31 at 07:26 -0800, Mark Knecht wrote:
> > I'm going to do as Lee and Ingo suggest, now that I have a test
> > that seems to create xruns pretty qickly. Hopefully I'll capture
> > something of interest. However I'm questioning exactly what the video
> > problem would be since I don't create xruns when watching MythTV full
> > screen. Only get them when watching in this preview window. That said
> > it is an ATI PCI-Express card but since it's 2.6.14 there is no ATI
> > driver support. My kernel is currently trying to load fglrx (the ATI
> > driver) and failing since it doesn't support this kernel. I'll clean
> > up the video driver setup and retest.
>
> Please try my first suggestion, just set Option "NoAccel" to the Device
> section of your xorg.conf.
>
> Lee
Well, unfortuantely, after working along for quite a while with no
problems I ran into another rash of xruns:
13:30:42.524 Audio connection graph change.
subgraph starting at qjackctl-9003 timed out (subgraph_wait_fd=17,
status = 0, state = Finished)
13:49:44.441 XRUN callback (1).
**** alsa_pcm: xrun of at least 1.575 msecs
subgraph starting at qjackctl-9003 timed out (subgraph_wait_fd=17,
status = 0, state = Finished)
13:53:54.253 XRUN callback (2).
**** alsa_pcm: xrun of at least 0.889 msecs
**** alsa_pcm: xrun of at least 8.928 msecs
13:53:56.006 XRUN callback (1 skipped).
subgraph starting at qjackctl-9003 timed out (subgraph_wait_fd=17,
status = 0, state = Finished)
13:58:39.856 XRUN callback (4).
**** alsa_pcm: xrun of at least 0.669 msecs
subgraph starting at qjackctl-9003 timed out (subgraph_wait_fd=17,
status = 0, state = Finished)
14:40:37.943 XRUN callback (5).
**** alsa_pcm: xrun of at least 1.056 msecs
subgraph starting at qjackctl-9003 timed out (subgraph_wait_fd=17,
status = 0, state = Finished)
14:53:54.885 XRUN callback (6).
**** alsa_pcm: xrun of at least 0.713 msecs
**** alsa_pcm: xrun of at least 28.928 msecs
14:53:56.711 XRUN callback (1 skipped).
In this case I was not using MythTV. I was building some code as part
of an emerge world, playing some music off a 1394 drive, and chatting
on the Gentoo-ppc IRC.
It seems that my system is not there quite yet.
I took a quick look. If you get a chance where does the NoAccel option
go? Inside of the section for the radeon driver? I'm sure I can find
this online but won't have much of an opportunity for the next few
hours.
Cheers,
Mark
Mark Knecht wrote:
[..]
> I took a quick look. If you get a chance where does the NoAccel option
> go? Inside of the section for the radeon driver? I'm sure I can find
> this online but won't have much of an opportunity for the next few
> hours.
IMHO this wont matter because, IIRC, the preview window in mythtv
doesn't even use xv... It's a straight x11 bitmap beeing drawn, after
scaling (so it's very CPU intensive... It's like having the HDD without
DMA enabled).
If the -rt series should work alright without DMA in the disks or with
mplayer -vo x11 or with myth's preview it's another issue :-)
Btw, test for xruns with "mplayer -vo x11 movie.mpg" if you can.
Regards,
Nuno Silva
On Tue, 2005-11-01 at 01:48 +0000, Nuno Silva wrote:
> Mark Knecht wrote:
>
> [..]
>
> > I took a quick look. If you get a chance where does the NoAccel option
> > go? Inside of the section for the radeon driver? I'm sure I can find
> > this online but won't have much of an opportunity for the next few
> > hours.
>
> IMHO this wont matter because, IIRC, the preview window in mythtv
> doesn't even use xv... It's a straight x11 bitmap beeing drawn, after
> scaling (so it's very CPU intensive... It's like having the HDD without
> DMA enabled).
Does not matter, a buggy 2D XAA implementation can stall the PCI bus and
produce xruns. I had an almost identical problem about a year ago with
the via driver and the gmplayer "splash screen" was the most reliable
way to trigger xruns.
Lee
On Tue, 2005-11-01 at 01:48 +0000, Nuno Silva wrote:
> Mark Knecht wrote:
>
> [..]
>
> > I took a quick look. If you get a chance where does the NoAccel option
> > go? Inside of the section for the radeon driver? I'm sure I can find
> > this online but won't have much of an opportunity for the next few
> > hours.
>
Yes, in the "Device" section.
Try "man radeon" for more info, but it's something like:
Section "Device"
Identifier "devname"
Driver "radeon"
...
Option "NoAccel"
...
etc
Lee