Output to an RAOP sink skips

[clconway]

Using an Airport Express as a sink from my laptop, the output skips a lot. Enough to make it unlistenable. Playing to the same Airport Express from a Mac laptop works fine, so it's presumably not network congestion. Output from the Mac skips occasionally, but the skips are different: more like pauses while the stream buffer. When Pulse Audio output skips, it's more like a CD skipping, with garbled audio and snippets that sound speeded up (much more distracting).

I'm running 0.9.15-test3.

P.S. There's no module-raop-* component in the bug tracker.

[coling]

Ahh indeed. Added the component now :)

I suspect this is due to the way in which we push data into the device. We just fill it up as much as possible and use the network delay to control what gets xfered to the device. The correct way to do this is to feed data in a real-time kinda of way, so I need to do this at some point.

[myxiplx]

I just installed this too, following the guide here: http://ubuntuguide.org/wiki/Ubuntu:Jaunty#Remote_speakers_for_Airport_Express

It works fine, and I can select the Airport as the output, but audio goes incredibly jumpy when I do so. My symptoms sound very much like the ones discovered during development - 3 seconds of sound, followed by 10 seconds of silence: http://www.pulseaudio.org/ticket/69#comment:47

However, in addition to that, I've found that selecting the Airport Express output has a massive effect on system performance. If I'm playing a video in Totem, it plays perfectly when output to the local speakers, but goes choppy when output to the airport. The video plays at approximately 1/4 of it's usual speed.

PS. Huge thanks for all the time & effort you've put in to getting this working. It made my day finding out I'm going to be able to use my Airport Express within Ubuntu, and not just with one or two programs, with anything I like :-D

[coling]

Thanks for the kind words myxipix :) I'm still working on this. It'll be perfect one day, but that day is sadly not today!

[myxiplx]

No problem, there's no rush. I know how draining these things can be on your time once you get people pestering. I'm quite happy to wait, and in the meantime if there's anything I can do to help just let me know.

I'm quite franky over the moon just to find out this might be possible one day. It's the little touches like this that are keeping me hooked on Ubuntu :)

[coling]

Replying to myxiplx:

I'm quite franky over the moon just to find out this might be possible one day. It's the little touches like this that are keeping me hooked on Ubuntu :)

In the interests of correctness, I should point out that Ubuntu have, to-date, not put any resources into upstream Pulseaudio development. I'm a Mandriva developer and the core PA dev is a RedHat? man, so the credit and kudos should really go to RedHat? (primarily) and Mandriva here :) Nokia are also putting a significant amount of resources in here (particularly with Bluetooth support) just FYI. Also I'm not a Mandriva employee, just a volounteer! There are several other people like me contributing in our own small way.

And, in the interests of fairness to Ubuntu, they do appear to now be advertising for a job position that should see more resources targeted towards PulseAudio in the future :) I just hope the developments they do will be well well coordinated with us here as "upstream" (a problem Ubuntu have, in the past, had trouble overcoming).

But, this is all rather irrelevant to this bug - just wanted to set the record straight :p

[myxiplx]

Sorry, I'm a bit of a Linux newbie, when I say Ubuntu I often mean Linux in general.

To add something more useful to this bug, I just tried gstreamer, which is also meant to stream to Airport devices, and had problems with that too. If anything it's worse than Pulseaudio, I just get random snippets of noise.

The airport still works ok, my other half can use iTunes on Windows and it's crystal clear.

If you could let me know the hardware it's worked ok on in the past, I'm happy to do some testing to see if it's hardware related at all.

[Perspectoff]

Hi there. I use the module-raop-sink on both Kubuntu and Ubuntu and it works fairly well if nothing else is happening on the network simultaneously. All in all, I applaud your efforts.

I write both Ubuntuguide and Kubuntuguide, and my current instructions (regarding the installation from .deb packages contained in the developer launchpad) have moved:

http://ubuntuguide.org/wiki/Ubuntu:Jaunty#Airport_Express for Ubuntu

http://kubuntuguide.org/Jaunty#Airport_Express_with_Pulse_Audio for Kubuntu

[peitschie]

Hi!

Firstly, thanks for the very useful plugin/feature! The detection and behaviour worked straight away, but I found on occasion the sound would suddenly start breaking up.

