Description of problem: Updated to F15. Tried watching videos such as Flash or others. Latency is through the roof. Output of pactl list on the client machine: Sink #1 State: RUNNING Name: tunnel.paola.local.alsa_output.pci-0000_00_1b.0.analog-stereo Description: Internal Audio Analog Stereo on pulse Driver: module-tunnel.c Sample Specification: s16le 2ch 44100Hz Channel Map: front-left,front-right Owner Module: 15 Mute: no Volume: 0: 100% 1: 100% balance 0.00 Base Volume: 100% Monitor Source: tunnel.paola.local.alsa_output.pci-0000_00_1b.0.analog-stereo.monitor Latency: 9774928030 usec, configured 250000 usec Flags: NETWORK HW_MUTE_CTRL HW_VOLUME_CTRL LATENCY Properties: device.description = "Internal Audio Analog Stereo on pulse" tunnel.remote.server = "[10.254.102.1]:4713" tunnel.remote.sink = "alsa_output.pci-0000_00_1b.0.analog-stereo" device.icon_name = "audio-card" tunnel.remote_version = "16" tunnel.remote.user = "pulse" tunnel.remote.fqdn = "paola.dragonfear" tunnel.remote.description = "Internal Audio Analog Stereo" I can verify it's PA. If I use my local audio device, the extreme choppiness and lag of playing videos disappears. So does skype. Problem is circumscribed to tunnels autodiscovered. This is the info of pactl list on the machine that is serving the audio sink: Sink #0 State: RUNNING Name: alsa_output.pci-0000_00_1b.0.analog-stereo Description: Internal Audio Analog Stereo Driver: module-alsa-card.c Sample Specification: s16le 2ch 44100Hz Channel Map: front-left,front-right Owner Module: 0 Mute: no Volume: 0: 100% 1: 100% 0: 0.00 dB 1: 0.00 dB balance 0.00 Base Volume: 100% 0.00 dB Monitor Source: alsa_output.pci-0000_00_1b.0.analog-stereo.monitor Latency: 24902 usec, configured 24988 usec Flags: HARDWARE HW_MUTE_CTRL HW_VOLUME_CTRL DECIBEL_VOLUME LATENCY Properties: alsa.resolution_bits = "16" device.api = "alsa" device.class = "sound" alsa.class = "generic" alsa.subclass = "generic-mix" alsa.name = "ALC887 Analog" alsa.id = "ALC887 Analog" alsa.subdevice = "0" alsa.subdevice_name = "subdevice #0" alsa.device = "0" alsa.card = "0" alsa.card_name = "HDA Intel" alsa.long_card_name = "HDA Intel at 0xfeaf8000 irq 27" alsa.driver_name = "snd_hda_intel" device.bus_path = "pci-0000:00:1b.0" sysfs.path = "/devices/pci0000:00/0000:00:1b.0/sound/card0" device.bus = "pci" IE on the sink machine, very low latency.
Packages on sink machine: [rudd-o@paola ~]$ rpm -qa | grep pulse pulseaudio-libs-glib2-0.9.21-7.fc13.x86_64 pulseaudio-libs-glib2-0.9.21-6.fc13.x86_64 pulseaudio-utils-0.9.21-7.fc13.i686 pulseaudio-libs-0.9.21-6.fc13.x86_64 pulseaudio-module-zeroconf-0.9.21-7.fc13.x86_64 pulseaudio-libs-0.9.21-7.fc13.x86_64 pulseaudio-0.9.21-7.fc13.x86_64 pulseaudio-libs-0.9.21-7.fc13.i686 pulseaudio-utils-0.9.21-7.fc13.x86_64 Packages on client machine: pulseaudio-utils-0.9.22-5.fc15.i686 pulseaudio-esound-compat-0.9.22-5.fc15.x86_64 pulseaudio-module-gconf-0.9.22-5.fc15.x86_64 pulseaudio-debuginfo-0.9.22-5.fc15.x86_64 pulseaudio-libs-0.9.22-5.fc15.x86_64 pulseaudio-0.9.22-5.fc15.x86_64 pulseaudio-libs-devel-0.9.22-5.fc15.x86_64 pulseaudio-module-jack-0.9.22-5.fc15.x86_64 alsa-plugins-pulseaudio-1.0.24-2.fc15.i686 pulseaudio-libs-glib2-0.9.22-5.fc15.i686 wine-pulseaudio-1.3.20-1.fc15.i686 pulseaudio-utils-0.9.22-5.fc15.x86_64 pulseaudio-module-x11-0.9.22-5.fc15.x86_64 xmms-pulse-0.9.4-9.fc15.x86_64 pulseaudio-module-zeroconf-0.9.22-5.fc15.x86_64 kde-settings-pulseaudio-4.6-10.fc15.noarch alsa-plugins-pulseaudio-1.0.24-2.fc15.x86_64 pulseaudio-gdm-hooks-0.9.22-5.fc15.x86_64 pulseaudio-libs-glib2-0.9.22-5.fc15.x86_64 pulseaudio-module-bluetooth-0.9.22-5.fc15.x86_64 pulseaudio-libs-zeroconf-0.9.22-5.fc15.x86_64 pulseaudio-libs-0.9.22-5.fc15.i686
I have made a VERY WEIRD discovery. There's about 1.4 megabits per second being casted from the source machine to the target machine through the pulseaudio port. I attach screenshots: http://imgur.com/qz82f WTF. There are no clients connected to my local pulseaudio server save for paman, and no clients that I know about on the remote machine.
Why is this thing transmitting audio data when no audio is even playing and no applications are using the tunnel??????
I discovered suspend-on-idle module was not enabled on the client side. When it is enabled, miraculously pulseaudio stops broadcasting audio when there is silence on my laptop. Let me see if that fixes the latency issues.
Nope. Didn'tmake a difference after daemon restarts on both sides. Addendum: after upgrading to F15, now there is about 1.5 mbit/s traffic on BOTH directions, even though the microphone is not in use from the client. How can this bug ship in the stable release of the distro? Is there no test plan to check for this?
module-suspend-on-idle made no difference. what more info can I provide?
Could it be because of clock drift???
I ntpdated both machines and the problem with the player freezing corrected itself. The silence network traffic, however, did not. Why is PA using local time for the purposes of sync between network machines, instead of monotonic time or something like that???
PA applications playing audio through the tunnel still stutter horribly. Much less than before, but at least two or three times in each song. What is going on here?
If I play a second sound while the stutter is happening on my primary music player, the stutter happens on the second sound at the same time with the same gaps at the same instant. This means there is something going wrong with the PulseAudio timing.
I have successfully correlated the dropouts to periodic packet losses on my wireless network. The periodic dropouts do not present themselves when I am using a LAN cable. The timing / clock drift bug, and the permanent stream of traffic even when completely silent and no client bug, remain.
OK, the problem was wallclock drift. When the wallclock drifts, the latency goes up and up and up and up. I fixed this by using ntpd clock skew on both machines. Nevertheless, this is new behavior that was introduced after the update to Fedora 15 (perhaps different kernel mechanisms for keeping time). The periodic interruptions I experienced in the bug reported above are basically wireless scans performed by NetworkManager. I am going to close this.
I am going to reopen this. With PulseAudio server and module-tunnel on the client, Flash lipsync is screwed. Time sync is peachy: ~@karen.dragonfear α: /usr/lib/nagios/plugins/check_ntp -H paola NTP OK: Offset -0.004631400108 secs|offset=-0.004631s;60.000000;120.000000;
This bug is currently assigned to an unsupported release. If you think this bug is still valid and should remain open, please re-assign it to a supported release (F22, F23) or to rawhide. Bugs which will be assigned to an unsupported release are going to be closed as EOL (End Of Life) on January 26th, 2016.