vlc 2.0.5 changelog:
ยท Fix playback initial synchronization with PulseAudio (however similar bugs in PulseAudio version 2.0 and later still exist)
#default-sample-rate = 44100
]]>I noticed this when playing videos online, and initially thought it was Flash screwing up, but a restart of the pulseaudio daemon seems to temporarily fix it. (Interesting thing though -- On Firefox, HTML5 videos slow down while Flash based videos speed up, while on Chrome, all audio/video speeds up.)
I'm definitely not sure how pulseaudio works, but my uneducated guess would be that pulseaudio is providing every other audio frame, as slowing down the video by 1/2 (according to YouTube's HTML5 player settings) provided an almost normal A/V speed (although audio quality was definitely lacking).
Nonetheless, the only workaround that has been working for me is to restart pulseaudio. The command "pulseaudio -k" is sufficient for me, as the daemon automatically restarts afterward. Upon this restart, audio and video speeds return back to normal, and remain the same way for some random amount of time (as low as 5 minutes and as high as 3 hours in my case).
tl;dr: I blame pulseaudio for this.
]]>As mentioned, this morning the streaming worked exceptionally well. Turns out that the remote pulseaudio-process is to blame. (That is the process where the playback occurs).
After restarting the remote process the streaming works for some time (5 to 45 minutes). I gathered some abnormal debug-output which occurs exactly at the moment of the playback-gap (and pitch shift).
first gap:
D: [alsa-sink] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink] ratelimit.c: 25 events suppressed
another gap:
D: [alsa-sink] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink] flist.c: pulsecore/memblockq.c: list_items flist is full (don't worry)
D: [alsa-sink] ratelimit.c: 13 events suppressed
Well.. any thoughts?
]]>New hypothesis: The problem is the same with vlc and mplayer, but it manifests itself different:
mplayer keeps the playback speed but it is slightly wrong and so it sometimes skips.
vlc adjusts the playback speed but it doesn't match up in the other direction and it skips and the speed is adjusted.Does that make sense?
Hm, that would raise the question, why is the playback speed wrong?
The only time I ever heard of pitch problems like that is resampling problems. I think pulseaudio defaults to 44100. Are you guys running vlc with 48000? Maybe it can't stream smoothly because it can't keep the cache full and resample on the other end fast enough?
I adjusted this setting two days ago to 44100 in vlc, no change.
Wah, something weird is going on this morning. Had no skips since 15 minutes or so..
]]>mplayer keeps the playback speed but it is slightly wrong and so it sometimes skips.
vlc adjusts the playback speed but it doesn't match up in the other direction and it skips and the speed is adjusted.
Does that make sense?
]]>plus not wanting to deal with the usual lolpulse attitude you exhibit unfortunately prevents indepth assistance.
Good luck, and if I do figure out something I'll post it for ya. I've heard occasional skipping if I do funny things to my network, but nothing unexplicable and consistent and definitely nothing involving pitch changing ...
My attitude towards pulseaudio would be much better if it would work as advertised.
Interestingly, for vlc with --log-level=debug on the server I get no output for the skips.
But mplayer skips produce this on the server:
D: [alsa-sink] protocol-native.c: Underrun on 'Internes Audio Analog Stereo for chris@chrisl', 0 bytes in queue.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Underrun on 'Internes Audio Analog Stereo for chris@chrisl', 0 bytes in queue.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Underrun on 'Internes Audio Analog Stereo for chris@chrisl', 0 bytes in queue.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Underrun on 'Internes Audio Analog Stereo for chris@chrisl', 0 bytes in queue.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Underrun on 'Internes Audio Analog Stereo for chris@chrisl', 0 bytes in queue.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Underrun on 'Internes Audio Analog Stereo for chris@chrisl', 0 bytes in queue.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Underrun on 'Internes Audio Analog Stereo for chris@chrisl', 0 bytes in queue.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Underrun on 'Internes Audio Analog Stereo for chris@chrisl', 0 bytes in queue.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Underrun on 'Internes Audio Analog Stereo for chris@chrisl', 0 bytes in queue.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Underrun on 'Internes Audio Analog Stereo for chris@chrisl', 0 bytes in queue.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
Ping says the latency is < 3 ms, iperf says the bandwidth is > 20 mbit.
Does that mean that actually my alsa driver on the client is buggy?
]]>Anyway, I'm using a solid cable, so that surely is not a bandwith issue.
It seems this issue is related to vlc since neither for me nor for you it appears with mplayer.
I played a bit with vlc's config and I found a setting which seems related (altough I cannot explain it at all). It's called "File caching (ms)" in the "Input/Codecs"-section. Lowering the time increases the skip rate, but the gap is smaller (and the pitch drop is smaller). Increasing the time lowers the skip rate but the gap and the pitch drop are huge. However, both options are not really something what is called 'workaround'.
Maybe playing a little bit more with some settings could help us.
greets.
]]>Good luck, and if I do figure out something I'll post it for ya. I've heard occasional skipping if I do funny things to my network, but nothing unexplicable and consistent and definitely nothing involving pitch changing ...
]]>smplayer has slight skipping, probably because pulseaudio skill can't manage even the latency over wifi automatically, but it sounds correct. VLC has the regular skipping + pitch dropping and sometimes it keeps stuttering for 1-2 seconds.
Also, when changing the sound device to a network sink while playing may make the player stop outputting sound or even stop progressing the progress bar.
Network transparency: Still not even the most simple use case is not ready for normal use after all this time. But who knows, maybe pulseaudio "2.0" will work the way we have been promised from the beginning how it'd work.
]]>I'm not an archer and using gentoo, but I experience exactly the same issue when playing music with 'Tomahawk' (which uses phonon with vlc-backend) over a pulseaudio network 'tunnel'.
Can you reproduce the problem with another player as well?
My Pulseaudio version is 1.99.2. Which one are you using?
My theory is, that this may be kinda syncing problem:
Perhaps the playback speed gets out of control (too fast), then pulseaudio syncs and since it played too fast, there is a playback gap. The speed gets resetted; therefore the audio pitch drops.
This is of course very questionable.
greetings
]]>So in the year 2012 pulseaudio over network is still not working well.
For example, this is vlc on my laptop and pulseaudio on my laptop sending the sound to a netbook with speakers:
http://ompldr.org/vY3d3ZQ (sorry for bad quality)
This skipping happens about once per minute and is quite annoying, even more since the pitch of the audio drops quite audible?!
Any ideas?
]]>