Re: Telephony API draft updated

On Fri, Nov 30, 2012 at 12:56 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Fri, Nov 30, 2012 at 1:21 AM, Kis, Zoltan <zoltan.kis@intel.com> wrote:
>>> I don't think this change is a good idea.
>>
>> Yes, it just tackled the visibility issue, but there other issues as well.
>> It looks like you responded to the last archived email, but the 2
>> latest messages (from Hsin-Yi Tsai and my reply) are missing from the
>> thread in the archive. Those should explain some more background for
>> this proposal.
>
> I haven't received those emails. Not sure if there was some problem
> with the list. I did receive this email though (obviously) and it does
> seem to have gotten appropriately archived.

No problem. I repeat a few points from there, just for the record, not
for the sake of argument.

1. About volume scale.
A use case (which the current API covers nicely) is that different
apps may have different volume scales, e.g. telephony may have a
"faster" scale with 10 steps and media player a "slower" scale with 50
steps. The UI should display volume bars accordingly. With the current
interface, volume is represented as a double between 0.0 and 1.0,
making the "scale" actually a "granularity", but still we need to get
the actual volume for showing it correctly.
(Eduardo - in the spec we need to clarify whether the word
"normalized" refers to this scale normalization, or to a normative
real audio volume normalization across all apps).

Another use case was that different audio routes (headset, speaker,
earspeaker, line out) may have different volume settings even within a
single call, e.g. when a headset is plugged in, and speaker was on max
volume, we want to start with a milder volume setting for the
headset...

Yet another use case was that different telephony services may have
different volume settings on all their calls,  of course only when
there is at least one call.

All these were real use cases from earlier telephony/dialer projects
(numbers altered).


>>> The call volume is a orthogonal property to any given call.
>>
>> I agree with this. Volume control should actually be on the stream
>> (source volume, or sink volume).
>
> If it applies only to that stream then I agree. Is that the proposal?

Tentatively yes. But even with that,r now we can stick to the present
interface which provides a "master" volume for a domain (like
telephony).

>> For a first step could we agree in defining a separate interface for
>> audio etc controls, and include that object in Telephony API rather
>> than a bunch of properties?
>> Then, we may discuss later what would be a better place for it.
>>
>> An updated proposal including volume scale:
>>
>> [NoInterfaceObject]
>> interface TelephonyMediaControl : EventHandler {
>>     attribute boolean          speakerEnabled;
>>     attribute boolean          headsetEnabled;
>>     attribute double            audioVolume; // from 0.0 to 1.0
>>     attribute unsigned short audioVolumeSteps; // scale
>>     attribute boolean          audioMuted; // from 0.0 to 1.0
>>     attribute double            micVolume;
>>     attribute unsigned short micVolumeSteps; // scale
>>     attribute boolean          micMuted;
>>
>>     attribute EventHandler onvolumechanged; // including muting
>>     attribute EventHandler onmicrophonechanged; // including muting
>>     attribute EventHandler onaudioroutingchanged;
>>
>>     /** for future use */
>>     attribute boolean          frontCameraEnabled;
>>     attribute boolean          backCameraEnabled;
>>     attribute boolean          localVideoOn;  // send video
>>     attribute boolean          remoteVideoOn; // receive video
>>     attribute EventHandler oncamerachanged;
>> }
>
> I think it's hard to talk in the abstract about which properties we
> should have until we know where they live. But sure, let's tentatively
> say that the above set of properties are good. Though I'd prefer to
> leave video out of it for now as to keep the discussion simpler.

OK.

Best regards,
Zoltan

>
> / Jonas
> ---------------------------------------------------------------------
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki
> Business Identity Code: 0357606 - 4
> Domiciled in Helsinki
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>

Received on Friday, 30 November 2012 11:16:27 UTC