RAOP detects AirportExpress only after resetting network

[takkat]

With Ubuntu Karmic 9.10 PulseAudio 0.9.21 runs pretty well playing sound smoothly over my WLAN-attached AirportExpress? (AE) devices. Thanks a lot for this nice work!

However after startup the AE is only detected when manually performing a network-reset. In addition, if WLAN-connection skips temporarily the AE may get "lost" and is not available until the network was disconnected and re-connected again (using GNOME network-manager).

I'm not sure on what additional information you need, so please ask.

[coling]

Does unloading and reloading the module-raop-detect module work? You can do this by loading paprefs and then unticking and reticking the appropriate ticky box.

If this works then I can only surmise that this related to PA process being started before avahi at login. This is totally possible. I'm not sure if we need to idle and reconnect to avahi or whether the system should guarentee avahi is available at login... hmmmm.

[takkat]

Replying to coling:

Does unloading and reloading the module-raop-detect module work? You can do this by loading paprefs and then unticking and reticking the appropriate ticky box.

Nope. Paprefs won't do the job, sorry. However when disconnecting from network and reconnecting immediately the AE-sink becomes available...

[coling]

In that case this is almost certainly avahi related in some capacity. I have seen people mention the same problem with native PA auto-discovery too. Lennart may have some ideas?

[takkat]

Replying to coling:

In that case this is almost certainly avahi related in some capacity.

ACK. Ping to my Airport.local is responsive only after a network reset. Do you have any ideas for a workaround to make things as easy as possible?

[coling]

Interesting. Does the name resolution work (e.g. Airport.local resolves OK to an IP?). If so then the problem could even be lower than avahi... Perhaps some kind of firewall is blocking the traffic? The reason I ask is that I use the actual IP address to connect rather than the name, so it would suggest that some network level issue is preventing this.

[takkat]

Replying to coling:

Does the name resolution work (e.g. Airport.local resolves OK to an IP?)

No, it feels like the name resolution is broken. Ping to the AE's IP is always fine.

As far as I found out, there are two different kinds of errors: Avahi-discover either fails to detect the AE (until resetting the AE) or, in most cases when the AE is recognized it says "Timeout Error". Still in both cases ping to the IP is responding.

Is it possible to use the IP rather than avahi to make PulseAudio stream music to an AE? That would be a perfect workaround to me.

[takkat]

Here's some additional information: When restarting avahi-daemon I mostly see my airport.local using avahi-discover and from PulseAudio.

However it must be more than that! I also have errors when the name resolution is fine (i.e. ping to airport.local works) but still, the device is not present in the PA audio settings until I perform a network restart.

Any ideas?

[throughnothing]

I just wanted to say that I also experience this bug, and usually restarting network-manager fixes the problem.

A few times it even goes away *while* im streaming music to it/using it, and I have to restart network manager to make it show up again and resume the music.

[coling]

I think the two issues (initial detection and subsequant disappearance while playing) are separate. I'd imagine the going away while listening one is actually a crash somewhere (probably in the roap module), so the whole of PA dies, and then is respawned and whatever is needed for initial detection is needed again here.

I don't use network-manager but doubt it's directly related. I'm pretty sure that whatever the bug, it's further up the stack.

If you can do avahi-browse -t _raop._tcp and get results then the code for detection in PA will get results. If the above command does not work until you reset the network, then this confirms the problem is further up the stack.

[takkat]

Now things get somewhat complicated:

• avahi-browse -t _raop._tcp doesn't say anything until a network reset.

• avahi-browse then immediately finds attached airport.local, as does PA

• after a power off to the airport, PA only removes it from the list when I repeatedly try to select it.

• but still, avahi-browse detects the (non-existent) airport.local device

• only after performiing a network reset avahi-browse will not falsely detect the (removed) device

• however, when switching the airport on again it will be detected smoothly as expected (i.e. no additional network reset is needed)

I hope this information helps to further narrow the bug. What else do you need?

[coling]

I don't seem to be seeing that behaviour on my system so perhaps there is a problem in your distro with the avahi-daemon? I think it would be best if you report a bug via your distro and show them the lower level output (i.e. the problem is pretty much directly visible with just the avahi-browse command). The fact that PA is involved looks mostly irrelevant and fixing the underlying problem in avahi will make things work correctly.

If you can post the distro bug link here it would help me check up on it later :)

