Music app stops playing when an app plays a sound

Media-hub, the service that handles audio used in the system, recently added the capability to categorize the type of audio being played. If all the following are true the existing audio stream is paused:

1. New audio stream is of the type "multimedia" (note this is the default category)
2. Existing audio stream is playing
3. Existing audio stream is also of the type "multimedia"

I imagine there are many apps that have small sound effects that shouldn't be categorized as "multimedia". With the way media-hub works now any app that uses an alert or small sound effect would need to have the sound recategorized. Would it make more sense for the default to be "alert" or something similar and then just have apps like the Music app specify that they are of type "multimedia"? That would make this categorization easier on other apps, but would require a fix to the music app and media-hub.

Or alternatively, a more complex solution might be to unpause the original stream once the new audio stream reports a status of EndOfMedia

No, the default audio role is of type multimedia because that is the default because it's the default volume group that is controlled if no other context is active. It shouldn't be a big deal to get the core apps to change to be of their proper types. Obviously we need to get the camera-app to change its role. I'll make sure a bug is filed for this in camera app.

@Florian: camera-app should categorize the camera click sound as role type "alert". Add the following QML code to do this:

In the Audio element's properties, add:

Audio {
  audioRole: MediaPlayer.alert
}

Status changed to 'Confirmed' because the bug affects multiple users.

Fix committed into lp:ubuntu-clock-app at revision 93, scheduled for release in ubuntu-clock-app, milestone rtm

If this remains the default, then every 3rd party app that misses this setting is going to cause the same problem whenever they choose to play a sound, which will be rather irritating. Note that this also happens everytime a notification sounds due to a text message or similar.

@Sam Bull: yes, but that would be a bug with the given app that should be fixed. As far as a text message goes, it should no longer pause playback when it comes in...it should instead cause the playback volume to decrease during the alert, then increase back to full volume (called the duckin effect in pulse audio terminology).

Yes, but my point is that if developers miss the documentation, and don't set this setting, it shouldn't cause disruption to the whole platform, which is what will currently happen.

If alerts is the default, then a developer not selecting multimedia for their app will only disrupt their own app, and will more likely be caught and fixed.

Currently, not changing the setting to alerts cause the developers app to work perfectly fine, but causes the rest of the platform to suffer as it cuts off music etc. Somebody with less familiarity with the platform will likely register bugs against the music-app or the platform, as it appears that the music is not functioning, thus further reducing the chances of the guilty app getting fixed.

There's no perfect solution in here, with whatever default role we pick. The main problem is that we currently can only have on active multimedia stream at a time, and that was a workaround until the background playlist stuff gets finished.

We need to improve/fix the documentation to make sure that this gets covered by all apps, so they can at least know better what to do when playing something.

Fix committed into lp:dropping-letters at revision 61, scheduled for release in dropping-letters, milestone Unknown