The ToneProfile does not work on Venu3S

STeN 2 months ago

Hello,

I have the following function. It plays tones nicely on Fenix 5x Plus watches, but never on Venu 3S watches, while it works on Venu 3S emulator.

I have checked the code and Attention has :ToneProfile && Attention has :playTone is true... I can see it also in device logs.

        if (Attention has :ToneProfile && Attention has :playTone)
        {
            log("[playMusic] ToneProfile is supported");
            var toneProfile =
            [
                new Attention.ToneProfile( 784, 125),
                new Attention.ToneProfile( 932, 125),
                new Attention.ToneProfile( 1244, 250),
                new Attention.ToneProfile( 1174, 250),
                new Attention.ToneProfile( 932, 125),
                new Attention.ToneProfile( 784, 125),
                new Attention.ToneProfile( 1174, 250),
                new Attention.ToneProfile( 1568, 250),
                new Attention.ToneProfile( 1396, 250),
                new Attention.ToneProfile( 1244, 250),
                new Attention.ToneProfile( 1661, 250),
                new Attention.ToneProfile( 1568, 500),
                new Attention.ToneProfile( 784, 125),
                new Attention.ToneProfile( 932, 125),
                new Attention.ToneProfile( 1244, 250),
                new Attention.ToneProfile( 1174, 250),
                new Attention.ToneProfile( 1046, 250),
                new Attention.ToneProfile( 932, 250),
                new Attention.ToneProfile( 784, 500)
            ];
            Attention.playTone({:toneProfile=>toneProfile});
        }
        else
        {
            log("[playMusic] ToneProfile not supported");
        }

But when I play one of the pre-defined tunes (see below), it works fine...

// Play a predefined tone
if (Attention has :playTone)
{
    Attention.playTone(Attention.TONE_LOUD_BEEP);
}

Any idea what could be wrong?

Thanks a lot

STeN

Top Replies

Brandon.ConnectIQ 2 months ago +7

Here's the deal with tones and tone profiles. Products used to all have tone generators, which allowed us to play a number of built-in tones or supply a tone profile to create custom tones. When products…
STeN 2 months ago in reply to Brandon.ConnectIQ +1

Hi Brandon.ConnectIQ,

That is a great answer. Thank you for that. SInce the newer products do not have a tone generator, but a speaker, do they have a possibility to play some custom sound even limited…
flocsy🤠 1 month ago in reply to STeN +1

