Midnight wrote:I do not think this is the intended use case for Runeaudio...
I'm not sure whether this is an intended use case or not, but I believe the proposal of having BT streaming enabled has some merits.
If BT streaming was not a Runeaudio use case, why enabling (Sh)AirPLay at all?
I can see a lot of potential benefits in implementing support for a BT dongle, limited to the A2DP profile.
Compared to (Sh)AirPlay Audio streaming, BT A2DP streaming allows 'casual' users to stream an audio feed (albeit, not 'hi-fi' quality, but who cares for casual listening...
) to the system without much hassle.
In my case, for example, I am running Rune in my own protected wired/wireless home network. I also have a guest Wi-Fi network which allows guests at home to be online but which is completely 'sealed off' from accessing the other resources in the home network (including the Rune Player and NAS sources).
In order to enable a guest to stream to Rune using (Sh)AirPlay I would need to provide her/him credentials to my own 'private' network, which I am typically not willing to do.
BT A2DP audio streaming would allow a guest to temporarily pipe music into the system without giving her/him access to other network resources and without needing the guest to install 3rd party AirPlay clients.
If this gets implemented (ArchLinux seems to have a quite solid BT stack provided by BlueZ)
https://wiki.archlinux.org/index.php/Bluetooth,
I believe this should be done in a similar way ShairPlay is currently done on 0.3alpha:
- upon connection, put MPD on pause
- when disconnection happens, resume MPD's Play status
Incidentally, I think the current (alpha03) Rune implementation of ShairPlay suffers from the following glitch:
- When playing an ShairPlay stream, if a user enables MPD from the UI Playback page both tracks are played simultaneously
- Wnen Airplay disconnects, the MPD stream does not resume as it is put on Pause
Repro steps:
1. have a track been played via MPD
2. connect from a client with Airplay
3. play a stream from the AirPlay client: MPD will automatically pause and the AirPlay stream will play
4. from RuneUI, un-pause the track being played at step 1.: both audio tracks will be played concurrently --> mess
5. disconnect the AirPlay client
6. Track at step 1. will go into MPD 'Pause' mode and user will need to resume playing of the MPD stream from RuneUI
I believe the issue is with script airplay.sh on /srv/http/command
- Code: Select all
if mpc | grep -q "playing"; then
/usr/bin/mpc pause
exit
fi
if mpc | grep -q "paused"; then
/usr/bin/mpc play
fi
which - I believe - gets run both at the beginning ot the Airplay connection and upon disconnection, discarding what has happened between the two trigger events.
Possibly using two separate scripts at begin and end of connection w/out querying the MPD state would mitigate the issue...
Posted: 19 May 2014, 15:06