Yes, that's going to be a driver problem, it sounds they got the clocking wrong and it is running at 48kHz rather than 44.1kHz or similar.
I was trying to point out that the audio skipping only happens on analog, and only when the CPU load isn high enough / maxed. That should rule out a sampling rate mismatch.
The thing in Linux is basically all the drivers are built in to the distribution, generally motherboard and chipset manufacturers don't care about Linux. At most they will give the specs to the driver writers, but normally the driver writers are reverse engineering the hardware. What is the chipset and driver? There may be an option on the command line to fix this e.g. by forcing the clock rate to a particular value, or a Google search for that motherboard, Linux and sound may help.
The motherboard is an ASUS H97I-Plus
, and its audio chipset is a Realtek ALC887-VD. There's no update driver on ASUS' site, and Realtek doesn't seem to acknowledge the existance of an 887 chipset, yet. (May be a custom IC for ASUS.)
just brew it! wrote:
Wow, weird. I haven't personally seen that sort of audio issue in the past 2-3 years; unless you've got a very new audio chipset (or one of the poorly supported Creative ones) things generally "just work" these days.
In the past I've seen some squirrely behavior with timing when the motherboard/BIOS has a buggy ACPI timer implementation, and the Linux kernel chooses (not sure how it decides) to use the ACPI timer as its high-resolution timing source. Could also be a bad interaction between the audio driver and the CPU's power management; that would explain why it depends on CPU load.
Things to try --
- Update to latest BIOS if you aren't already at the latest version.
I'm fairly certain it's the second most up to date version, the latest only adding overclocking features
. The CPU is an i7-4790S
, so I saw no benefit in installing the new BIOS version.
- Temporarily disable CPU power management in your BIOS to see if that has any effect.
There were a lot of clocking related settings in this BIOS. I'll try changing them when I get a chance.
- If you have both onboard and a discrete soundcard, try temporarily removing the one you're not using (if you're using discrete disable the onboard in the BIOS; if you're using onboard, remove the discrete card).
Nothing discrete, yet, unless you want to count the HDA (HDMI audio) on the GeForce, and the issue was present before installing that.
- If you can figure out what audio chipset you've got we may be able to get a better handle on your issue. Run alsamixer in a terminal window; this should tell you what audio chipset the system thinks you have (and if it comes up as generic then we know a chipset-specific driver was not included in the distro you installed).
- Post the contents of the files /sys/devices/system/clocksource/clocksource0/available_clocksource and /sys/devices/system/clocksource/clocksource0/current_clocksource so I can have a look at them. Depending on what your motherboard supports and what the kernel is selecting by default, it might be worth trying to force the use of a different high-resolution timing device.
tsc hpet acpi_pm
[addendum]I was seeing a behavior in the system monitor I never witnessed before. The cores were playing hot-potato with a 95%-100% utilization thread, cycling through them out of order. I only noticed it with one game so far (Red Eclipse) so I don't know if other applications are being treated the same.