| Summary: | [945GM] Latest stable driver causes jack xruns | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Ray Rashif <schivmeister> |
| Component: | Driver/intel | Assignee: | Jesse Barnes <jbarnes> |
| Status: | RESOLVED INVALID | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | Keywords: | NEEDINFO |
| Version: | 7.4 (2008.09) | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
Current workarounds (thanks to Jesse, and Dominic from LAU for the confirmation of these):
== Partial ==
# /etc/X11/xorg.conf
...
Section "Device"
Identifier "Intel GMA 950"
Option "SwapbuffersWait" "false"
EndSection
...
#
This one only decreases the amount of xruns, i.e only 1 xrun per set of minimising events instead of say, 1 for every minimise and de-minimise action. As such, problem is still there and it's significant.
Stopping compositing via the WM (eg. KWin Effects; ALT+SHIFT+F12) also triggers a burst of these underruns.
== Full ==
Downgrade to xf86-video-intel 2.7.1 and use an older renderer:
# /etc/X11/xorg.conf
...
Section "Device"
Identifier "Intel GMA 950"
Option "RenderAccel" "EXA"
EndSection
...
#
With this method, no more xruns but you have to live with the theoretically-sub-optimal 2D rendering.
I believe this can be confirmed as a UXA side-effect. Whether a bug or not, or simply a result of a method (eg. the new type of buffering) which _needs_ to be used, is left to the developers to decide.
Oops, major typo above:
s/RenderAccel/AccelMethod/
# /etc/X11/xorg.conf
...
Section "Device"
Identifier "Intel GMA 950"
Option "AccelMethod" "EXA"
EndSection
...
#
So both of those options will affect how long the X server will block for. It could be blocked for other reasons though too, so it's probably a bad idea to have clients that depend on getting X time in order to stream audio. Do you know which clients are waiting for X before processing audio data? If it's just X applications, I would expect them to have trouble writing to jackd if the server was blocked, but you may be able to increase the buffering size to avoid that? There shouldn't be any such clients (even if there are it shouldn't be a significant amount of time to trigger this), at least not those communicating with jackd. The xruns occur without any client, i.e on server idle - as long as there are window manager events like minimising, moving, switching desktops etc. Buffer size has no effect; tested from 128 to 1024 (anything beyond that is not practical for ADC/DAC). The only cause for this should be the new buffering in UXA, or something else, but definitely UXA-related. I will see if latencytop provides anything useful, though I doubt it. Any update here? If you think my theory about the X server is wrong, then it must be something in the kernel blocking your jackd process... timeout |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Chipset: Mobile 945GM GPU: GMA 950 Hardware: Compaq Presario V3000 (Intel Core Duo 1.60GHz, 2GB RAM) OS Distribution: Arch Linux i686 Environment: KDE 4.3.1 HAL: Yes (input hotplugging) Xorg Conf: No, Yes (for disabling compositing) == Issue == From 2.7.99 all the way up to 2.8.1, the driver (regardless of compositing, DRI, KSM etc.) appears to be more ambitious in that it causes buffer underruns in an environment running (realtime) priority threads. The older driver version tested NOT to exhibit this and working fine: 2.3.2 == Reproduction == Realtime is not necessary for this to occur, but to enable and test it one has to have the following ammendments to the system: # /etc/security/limits.conf ... @audio - rtprio 99 @audio - memlock unlimited ... # And be sure to be in the "audio" group by ensuring: # /etc/group ... audio::92:$username ... # Install and run jack (jack audio connection kit) as per the following with hw:0 being your onboard audio chipset: /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p256 -n3 Then open a file manager (preferably Dolphin in KDE) window and rapidly minimise and restore it. Notice the "xruns" reported by jackd. In a normal and healthy system, there should no such xruns triggered by WM/DE events. == IRQs == 0: 5382427 7 IO-APIC-edge timer 1: 17540 0 IO-APIC-edge i8042 8: 134 0 IO-APIC-edge rtc0 9: 3888 0 IO-APIC-fasteoi acpi 12: 3582967 0 IO-APIC-edge i8042 14: 181280 0 IO-APIC-edge ata_piix 15: 0 0 IO-APIC-edge ata_piix 16: 1161653 0 IO-APIC-fasteoi uhci_hcd:usb5, ohci1394, i915@pci:0000:00:02.0 18: 0 0 IO-APIC-fasteoi mmc0 19: 142613 0 IO-APIC-fasteoi uhci_hcd:usb3 21: 0 0 IO-APIC-fasteoi uhci_hcd:usb4 22: 2716333 0 IO-APIC-fasteoi HDA Intel 23: 9139 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2 27: 58345 0 PCI-MSI-edge ahci NMI: 0 0 Non-maskable interrupts LOC: 1702943 3712485 Local timer interrupts SPU: 0 0 Spurious interrupts RES: 3381732 4506213 Rescheduling interrupts CAL: 92 224 Function call interrupts TLB: 107818 952618 TLB shootdowns TRM: 0 0 Thermal event interrupts ERR: 3 MIS: 0