Bug 23739

Summary: [945GM] Latest stable driver causes jack xruns
Product: xorg Reporter: Ray Rashif <schivmeister>
Component: Driver/intelAssignee: 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:

Description Ray Rashif 2009-09-06 02:37:11 UTC
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
Comment 1 Ray Rashif 2009-09-13 03:41:58 UTC
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.
Comment 2 Ray Rashif 2009-09-13 04:07:28 UTC
Oops, major typo above:

s/RenderAccel/AccelMethod/

# /etc/X11/xorg.conf
...
Section "Device"
        Identifier      "Intel GMA 950"
        Option          "AccelMethod"       "EXA"
EndSection
...
#
Comment 3 Jesse Barnes 2009-11-20 13:13:06 UTC
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?
Comment 4 Ray Rashif 2009-11-24 09:48:29 UTC
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.
Comment 5 Jesse Barnes 2010-02-11 09:51:44 UTC
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...
Comment 6 Jesse Barnes 2010-04-06 11:29:09 UTC
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.