Bluetooth devices are not able to control and display playing music from apps and web apps consistently

Bug #1099972 reported by Stuart Langridge
18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
media-hub (Ubuntu)
Confirmed
Wishlist
Unassigned

Bug Description

My car is a bluetooth device. I can pair my phone with the car, and then playing music on the phone will use the car as a bluetooth headset and play the music through the car's speakers. The car can also display the name of the playing music on its screen (passed over Bluetooth) and skip to next and previous song via buttons on the steering wheel (with the next/previous command passed over Bluetooth).

An Ubuntu phone has the ability to play songs, including from web applications. At the moment, some music playing apps on Ubuntu can respond to a Bluetooth next/previous command from a paired Bluetooth headset. However, perhaps the Sound Menu could take control of all Bluetooth pairings. That way, all Bluetooth headset next/previous commands would be passed to the Sound Menu, and the Sound Menu would take care of passing those next/previous commands to the currently playing app; similarly, the Sound Menu knows the name of the currently playing song and could pass that information back over Bluetooth to the headset/car and then the car can display the name. If the Sound Menu handled this, then a music playing app on Ubuntu would merely need to integrate itself with the Sound Menu and would have Bluetooth headset support without any work in the app at all. This would also work with web apps (for example, Grooveshark's HTML5 app) which have Sound Menu integration, meaning that an Ubuntu phone would be able to use Grooveshark's HTML5 app and control it from a Bluetooth device while displaying the name of the playing song on that Bluetooth device, something no other platform can do.

Note that this is useful beyond Bluetooth: other consumers of the currently-playing metadata or music control will find this useful. A phone welcome screen which shows the currently playing track and album art would automatically work if it talked to the Sound Menu. Media keys could be handled by the Sound Menu rather than every app individually.

This may not be specifically a Sound Menu issue; probably most of the pieces to make this work in various places (the bluetooth stack, the sound menu, mpris) are in place, but it would be good if the feature were tested from end to end to ensure that all the pieces fit together and the feature worked.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: indicator-sound 12.10.1-0ubuntu1
ProcVersionSignature: Ubuntu 3.5.0-21.32-generic 3.5.7.1
Uname: Linux 3.5.0-21-generic x86_64
ApportVersion: 2.6.1-0ubuntu9
Architecture: amd64
CheckboxSubmission: 4d186c1dd89d3ba4cb89f5ee55713686
CheckboxSystem: bb422ca46d02494cdbc459927a98bc2f
Date: Tue Jan 15 11:03:39 2013
EcryptfsInUse: Yes
InstallationDate: Installed on 2011-12-11 (401 days ago)
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20111211)
MarkForUpload: True
SourcePackage: indicator-sound
UpgradeStatus: Upgraded to quantal on 2012-10-20 (87 days ago)

Revision history for this message
Stuart Langridge (sil) wrote :
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Confirming; we've discussed this one to one on IRC: the idea is nice; hence why I marked this Wishlist.

I'll let Stuart paste our discussion as he sees fit :)

Changed in indicator-sound (Ubuntu):
status: New → Confirmed
importance: Undecided → Wishlist
Stuart Langridge (sil)
description: updated
Revision history for this message
Lars Karlitski (larsu) wrote :

Cool idea, but this would most likely be implemented in the media-keys plugin of gnome-settings-daemon, which already takes care of media keys.

affects: indicator-sound (Ubuntu) → gnome-settings-daemon (Ubuntu)
Revision history for this message
Stuart Langridge (sil) wrote :

This isn't just about the media keys. Remote Bluetooth devices, such as car stereos, can also display the name, duration, and current position of a song that's playing. The media keys don't know that, and shouldn't. Possibly this could be implemented by both indicator-sound and gnome-settings-daemon working in concert; the reason I suggested that it should be implemented *by* indicator sound is that indicator-sound already knows what's playing and what's next, and it knows how to control the currently playing media player, all via MPRIS. Therefore, implementing this all in indicator-sound would mean that only one thing on the device needs to know how to implement the complicated Bluetooth APIs, and any Ubuntu app which correctly integrates with the Sound Menu will also work perfectly with Bluetooth devices without having to do *anything* else, even handling media keys. A music application should not hav to itself contain a bunch of bluetooth code for sending song metadata, I think.

Even if the media keys stuff does get handled by gnome-settings-daemon, the Sound Menu should be involved in order to send the metadata of the currently playing song to a remote bluetooth device, so I'm re-adding indicator-sound to this.

affects: gnome-settings-daemon (Ubuntu) → indicator-sound (Ubuntu)
Changed in gnome-settings-daemon (Ubuntu):
importance: Undecided → Wishlist
status: New → Invalid
Revision history for this message
dobey (dobey) wrote :

Moved this to media-hub, which is the actual music playing back-end. The indicator is simply a view on top of that, as would be any connected car stereo or other device.

no longer affects: gnome-settings-daemon (Ubuntu)
affects: indicator-sound (Ubuntu) → media-hub (Ubuntu)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.