1135680 - Use audio channel interruptions instead of a Settings flag "_hack_hack_shut_up"

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: AudioChannel, defect)

Description

[Cristian Rodriguez (:crdlc)]

With this change we can get rid off settings permission

Comment 1

[Cristian Rodriguez (:crdlc)]

Hi Gabriel, I have implemented a patch [1] to get rid off settings permission for Music app which was only used for a workaround between Music - Ringtone apps playing the same audio after sharing a file. I tried to solve the issue by means of competing for the 'content' audio channel. But I am not receiving any event in Music app when audios are played in ringtone ('mozinterruptbegin' and 'mozinterruptend'). Is this issue related to priorities between caller and callee? if so, is something that will be fixed in bug 892371? Thanks in advance for your support and help.

[1] https://github.com/crdlc/gaia/commit/a55b183536753d2e9836151ee9966ec2be42bcf1

Comment 2

[Gabriele Svelto [:gsvelto]]

(In reply to Cristian Rodriguez (:crdlc) from comment #1)
> Is this issue related to
> priorities between caller and callee? if so, is something that will be fixed
> in bug 892371?

No, that's competely unrelated to audio policy.

Comment 3

[Cristian Rodriguez (:crdlc)]

(In reply to Cristian Rodriguez (:crdlc) from comment #1)
> Hi Gabriel, I have implemented a patch [1] to get rid off settings
> permission for Music app which was only used for a workaround between Music
> - Ringtone apps playing the same audio after sharing a file. I tried to
> solve the issue by means of competing for the 'content' audio channel. But I
> am not receiving any event in Music app when audios are played in ringtone
> ('mozinterruptbegin' and 'mozinterruptend'). Is this issue related to
> priorities between caller and callee? if so, is something that will be fixed
> in bug 892371? Thanks in advance for your support and help.
> 
> [1]
> https://github.com/crdlc/gaia/commit/a55b183536753d2e9836151ee9966ec2be42bcf1

Alive, do you have any input here for helping me? thanks a lot

Comment 4

[Cristian Rodriguez (:crdlc)]

Is because of music app is in foreground behind inline activity and the audio competing policy does not apply?

Comment 5

[Cristian Rodriguez (:crdlc)]

Hi Andrea, Maria Angeles told me that you are a good contact to help me with my questions :)

Comment 6

[Gabriele Svelto [:gsvelto]]

(In reply to Cristian Rodriguez (:crdlc) from comment #4)
> Is because of music app is in foreground behind inline activity and the
> audio competing policy does not apply?

That's a good point, AFAIK inline activities do not alter the visibility of an element. The activity caller will thus be marked visible and whatever relies on that state will treat it as such.

Comment 7

[Cristian Rodriguez (:crdlc)]

Hi Gabriel again, I have checked and it works when the activity disposition is window instead of inline

https://github.com/crdlc/gaia/commit/aa36b0a8862cb90173ffff9c3eb38295749195fa

Comment 8

[Cristian Rodriguez (:crdlc)]

and now the question is to know where we could fix this: "inline activities vs audio competing policy". Maybe system app, gecko side, ... I don't have idea, so in this point, any help/suggestion will be more than welcome

Comment 9

[Gabriele Svelto [:gsvelto]]

This is a complicated issue. The fix should go into the system app (i.e. the activity opener should not be considered visible) but due to how our priority system works we usually can't do that because otherwise the activity opener has a high chance of getting killed. We've discussed fixing this with Alive as part of v3 and we intend to do it but it's not going to happen very soon.

Comment 10

[Cristian Rodriguez (:crdlc)]

(In reply to Gabriele Svelto [:gsvelto] from comment #9)
> This is a complicated issue. The fix should go into the system app (i.e. the
> activity opener should not be considered visible) but due to how our
> priority system works we usually can't do that because otherwise the
> activity opener has a high chance of getting killed. We've discussed fixing
> this with Alive as part of v3 and we intend to do it but it's not going to
> happen very soon.

Thanks a lot for your quick answer Gabriel. I understand your explanation and it seems hard to solve. I release the bug because I don't have to do more here. Thanks

Comment 11

[(inactive after 6/18) Alive Kuo [:alive]]

Gabriele already answered :)

Comment 12

[Dominic Kuo [:dkuo]]

Hi folks, thanks for working on this. Actually several gecko and gaia devs are implementing the new audio channel api and a sub-module in system app, to solve the audio competing issues completely.

After the new audio channel api and the audio channel service enabled in system app, theoretically all the hacks for audio channel should be removed, including this one and we don't have to count on audio_competing_helper.js, so let's not to propagate the audio_competing_helper hacks, sounds good?

And if you are interested in the new audio channel api, please see:
- Spec: bug 961967
- Gecko: bug 1113086
- Gaia: bug 1100822

Comment 13

[Cristian Rodriguez (:crdlc)]

yes sure, i didn't use this in my last test https://github.com/crdlc/gaia/commit/aa36b0a8862cb90173ffff9c3eb38295749195fa to detect the issue. I didn't need that, just to listen for events on audio element

Comment 14

[Jim Porter (:squib)]

This hack is no longer present in the Music app; I'm not sure if there's anything left to do, but since it's not assigned to me, I'll just update the component to AudioChannel.

Comment 15

[BMO Automation]

Firefox OS is not being worked on