I've been wondering if there is a way to modify or even disable tones for indicating channel states. The behaviour regarding tones seems like a black box with little documentation.
During migration to Apple's PT Framework we've noticed that there are few scenarios where a tone is played which doesn't match certain certifications. For example; moving from a channel to another produces a tone which would fail a test case. I understand the reasoning fully, as it marks that the channel is ready to transmit or receive, but this doesn't mirror the behaviour of TETRA which would be wanted in this case.
I'm also wondering if there would be any way to directly communicate feedback regarding PT Framework?
I've been wondering if there is a way to modify or even disable tones for indicating channel states. The behaviour regarding tones seems like a black box with little documentation.
No. One of the PTT framework's requirements is to make sure that apps couldn't record the user without their knowledge, which is why the tone exists. I'll also note that, in practice, many apps actually "integrate" the tone into their experience by using a two-tone pattern where the system’s tone basically means "I know you want to record and am working on it" and the app then places a second tone that means "your connection is now active and people can hear you, so start talking".
However, this:
For example; moving from a channel to another produces a tone which would fail a test case. I understand the reasoning fully, as it marks that the channel is ready to transmit or receive, but this doesn't mirror the behaviour of TETRA which would be wanted in this case.
...is actually a bug in your app, partially caused by a design mistake in the PTT framework. The problem here is that, with the benefit of hindsight, we should have used the word "channel" in the PTT framework. We used it because that's the terminology widely used by PTT apps, but that's also why we should NOT have used it.
What the PTT framework means by "channel" is simply "your app’s connection to the system" and NOTHING else. That means:
-
You'll never have more than "one".
-
You ONLY "join" when you want to start your long-running "PTT session".
-
You ONLY "leave" when you want to end that session.
And, yes, that doesn't match what your app means by "channel"... which is EXACTLY why we should NOT have used the name "channel" in the API. Your app is going to implement your own concept of channels on "top" of ours. For example, when you "switch channels", you'll probably update the channel descriptor to describe your "new" channel. Your app might have a state where you aren't in any "channel", so you change the channel descriptor to "No Channel". None of that means that you'll actually change the state of PTChannelManager.
In any case, returning to the original example:
moving from a channel
…the solution is “don’t do that”. It’s disruptive to the overall PTT system and doesn’t really “work”. Architecturally, PTChannelManager is actually a singleton and actively leaving/joining channels just create unnecessary disruptions. If you’re in the background, the rejoin can actually fail, breaking your app. As I outlined above, “join” when your app wants to be “the PTT app” and don’t leave again until you’re ready to be completely “done”.
I'm also wondering if there would be any way to directly communicate feedback regarding PT Framework?
In terms of formal feedback, the answer is basically "always" that you need to file bugs. If you post bug number back to this thread, I'll also make sure they get to the right person.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
