Popping Sound

for the same code (didn't change anything - just keep toggling same app code 1 minute apart): If I set alarm 1 minute later and lock the phone -> I see alarm go off and UI shows in Lock Screen with the alarm sound If I set alarm 1 minute later and do NOT lock the screen (looking at Home Screen while I wait) -> I get nothing (likely my app code is executing something though) without fail it does that behavior atm

Hi there, thank you for the response. At the moment, I am not 100% clear on what's going on so don't want to go through the process of filing Feedback. My updated understanding is that the alarm maybe does go off, but there's some special behavior if the phone is not locked (ex. its in foreground) or app is in foreground while the alarm goes off. If I lock my phone, even with 1 minute differential I see the alarm go off. If I don't lock my phone, what maybe happens (at least I sometimes see it in debugger) is that the app runs to receive the alerting update (even if its technically in background?), but there's no UI anywhere showing that the alert is going off. Sometimes I do hear the sound (there's sound of alarm going off with no UI anywhere). I utilized open source sample code around AlarmKit and for that I do see the UI appear, where maybe it does because they implemented the custom widget? (but even their UI still shows inconsistencies depending on state of device/app) Of course I could

I'm facing a similar issue with my external USB audio device.

I believe our app shall have done this correctly, as both incoming and outgoing calls functioned properly before the problem occurred. Our application did not restart or reinitialize during this time. Are you absolutely certain of this? If so, then do you have any idea/guess as to how much time was between the last working call and the first failed call? My best guess on what caused this was that it was tied to odd app initialization conditions. Thinking about it more, I might see another way it could happen, but I think that would require: Your app to have done a setConfiguration at EXACTLY the wrong moment. Immediately suspend after that point. Stay suspended for a significant period of time (hours?). Regarding backstop, Are you referring to the reconfiguration of the audio session? No, or at least not exactly. Let me jump back to what I said here: I would add an additional call to set the configuration before you call reportNewIncomingCall on the first push you receive, as this should ensure that

It seems I misspoke when explaining the classifications behavior. Indeed, it is possible you will get multiple entries with the same id and time range. You will get a separate output from each sound classifier (laughter, shouting, speech) for the same audio input. These will have the same session id since they’re from the same session. For short sessions you could get the same time values. So, for a short utterance, you might get multiple entries with different classifications as the classifier can think it is shouting or laughing but not sure, and it will output 2 entries with the same identifier and the same time scope. For longer sessions you may get more sound classifications and the time range should reflect which part of the audio stream each entry is referring to. I hope this clears the question you had. I will also go back and correct the initial answer so others searching for the same answers will see the correct answer. As for what level of confidence should be fi

I've just checked beta 7: Custom sounds from the App Bundle — play (once, without repeat) Custom sounds from the Library/Sounds directory — do not play Could anyone play a sound from the Library/Sounds directory?

I've just checked beta 7: Custom sounds from the App Bundle — play (once, without repeat) Custom sounds from the Library/Sounds directory — do not play Could anyone play a sound from the Library/Sounds directory?

Hi @DTS Engineer We attempted to capture a fresh sysdiagnose, but we were unable to reproduce the issue in our lab. We will continue our efforts to replicate the problem. [quote='852684022, DTS Engineer, /thread/783870?answerId=852684022#852684022'] PushKit and CallKit should both be configured in applicationDidFinishLaunching. The goal here is that you want CallKit to be fully configured before your PushKit delegate is called to deliver a VoIP push. I would add an additional call to set the configuration before you call reportNewIncomingCall on the first push you receive, as this should ensure that callservicesd has a valid session ID. Note the configuration doesn't need to change, so setting the configuration to the existing value will work fine. [/quote] I believe our app shall have done this correctly, as both incoming and outgoing calls functioned properly before the problem occurred. Our application did not restart or reinitialize during this time. The issue does not happen on the first call(push). Rega