Created attachment 164381 [details] Software Dependencies for Paprefs + ALSA THIS BUG IS ALSO FOUND ON UBUNTU'S LAUNCHPAD SITE: https://bugs.launchpad.net/ubuntu/+source/paprefs/+bug/1409100 When either listening to music, watching a movie, viewing Youtube on Chrome, using *any* application, if I have Simultaneous Output enabled, the resulting audio output is generally delayed on one sound card from the other, and I cannot seem to find a viable way to fix this. All speakers are equally far from the user, so the speed of sound travelling has nothing to do with this to my best estimations. What could it be that is causing these issues? Attached is a HardInfo report of my Ubuntu PC. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: paprefs 0.9.10-1 ProcVersionSignature: Ubuntu 3.16.0-28.38-lowlatency 3.16.7-ckt1 Uname: Linux 3.16.0-28-lowlatency x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Fri Jan 9 14:23:38 2015 InstallationDate: Installed on 2014-11-08 (62 days ago) InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1) ProcEnviron: LANGUAGE=en_US PATH=(custom, no user) XDG_RUNTIME_DIR=<set> LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: paprefs UpgradeStatus: No upgrade log present (probably fresh install)
Created attachment 164401 [details] HardInfo Report (HTML FILE) Here is a hardinfo report done from the time the bug was originally files. Please note even today with the latest updates for Ubuntu, I still have the same sound issue.
Unless all sound boards share the same clock, there are always drift between them after some time. It's unavoidable, and it's no sound driver problem. If you have some professional boards with the clock sync feature, they sholuld be able to perfectly sync with each other. The upper layer audio stack can resample the sample rate on the fly in order to match with the other clock source (a la PLL), but I doubt whether PA does it.
Could there be a clock rate sync added to the kernel that uses the CPU/APU as the middleman per-say, to tell the Southbridge (AMD SB710 in my machine to be exact) to designate audio accordingly to both devices by delaying the output so-slightly via one bus compared to the other that is obviously faster? A delay mechanism like this could be an efficient bypass standard if perfected.
Created attachment 164411 [details] NEW HardInfo Report - January 22, 2015 Here is an updated HardInfo report on my machine taken from today, January 22, 2015 at ~8:40AM EST after new system updates. The issue still occurs, nevertheless.
It's not about CPU clock.
I know it's not. But the CPU designates what processes go where.
Sound cards have own oscillators on them...