After a day spent fiddling yesterday, I have found a way to make the raop module skip relatively reliably under the Ubuntu Karmic beta release (based on version 0.9.18-0ubuntu3 I believe).

Basically, if I have either only one pulseaudio-based computer on the network, or the pulseaudio computer feeding the Airport does NOT attempt to share its local devices or locate networked devices, the sound always works fine. If I switch either of these options on though, as soon as I add another pulseaudio-based computer, the music stream to the Airport appears to break up significantly.

I'm able and willing to do code/debugging type activities as required if you're interested in helping me follow this through a bit more :-).

Again... many thanks this feature. Helps me get one step closer to being able to simultaneously broadcast to every stereo in my house from the same computer :D

[yoann]

Hi,

I can confirm the problem : streaming to the Airport will skip every 1/2 seconds. The behavior is the same independantly of the network load.

I experienced the issue on a Wifi network, and on a 100 mbit ethernet network with no other hosts connected. I was not able to make the system work reliably.

Disabling local devices sharing, and access to remote pulseaudio devices didn't help in my case.

Regards,

[peitschie]

Hi Yoann,

Just one more thing to try that helped me. I had to actually stop all streams and switch the default audio to the Airport to get it to play without skipping and breaking up. If I try and move an active stream (among other things), I would get the problem you described. Are you able to check if the stream works correctly if you start it straight on the Airport? You may be already doing this of course, so please disregard this suggestion if you are :)

[yoann]

Replying to peitschie:

Hi Yoann, Just one more thing to try that helped me. I had to actually stop all streams and switch the default audio to the Airport to get it to play without skipping and breaking up. If I try and move an active stream (among other things), I would get the problem you described. Are you able to check if the stream works correctly if you start it straight on the Airport? You may be already doing this of course, so please disregard this suggestion if you are :)

Hi!

Unfortunately, that is what I did already : the default stream was being set to the Airport from the start.

[aronparsons]

Same problem here. Playing a file with raop_play is perfectly smooth.

[wk]

Replying to brion: Hi, Same problem here, at first. I spent some time on it, and finally got it working (almost) without skipping. Am using Kubuntu 9.10 on an Eeepc.

• installed PA 0.9.21 from Launchpad (this also installed RTkit)
• changed config of PA daemon:

  default-fragments = 8
  default-fragment-size-msec = 25
  

• manual load of raop sink (I think I have issue ticket:770 as well)

  pactl load-module module-raop-sink server=xxx.xxx.xxx.xxx sink_name=raop.yourairtunesname.local description="yourairtunesname"
  

At this stage I get a choppy sound for a couple of seconds when moving the stream to the airport device, and then the stream continues smoothly. Until networkmanager starts a scan for accesspoints, at which point the sound goes horribly choppy for 10 or 20 sec again. This happens every two minutes on Kubuntu 9.10. To solve:

• Install wicd as a networkmanager

Hope this helps.

[wk]

Replying to wk:

* manual load of raop sink (I think I have issue ticket:770 as well)