(as a bit of a long shot, you can perhaps try disabling ipv6 support in /etc/avahi/avahi-daemon.conf (use-ipv6=no) and see if that helps? Other options in there may end up pointing to a config problem... I'm not really an expert on avahi tho', so can't offer much more in this area)

[throughnothing]

I observer pretty much the exact same behavior described by takkat. I'm using ubuntu (karmic), are you using the same takkat? I agree with coling that it seems like an avahi issue, and pulse is just trusting/using whatever avahi is telling/providing to it. Definitely seems like either an avahi issue or an ubuntu issue, or both. I'm going to look at the avahi bug tracker and see if they have any bugs related to this issue, and if not either post one there or to ubuntu.

[takkat]

@ coling: thank you very much for your help. After what I've learned, I agree it's most likely an avahi issue, or some broken config in ubuntu (however I have these issues on two different machines, running on jaunty or karmic). By the way, ipv6 was always deactivated (by default).

@ throughnothing: did you find out anything? Maybe it's related to #116984, a rather antique but still unsolved issue reported on launchpad?

[throughnothing]

@takkat I quickly browsed through the avahi bugs and didnt see anything, but that ubuntu bug is a good find. It's old and seems not much has been done there, I commented there as well so hopefully we can get some ubuntu people to check into it.

[takkat]

After updating to ubuntu 10.04 LTS I am still having problems with audio streaming to my AirportExpress?. Avahi does not update .local services correctly, i.e. if the AirportExpress? disappears it would still be reported as .local device to PA until Avahi daemon is restarted. On the other hand, if AE is switched on later, again a reset of Avahi is needed to make it be resolved as a .local device. But there is more, probably involving PA as well: there are instances when Avahi correctly does or does not resolve a .local device but still PA device chooser displays it on a rather random basis.

Since not many people seem to be interested/affected by this (LP #586229) there is obviously little chance of any improvement in respect to the Avahi behaviour. It would be very nice if there was an easy way for a workaround, e.g. using the IP adress (which is always fine at least to ping) for streaming rather than Avahi .local devices.

Any way to get there?

[coling]

You can happily load the roap sink manually (and pass an IP address). Just pass the appropriate arguments to it as per the wiki:Modules page.

[coling]

Oh and I should point out that PA Dev chooser is rubbish and we do not support it. It works independently of a connection to the PA server and generally just messes about with the configuration by tweaking properties on the X11 root window. Even it's avahi code is independent of the PA server. As we have been saying for almost 2 years, don't use padevchooser! :)

[takkat]

@coling: thank you for your advice. Sorry for having named padevchooser earlier, I had this in mind from an old install but presently I don't use it any more. Instead I use the volume-control app to choose the audio device.

Unfortunately I fail completely in loading the raop sink manually, mainly because I am unable to find any documentation. The module-raop-sink is not listed in the wiki:Modules here either. How exactly do I pass an IP adress to this module? As far as I understood I have to do pulseaudio --load="module-raop-sink ARGUMENTS" but, what are these arguments?

[coling]

Hmm, it seems I completely fail! I could have sworn I'd added the roap sink to the wiki:Modules page but now I look it's clearly not there!

I've updated it now. Sorry about that.

You'd use the following command to load the module manually: pactl load-module module-raop-sink sink_name=RAOP server=192.168.0.2

[takkat]

@coling: Great! Streaming works fine now for me, at least when my AE is ready. No more Avahi or network resetting, thank you for this little but nice and efficient trick.

[takkat]

For those interested: there is a one-click GUI I published on https://launchpad.net/stream2ip to make streaming directly to the IP more comfortable.

[takkat]

After upgrading to pulseaudio 1.0 in Ubuntu 11.10 and 12.04 we are unable to connect to a RAOP device with a script using

pactl load-module module-raop-sink sink_name=RAOP server=IP

Replacing IP with [IP]:Port does not make it better.

When selecting the RAOP sink, and move the sink input there from a python script the music player will pause playback until the default sink was restored. Connecting from command line usually works fine.

Sometimes the RAOP sink will disappear silently, or its name will be replaced by a different name (RAOP replaced by raop.<Name>.local). The latter also happens when we disable RAOP discovery with paprefs.

Therefore we can no longer use the IP alone (without using Avahi) to establish a working raop sink. As Avahi still is not capable of reconnecting an AEX after intermittent network corruption this is not really a satisfying solution.

Can we do anything about this?

[takkat]

Turned out to be a timing issue. Introducing 3s sleep after loading the raop module fixed it.