Should pass incoming call sound to notification system for playback

[Michał Sawicz]

The telephony service currently plays all the sounds itself. We now have support for notifications to play them, and it would be better as a central place to handle notification sounds.

Adding a unity8 task as we need to define looping (probably infinite for all snap decisions, none for the rest - adding a ubuntu-ux task for confirmation) and sound roles (based on notification severity/importance?).

Also adding unity-notifications task in case we need to define more hints...

This would help ensuring consistency for things like bug #1379238.

[Michał Sawicz (saviq)]

Oh and I wonder, what if there's multiple SDs at the same time? I doubt all should play, maybe only the one that's "active" (expanded/focused) should play?

And for standard notifications, we might need a queue?

[Olga Kemmet (olga-kemmet)]

How come, that the telephony service is handling sound differently from all other apps? Or am I misunderstanding something?

[Michał Sawicz (saviq)]

W dniu 15.10.2014 o 15:21, Olga Kemmet pisze:
> How come, that the telephony service is handling sound differently from
> all other apps? Or am I misunderstanding something?

It's a service, not an app, so it has no UI. It does, however, trigger
the snap decision of an incoming call (maybe it'll be a dialog later,
doesn't really matter). Unless it's the actual phone app that will come
up on incoming call, the telephony service will trigger some UI
displayed for the user to interface with. That dialog can have a sound
associated, so that the service doesn't have to be told that the user
muted the call, for example.

[Michał Sawicz (saviq)]

One additional comment here... The incoming call UI might be special enough to treat differently. If we end up with a fullscreen / maximized call UI, it might just as well be the dialer app itself... In which case there's no notification to play the sound through, and needs to be handled in a special way.