this actually seems to be an essential part. When I enable the raop-discover module, the sink is automatically added (though runs once only, need to restart network/avahi for it to work again) and sound is intermittent. With the manual load I direct it to the IP adress of the Airport device as known by my router. This is a different adress from the one given by Avahi/raop-discover (don't know whether that is correct behaviour).

[karhulitos]

I'm running Ubuntu Karmic 64 and "1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu14~~karmic~ubuntuaudiodev1"

My experiences are varied; sometimes I get rather good output, sometimes heavy skipping. I use to do killall pulseaudio as many times as output gets better. But I never get solid sound.

With above version AEX won't get detected until I restart pulseaudio.

[coling]

Replying to karhulitos:

With above version AEX won't get detected until I restart pulseaudio.

I remember speaking with some Ubuntu users a while back and there seemed to be a bug regarding avahi generally on Ubuntu. The auto-detection relies on a working avahi setup, so likely the detection part of this problem is specific to Ubuntu.

[karhulitos]

Detection is a minor problem, would you have any ideas for clear audio?

[bnb]

Hi all,

i encounter the same problem. Didn't solve it, but here are some details which might help to track down the issue (i use pulseaudio 0.9.15 from debian stable):

1. I own 2 airport expresses. The choppy output only occurs at the new 802.11n-version (firmware version 7.4.2) of the device. My old-generation version (802.11bg, firmware version 6.3) is not affected. 2. As stated before, the problem doesn't occur with the raop_play client or itunes as the client. 3. The problem seems not related to the WLAN component or bandwidth, since i stream across a FastEthernet? network (actually i deactivated the wireless radio on the device) and the used bandwidth is far from saturated. 4. The advice from peitschie above (to deactivate other pulseaudio-devices/-sinks) could be explained by a strange pulseaudio-behavior i observed: If both AEX devices are configured in pulseaudio via separate "module-raop-sink" lines (manually; "module-raop-discover" not used), but only the "problematic" AEX is marked as an active sink, a wireshark dump suggests that the output seems to be nonetheless streamed to _both_ AEX devices. This seems like a bug to me, but maybe someone knows better... ;-) 5. Unfortunately the issue in 4. does not seem to be the whole story: I still get choppy output on my problemativ AEX even if i deactivate any other sink in my pulseaudio-configuration. 6. Although not directly related to the choppy sound, but maybe to the described problems with auto-discovery of devices: I see a strange behaviour of my new-generation/problematic AEX concerning Bonjour/Avahi service announcements. I configured a fixed RFC1918-IP on the device, which can be used to successfully connect to it. But if i look into the mdns-announcements, the AEX announces an unrelated APIPA-address, which is then used by the module-raop-discover. Seems like a bug in the (new generation-)AEX-firmware.

[fredz]

I'm on ubuntu lucid. I've switched from network-manager to wicd and it works well now

[fdemmer]

using a new AEX with FW 7.4.2 I can confirm the weird address announcement. I have wifi disabled and Ethernet set to DHCP (gets a 192.168.x.x address assigned), but sometimes 169.254.213.192 is announced (also a IPv6 address is always included in the announce!)

I traced during discovery and also found this...

the ANNOUNCE contained:

v=0
o=iTunes 2266047237 0 IN IP4 192.168.10.100
s=iTunes
c=IN IP4 192.168.10.4
t=0 0
m=audio 0 RTP/AVP 96
a=rtpmap:96 AppleLossless
a=fmtp:96 4096 0 16 40 10 14 2 255 0 0 44100

and was answered with OK. Then...

SETUP rtsp://192.168.10.100/2266047237 RTSP/1.0
CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;mode=record
User-Agent: iTunes/4.6 (Macintosh; U; PPC Mac OS X 10.3)
Client-Instance: 5d8eb6e47666307d

RTSP/1.0 453 Not Enough Bandwidth
Server: AirTunes/101.9
CSeq: 2

Anyone else getting that? Is it new in 7.4.2? (I tried, but failed to downgrade my AEX, yet.)

Playback works after that nevertheless.

There is some cracking in the sound though. These are not really rhythmic skips; more constant crackling like bad reception. It varies a lot using different players (totem pretty good, mplayer ok, vlc very bad). I could fix this very easily by reducing the volume of the application in the "Sound Preferences". (~99% were enough for totem, vlc needed around 95%, ...)

[fdemmer]

Ah! The "Not Enough Bandwidth" is the reply in case the AEX is already in use. A sink is still created in that case, but it does not work. Maybe it would be a good idea to not create a sink after that reply...?

As previously reported I had everything working with mpd+pulseaudio+module-raop (fixed config, not autodetection, as it seems broken with AEX 7.4.2). That was on my desktop PC... then I tried the same on my fileserver, which is supposed to become my musicserver. Same Ubuntu, same pulseaudio, same mpd, but... skips as described by others in this ticket and those logs:

D: [pulsecore/protocol-native.c:1322 handle_seek()] Requesting rewind due to end of underrun.
D: [pulsecore/protocol-native.c:1322 handle_seek()] Requesting rewind due to end of underrun.
D: [pulsecore/protocol-native.c:1517 sink_input_pop_cb()] Underrun on 'default pulse', 0 bytes in queue.
D: [pulsecore/protocol-native.c:1322 handle_seek()] Requesting rewind due to end of underrun.
D: [pulsecore/protocol-native.c:1322 handle_seek()] Requesting rewind due to end of underrun.
D: [pulsecore/protocol-native.c:1517 sink_input_pop_cb()] Underrun on 'default pulse', 0 bytes in queue.

I tried playing with fragments and size, made sure pa is using high prio and realtime scheduling, checked network speed; nothing helped.

I tried upgrading from Lucid default mpd 0.15.4 to 0.15.15 from a ppa, but that changed nothing.

To further exclude mpd as a cause of the problems, I configured the mpd on the fileserver to use the pulseaudio on my desktop (which in turn uses the AEX)... and that worked perfectly!

So... not working: [fileserver+mpd+pulse-output-plugin+pulseaudio+raop] --> [AEX]

working: [fileserver+mpd+pulse-output-plugin] --> [desktop+pulseaudio+raop] --> [AEX]

btw, also working without problems: the ruby raop module using this simple stdin-->AEX script: http://raop.rubyforge.org/svn/trunk/examples/read_stdin.rb

sinks look the same on both desktop and server:

1 sink(s) available.
  * index: 1
	name: <raop>
	driver: <module-raop-sink.c>
	flags: NETWORK HW_VOLUME_CTRL LATENCY 
	state: IDLE
	suspend cause: 
	priority: 0
	volume: 0: 100% 1: 100%
	        balance 0.00
	base volume: 100%
	volume steps: 65537
	muted: no
	current latency: 0.00 ms
	max request: 8 KiB
	max rewind: 0 KiB
	monitor source: 1
	sample spec: s16le 2ch 44100Hz
	channel map: front-left,front-right
	             Stereo
	used by: 0
	linked by: 0
	fixed latency: 250.00 ms
	module: 16
	properties:
		device.string = "192.168.10.4"
		device.intended_roles = "music"
		device.description = "RAOP sink '192.168.10.4'"
		device.icon_name = "audio-card"

...i am completely out of ideas what could be wrong... anyone?

[cefn]

I experience the same skipping audio issue on Lucid Lynx with...

pulseaudio 0.9.22~0.9.2 pulseaudio-module-raop 1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu14

...and happy to try various things if anyone has any ideas.

[fdemmer]

i gave up on using my airport with ubuntu a wile ago; now unity drove me to fedora 15, which comes with pulseaudio 0.9.22. contrary to what cefn reports, i now have no skips in playback via wire or wireless with that version.

yum gives the following details about the installed package (and the same for pulseaudio-module-zeroconf, which includes the raop module):

Name : pulseaudio Arch : i686 Version : 0.9.22 Release : 5.fc15

(not related to this issue, however: airport discovery seems to be broken on fedora 15 :( ... you just cannot have everything.)

[charding]

I have the airport express 802.11n-version (firmware version 7.4.2) but for some reason I only get choppy sound on certain songs.

Does anyone know if upgrading the firmware on this airport express to 7.6 fixes the skipping issue?

I will try the static IP if this fixes it.

[charding]

Using static IP when loading the module works a bit better but I still get choppy sound. When I use rhythmbox and at the same time while playing music, have pavucontrol open and switch back and forth from my local speakers to the AE, it sometimes "fixes" the choppiness and plays totally smooth.

I have a server where I stream my music (sshfs) to my laptop and then to the AE. This really causes choppiness: if the music is playing smoothly and I then load a new album into rhythmbox. I assume this is because it is taking more bandwidth on the network to download the songs into rhythmbox.

Monitoring gkrellm during this whole process, I find I can switch back to the AE (pavucontrol) to get smooth playback once network consumption is ~150-300k on the network. I get skipping when the traffic is less than 100k.

[Rudd-O]

Same problem here. Ubuntu Oneiric, playing with Amarok, PulseAudio 1.0, skips like a motherfucker, every half a second, consistently. I have no pulseaudio programs open at the time, no VU meters, no nothing... it's just a disaster.

When is this going to be fixed?

[Rudd-O]

BTW, I get about 1mbit/s network output to the AirPort?, and I am connected on the LAN. Ping times to the AirPort? fluctuate between 1ms and 6ms.

I have it autoconfigured using paprefs, no manual configuration. I haven't tried and I won't try manual configuration either.

[coling]

Replying to Rudd-O:

When is this going to be fixed?

I'm afraid there is no specific timescale for a fix. It really just needs someone to commit to spending the time on this - it's a very time consuming task and I'm afraid I just don't have much time to look at it.

Patches to raop are most welcome, but please do speak to me on IRC first as there is an unmerged branch of raop changes (unlikely to help here) that it may make sense to base the work on rather than the code in git master.

Sorry this is not a better response, but we are massively under resourced so please do encourage people to work on this is they have the appropriate skills or are willing to learn them.