Problems switching airplay <-> local music

I’m currently using musicbox 0.6 RC with airplay and local music.
After using shairplay i cant play local music anymore (even if i first disable airplay speakers (musicbox) at my macbook)

I got the following output in mopidy.log:
ERROR GStreamer error: state change failed and some element failed to post a proper error message with the reason for the failure. Debug message: gstplaysink.c(1899): gen_audio_chain (): /GstPlayBin2:playbin20/GstPlaySink:playsink0

It seems to me that the audio device is still bound to shairplay-sync.
There is also a related? error if i want to start airplay after/while local music was played back.

Is it possible to reset the binding of the sounddevice on a connect via airplay & when musicbox starts to play music?

I found this closed issue with missing gstreamer log:
https://github.com/mopidy/mopidy/issues/927

Here is my gstreamer log:
http://pastebin.com/GpZgQ9LW

Similar problems have been reported earlier:

I think the problem could be solved by an alsa mixer device which is shared by shairport-sync and mopidy.
Unfortunately i’m a total linux sound noob :frowning: i’ll try to learn more on this topic and hopefully find a solution with an alsa-mixer.

Why is a such a mixer configuration not standard in musicbox? Where are the benfits of the software mixer?

I’m not convinced it’s much to do with the mixer but some experiments might be worth doing. From the shairport-sync documentation:

[quote] -t timeout | --timeout=timeout

Exit play mode if the stream disappears for more than timeout seconds.
When shairport-sync plays an audio stream, it starts a play session and will return a busy signal to any other sources that attempt to use it. If the audio stream disappears for longer than timeout seconds, the play session will be terminated. If you specify a timeout time of 0, shairport-sync will never signal that it is busy and will not prevent other sources from “barging in” on an existing play session. The default value is 120 seconds.[/quote]

thanks for the hint with the -t option, solves part of my issue.
After some investigation i found out, that shairport-sync behaves weird when i connect it via the OSX audio output config.
With iTunes & iOS devices i don’t have the problem of a blocking.

Issue at shairport-sync:
https://github.com/mikebrady/shairport-sync/issues/69

Is it intended, that when changing from playing something in Musicbox PI to Airplay and after using/stopping Airplay the music that that was played before in Musicbox PI will not continue. It must be started then every time with “play”. For me, this a clear “no go”. It should continue with the music/playlist/radio station, that was played before switching to airplay. Volumio behaves so. I’d prefer Musicbox PI. Can this behaviour be changed/modified/configured?
Thanks for any advice.

No, don’t think so. You need to stop so that the sound device is released.
Would setting up a dmix alsa device help? You could try looking into that.

Hi, I wonder if you’ve got me right. Volumio does restart the last source which played before AirPlay after quitting AirPlay. This was very important for me. i wonder, why this little feature was not implemented into PI MusicBox, which I would have actually preferred to Volumio.

The point is that when changing from Mopidy to Airplay you must stop Mopidy i.e. you cannot pause. Once you have stopped you lose the play state. We would have to manually backup Mopidy’s state before stopping and then restore it afterwards. It’s doable but a bit hacky. I don’t recall many (if any) requests for it before now, hence it’s not been implemented.