Pulseaudio over network - Skipping with dropping pitch

Cdh · 2012-03-02 22:29:59

Hi Archers,

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?

vootey · 2012-05-01 14:55:32

Hey Cdh,

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

Cdh · 2012-05-01 15:41:36

Just a quick test over 54 mbit wifi (pulseaudio is sending approximately 190 kb/s while playing).

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.

ZekeSulastin · 2012-05-01 16:03:08

I'd see if I can help, but a combination of WORKS_FOR_ME across all kinds of fun wifi setups and computers (i.e. server to router 1 wireless-bridged to router 2 connected to iBook G3) 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 ...

Last edited by ZekeSulastin (2012-05-01 16:07:04)

vootey · 2012-05-01 16:41:53

Yup, I'm of aware of the wifi problems and so forth and I guess you are not lucky with your "2.0" pressumption. Afaik network support is not one of their highest priorities (and I'm using 2.0 RC2, so..).

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.

Cdh · 2012-05-01 23:17:32

ZekeSulastin wrote:

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?

Last edited by Cdh (2012-05-01 23:18:30)

Cdh · 2012-05-02 22:50:32

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?

defears · 2012-05-03 00:57:19

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?

vootey · 2012-05-03 07:16:44

Cdh wrote:

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?

defears wrote:

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..

vootey · 2012-05-03 10:03:21

Okay, now I've got something concrete.

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?

Last edited by vootey (2012-05-04 00:03:58)

8vdude8 · 2012-05-27 07:40:44

I'm actually using Ubuntu 12.04, but I've noticed a somewhat similar issue. The skipping occurs for some time, and then play speeds of any audio file (local or via network) changes about 2x.

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.

agapito · 2012-05-27 07:57:52

Try uncommenting this line at /etc/pulse/daemon.conf and restarting pulseaudio.

#default-sample-rate = 44100

vootey · 2012-12-20 16:41:35

Could it be that the issue is gone with vlc 2.0.5 using Pulseaudio 3.0? I tried again and it seems to be working without issues. o_O

vlc 2.0.5 changelog:

· Fix playback initial synchronization with PulseAudio (however similar bugs in PulseAudio version 2.0 and later still exist)

Last edited by vootey (2012-12-20 16:44:08)

Arch Linux

#1 2012-03-02 22:29:59

Pulseaudio over network - Skipping with dropping pitch

#2 2012-05-01 14:55:32

Re: Pulseaudio over network - Skipping with dropping pitch

#3 2012-05-01 15:41:36

Re: Pulseaudio over network - Skipping with dropping pitch

#4 2012-05-01 16:03:08

Re: Pulseaudio over network - Skipping with dropping pitch

#5 2012-05-01 16:41:53

Re: Pulseaudio over network - Skipping with dropping pitch

#6 2012-05-01 23:17:32

Re: Pulseaudio over network - Skipping with dropping pitch

#7 2012-05-02 22:50:32

Re: Pulseaudio over network - Skipping with dropping pitch

#8 2012-05-03 00:57:19

Re: Pulseaudio over network - Skipping with dropping pitch

#9 2012-05-03 07:16:44

Re: Pulseaudio over network - Skipping with dropping pitch

#10 2012-05-03 10:03:21

Re: Pulseaudio over network - Skipping with dropping pitch

#11 2012-05-27 07:40:44

Re: Pulseaudio over network - Skipping with dropping pitch

#12 2012-05-27 07:57:52

Re: Pulseaudio over network - Skipping with dropping pitch

#13 2012-12-20 16:41:35

Re: Pulseaudio over network - Skipping with dropping pitch

Board footer