Airport Express is locked after stopping an RAOP stream

[clconway]

After using module-raop-sink to output to my Airport Express, I cannot connect to it from another machine---the hardware is still "in use"---until I pactl unload-module. The connection should be dropped, and the hardware unlocked, so long as there is no active stream.

I'm running 0.9.15-test3

[coling]

Yeah I was aware of this, I just didn't find out why yet.

I think it could be due to dropping the control connection *before* dropping the data connection but I could be wrong here... I'll try and look into it.

[throughnothing]

I've noticed (by using nethogs) that whenever I check the "Make discoverable Apple AirTunes? sound devices available locally" box in the PulseAudio Preferences, that it instantly finds my Airport Express, and pulse audio begins to chew up network, apparently sending to the device. As soon as I turn this option on, pulseaudio sends a steady stream of 150k/s to up to 300k/s presumably to the airport express. Of course this happens when no sounds are playing from my computer at all. As soon as I uncheck that option in the preferences, all of the network traffic stops.

When I'm doing this test, I disable all other network stuff in pulseaudio, so I'm not positive if this bug/behavior spills over into other pulsaudio network shares, etc. Is it standard for pulseaudio to constantly send (presumably) empty data to network sinks just because they exist? This seems pretty wasteful, and it forces me to turn off this option except when I actually want to use it just because it eats up my bandwidth and hits my network pretty hard.

[coling]

Yeah it constantly keeps the device open and running. This is due to the fact that reconnection after dropping the connection did not work very reliably and thus I could not suspend very easily. I hope to have some time to bring this stuff up to date in the not too distant future to give us better support for these devices.

[throughnothing]

Hey, this sounds good. I'm glad you were aware of the issue. I'd love to help out with this as well. I'll hopefully have some time to check out the latest code this week and start messing around. I'm assuming that raop-play has the same issues/problems with delay as well as constantly pushing data to the device? If not, maybe we could see whats going on differently there.

[coling]

Well roap-play was partly used as inspiration while implementing things but the async nature of PA means that the semantics are quite different - e.g. I can't just spin and wait for connections etc.

I'm not 100% sure but I can probably implement idle support now as I think the reconnection issue was fixed when I tidied up some socket client stuff.... I'll maybe see if I can implement that sometime soon and see how reliable it is. Nothing in git master has changed in the raop stuff so nothing new to test in that regard but I'll try and update this ticket with WIP.

[mrooney]

Thanks for all your excellent work in this area coling! Being able to stream to an Airport Express so easily is wonderful.

In the mean time until this is fixed (since my roommate can't use the device as long as my computer is on, in the current state), I've set up two keybindings to toggle this to make it more usable:

Enable (Super+Shift+P): pactl load-module "module-raop-discover" Disable (Super+P): pactl unload-module pactl list | grep module-raop-discover -B 1 | grep Module | cut -d# -f2

It is slightly complicated by the fact that you can't seem to unload by name, so it has to figure it out from another pactl call. Anyway, I just thought I'd share that for anyone else in a similar situation, and also to see if this was the best way (is it?)

[coling]

Your approach is certainly not a bad one. The reason you cannot unload a module by name is that some modules can be loaded more than once - e.g. the module-alsa-card module will be loaded once for each hardware card you have so unloading by name is tricky.

Another method for your workaround would be to tweak a gconf key. If you look in gconf-editor for the key /system/pulseaudio/modules/raop-discover/enabled. If you flip this key to true/false, the module should be loaded/unloaded for you.

I want to ultimately deprecate the gconf stuff but this will work fine in the short term and could be regarded as a cleaner way to do things, but really that's just nitpicking :)

[mrooney]

Thanks for the response coling! Indeed the gconf approach is easier and makes the unloaded state persistent across reboots whereas mine did not. PS, if you need someone else to test Airtunes stuff, I can happily help out!

[fdemmer]

On maverick/pulseaudio 0.9.21-63-gd3efa-dirty I have observed, that the traffic immediately after discovery is still there. Also it is not possible to access an AEX from a different machine after the first one stopped using it (but has the module still loaded). Is this still the expected behaviour or have changes been made to improve the situation...?

[coling]

Sadly this is the expected behaviour as I found that after disconnecting from the RAOP device, I was unable to reconnect again. Obviously I would much prefer to disconnect and allow others to use it while we're not but this is the only way for the time being. Work is being done (mostly by teuf from libgpod) to try and address this issue and more. :)