@DTS Engineer thank you for your answer! But I'm a little bit confused. Do You want to say it's legitimate to create audio recording entities even if Audio Session is not activated?
Yes, that is totally legitimate and, in fact, basically required by the audio system. What "activating the audio session" actually means is "start doing actual work using the current configuration". Most configuration has to be done before the session activates because:
-
At a conceptual level, if you change things after activation, then you have to throw away some (indeterminate) amount of audio that was handled with the wrong settings.
-
At a practical level, the audio system simply does not allow many audio settings to be changed while the session is active.
However, the audio system does not care when you create or configure audio objects. Most apps tend to do it close to session activation, but that's entirely a matter of how code is organized and structured, not a requirement of the audio system. Indeed, it's entirely possible far a voip/ptt app to ONLY configure it's audio session once when it was launched (for example, in didFinishLaunching) and never change the configuration again. Most apps don't work that way because the want to use different configurations at different points, but that's an issue of app design, not because of how the audio system works.
Before recording and transmitting audio, wait for the framework to call channelManager(_:didActivate:).
Hmm... So I think the confusion here comes from some ambiguity around what "recording" means and an ordering issue in the documentation. What the document means "recording" here is simply that your app is actually receiving/capturing and/or playing/transmitting. On the ordering side, the most critical point here is what then comes slightly later in the same document:
Important
Let the system activate and deactivate the audio session to ensure it has the proper priority within the system.
In concrete terms, that simply means that your app should not call setActive. The system will call it for you, then tell you when the session is active using the "didActivate" delegate. Given what session activation actually means ("start moving audio data"), that means that:
Before recording and transmitting audio, wait for the framework to call channelManager(_:didActivate:).
...is actually a truism. That is, until "didActivate" is called, you session is not in fact active, which means you aren't receiving (or playing) any audio data... do what would your app be recording?
So, let me actually start here:
And if take into account PTT Framework doesn't offer any "fail" notification I'm really confused how to deal with it...
I think the single most important fact to internalize about the PTT (and CallKit) framework is that, fundamentally, it is a user interface framework that just happens to have a very narrow focus. That understanding is critical because the interface elements and naming convention make it very easy to fall into the trap of thinking the framework is doing "more" than it actually does or is even capable of doing.
Case in point, all the delegate method "didBeginTransmittingFrom" actually means is that the system has received one of the events that indicate the user wants to transmit audio. It does NOT in fact mean "your app is transmitting data somewhere" because there simply isn't any way for the system to know whether or not your app "can" or "should" do that.
You've already listed several reasons why you app couldn't transmit audio:
update 2: another thing I'm worrying about is establishing connection to audio receiving server. It can take some time and user will get audio notification about he/she may start talk before audio can be really sent.
Yep.
On other side, connection to server can fail (especially if PTT started from background) and it can happen with significant delay,
Yep, that can't happen too.
You have also have an example of a "shouldn't" here:
Also user can fail to "claim floor" due to race condition (and it's highly possible with more than 2 participants in room, we've met it already).
That is, your particular app has defined an additional "rule" the controls constrains what actually happens to audio.
However, that doesn't mean this:
This means app has to implement some recorded audio buffering.
No it doesn't. All the system did was tell you that the user took an action and then activated your audio session. What you do after that point is ENTIRELY up to your app. You could record audio into a buffer or you could discard the audio until you're able to establish a connection to the server.
As a side note here, even the term "transmit" is somewhat misleading. NOTHING in the PTT framework actually requires that you transmit audio data. In theory, it's actually possible to build a PTT app that ONLY sends and receives plain text. That is:
-
Incoming "audio" is sent as plain text in the push packet itself. That audio is then "played" using text to speech.
-
Outgoing "audio" is converted to text and the text is then sent to the server.
I don't think anyone has built this out as a full system, but I believe there are systems in production that use the first technique for some messages. For example, a computerized dispatch system can use #1 for it's own dispatch messages and standard audio for real time communication between users. This both saves bandwidth (smaller message) and improves both reliability (pushes can be received even when normal connectivity is impossible) and performance (playback can begin "immediately", since all of the content that needs to play is in the payload).
That leads to here:
and from user point of view it will look like he/she actually successfully recorded audio (at least some peace of audio).
Yes, that's one of the interface issues you'll need to consider. The standard approach here is that apps actually use two tones for recording, not one. That is, the system first plays the recording alert tone (sound 1) and the app then plays a different tone (sound 2)"later", once it actually wants the user to start talking. Similarly, most apps also need some kind of failure tone to handle the case where audio simply cannot be sent (or received). Of course other variations of this are possible. For example, the app could have a "connecting" tone that loops in between, so the user isn't listening to dead air. The point here is that how you handle all of this is up to you.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
