Closed GeniviAMmaintainer closed 6 years ago
tracked in JIRA
Yes, it makes sense to remove it because I am expecting following use case: In case the application sets the mute state and it changes a notification with new state will be triggered. In case the policy decides to change the state the notification will be triggered too. An application can at least request the available sinks the get the current state.
However: Somebody might demand on start-up only the state for one element only. In order to reduce the communication efforts it might be interesting to offer an interface to get the common state for one sink (am_SinkType_s) instead of the entire list. This might mean that ::getVolume is somehow redundant.
Where is the benefit to track it inside Jira? Is the fidl not public to open source?
It was simply because it is part of the AM Plugins. And I understood those issues will be tracked in JIRA.
If this is not true, we can of course use the GitHub.
Von: Jens Lorenz [mailto:notifications@github.com] Gesendet: Montag, 6. August 2018 15:47 An: GENIVI/AudioManager AudioManager@noreply.github.com Cc: Molz Jacqueline, EE-602 Jacqueline.Molz@bmw.de; State change state_change@noreply.github.com Betreff: Re: [GENIVI/AudioManager] function getSinkMuteState in PluginCommandControl.fidl (#38)
Where is the benefit to track it inside Jira? Is the fidl not public to open source?
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://github.com/GENIVI/AudioManager/issues/38#issuecomment-410713565, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVIKwaoz63J_Hv_W2cCaTzsidS5XpjN1ks5uOEjlgaJpZM4VwYuE. https://github.com/notifications/beacon/AVIKwavyy8gup4Z-UfK-SJjKmm0RmjZMks5uOEjlgaJpZM4VwYuE.gif
The function getSinkMuteState is listed in the PluginCommandControl.fidl but it seems to be not used at all. Does it make sense to remove it completely?