Yeah, I think this should be added to the documentation ASAP (probably it's easier to add that list to the docs than to add a new api for it)

All Replies

0 STeN 2 months ago

This could be closed. It is a duplicate of https://forums.garmin.com/developer/connect-iq/f/discussion/405697/toneprofile-and-playtone-issue-on-venu-3s. I have accidentally posted my question twice, since the first post was flagged by other users as inappropriate and doesn't appear on the site right now. I am not sure why. Sorry for that.

0 Brandon.ConnectIQ 2 months ago

Here's the deal with tones and tone profiles. Products used to all have tone generators, which allowed us to play a number of built-in tones or supply a tone profile to create custom tones. When products like Venu 2 Plus came along, the hardware switched to a speaker that played pre-recorded built-in tones and could no longer play arbitrary tone profiles since there was no longer a tone generator.

From a Connect IQ perspective, all of this functionality is guarded by a :hasToneSupport annotation, which covers all of the tone-related functionality in the Attention module. In other words, the Connect IQ API can't differentiate between a product that can only play pre-recorded tones and a product that has a tone generator to play custom tone profiles—we just know a product can either play tones or it can't.

While we try to match product functionality as much as possible in the simulator, the sim is kind of dumb in situations like this. It just knows that a Venu 3 or Venu 2 Plus can play tones, so tone profiles also work in the sim even though they won't work on the real device.

For now, the rule of thumb (which I realize may not be an easy determination for you) is to expect tone profiles to not work if a device has a speaker. This will likely include most of the newer products.

Ultimately, we need to handle this better at the API level, so I've filed a ticket to get this addressed.

0 FlowState 2 months ago in reply to Brandon.ConnectIQ

Brandon.ConnectIQ said:
From a Connect IQ perspective, all of this functionality is guarded by a :hasToneSupport annotation, which covers all of the tone-related functionality in the Attention module. In other words, the Connect IQ API can't differentiate between a product that can only play pre-recorded tones and a product that has a tone generator to play custom tone profiles—we just know a product can either play tones or it can't.

Thanks for the inside baseball explanation!

I feel like the ToneProfile docs and Attention sample are a bit misleading in light of the above, since they both have an example of using Attention has :ToneProfile to gate ToneProfile functionality.

The sample even has an explicit example of Attention has :ToneProfile nested inside Attention has :playTone, which def gives the impression that the former can be false even if the latter is true.

But my understanding is that in reality, :ToneProfile will be available if :playTone is available, at least for devices with API level >= 3.1.0 (which is the min level for ToneProfile), even if ToneProfile won't actually work on the real device. (Yes, I realize that the has :ToneProfile check still makes sense for devices with API level < 3.1.0).

And it seems that older devices "know" they don't support ToneProfile (even if they support tones), since ToneProfile didn't exist back then (I assume). Yeah, I'm splitting hairs here.

0 flocsy🤠 2 months ago in reply to Brandon.ConnectIQ

Brandon.ConnectIQ Can this also be added to the documentation (including the supported devices list) and maybe also to the simulator.json - it's a useful way to programmatically generate monkey.jungle files based on custom logic.

And if we're already talking about has checks. Can there be 2 keywords so we could differentiate where we want compile time and where runtime check? The --disable-api-has-check-removal option is kind of an after-thought / hack / workaround.

0 STeN 2 months ago in reply to Brandon.ConnectIQ

Hi Brandon.ConnectIQ,

That is a great answer. Thank you for that. SInce the newer products do not have a tone generator, but a speaker, do they have a possibility to play some custom sound even limited? WAW/PCM, OGG/Vorbis, MP3/MP3, M4A/AAC?

Thank you a lot for an answer or suggestion.

STeN

0 Brandon.ConnectIQ 2 months ago in reply to STeN

FlowState said:
I feel like the ToneProfile docs and Attention sample are a bit misleading in light of the above

Agreed. I'll look into getting that addressed. I suspect that was written using the same (reasonable) assumptions many developers might make about tones.

flocsy🤠 said:
Can this also be added to the documentation

I'll ask about this. It's worth looking at, but that may put us on a slippery slope since we don't document all of the other unique exceptions for all products. This is a particularly special case, I understand, but I'd prefer we just fix the problem.

flocsy🤠 said:
And if we're already talking about has checks. Can there be 2 keywords so we could differentiate where we want compile time and where runtime check

Interesting. I'll ask the Council of Ricks what they think about this.

STeN said:
SInce the newer products do not have a tone generator, but a speaker, do they have a possibility to play some custom sound even limited? WAW/PCM, OGG/Vorbis, MP3/MP3, M4A/AAC?

This has been discussed, but it hasn't yet been prioritized. We've also recently been talking with product teams about whether these speaker-based products have hardware that's capable of playing arbitrary tones so we can look at supporting ToneProfile.

0 FlowState 2 months ago in reply to Brandon.ConnectIQ

Brandon.ConnectIQ said:
FlowState said:
I feel like the ToneProfile docs and Attention sample are a bit misleading in light of the above

Agreed. I'll look into getting that addressed. I suspect that was written using the same (reasonable) assumptions many developers might make about tones.

Thanks!

But to be clear, it seems that it actually is possible for Attention has :playTone to be true, but Attention has :ToneProfile to be false - for CIQ 1 and 2 devices, because ToneProfile didn't exist until CIQ 3.

So the docs and sample do make sense in the context of all the old devices which may or may not have a beeper (but never a real speaker). For example, on an FR235 (CIQ 2), Attention has :playTone is true and Attention has :ToneProfile is false. I tested this in the sim, but I have doubt the real device would behave the sim way. (Because ToneProfile never existed in CIQ 2.)

Again, I do find it interesting that the old products (with CIQ < 3) are able to have Attention has :playTone == true, but Attention has :ToneProfile == false, because ToneProfile didn't exist back then.

Why isn't it possible for products with a speaker to omit ToneProfile in the same way that old products omit ToneProfile?

0 STeN 1 month ago in reply to Brandon.ConnectIQ

Brandon.ConnectIQ

> For now, the rule of thumb (which I realize may not be an easy determination for you) is to expect tone profiles to not work > if a device has a speaker. This will likely include most of the newer products.

Since there is no way to detect it - is it at least known which concrete devices have speaker and which have still tone generator?

0 flocsy🤠 1 month ago in reply to STeN

Yeah, I think this should be added to the documentation ASAP (probably it's easier to add that list to the docs than to add a new api for it)