Popping Sound

Hi @DTS Engineer After rolling out the workaround solution (setConfiguration immediately before reporting a new call), the issue still persists. So looks like the workaround can not resolve this issue. cc @goat_herd Today, we reproduced this issue once on iOS 26, WITH the workaround solution. I have reported a bug. FB20789841 (CallKit does not activate audio session, the issue rate increased on iOS 26.) Base on our metrics, this issue is the primary contributor to one-way audio problems in our app and continues to increase as iOS 26 adoption grows. The occurrence rate seems to be twice as high on iOS 26 compared to iOS 18. Our metrics currently show a 0.67% rate for iOS 26, and this figure is still rising. !!!Given the ineffectiveness of the workaround, we respectfully request that this issue be given higher priority. This is particularly important as iOS 26 is being adopted by an increasing number of iPhone users.!!!

This sounds related to my feedbacks FB16246168 (Text in Lock screen accessory rectangular widget does not wrap to another line when it should fit) FB16246023 (Lock screen accessory rectangular widget does not appear as expected on iPhone 16 Pro because text is too big and truncated) But both of those were filed before iOS 26

Can anyone give advice? Thanks a ton! Unfortunately, this is actually the first time I've looked at Building an Audio Server Plug-in and Driver Extension and, to be honest, that is not great sample code. Using darwinup in a shell script is not something any one should actually do. I've already filed a bug on this (r.163226098), but you're going to need to do a bit of work to end up with something reasonable. SO, what I would actually suggest is the following: Start with the sample Communicating between a DriverKit extension and a client app and get it building and running. That's our simplest sample and will let you sort out the basic build and install process. Once that's working, replace the DEXT inside that sample with the DEXT from Building an Audio Server Plug-in and Driver Extension. Once that's done, you'll have an installer app with an embedded DEXT, which is what ALL DEXT need to be shipped as anyway. Shifting to the codesign front: I would be ok for now with the local option, but X

Why is there a difference in behavior between these two devices? It sounds like a bug, possibly fixable by reboot as noted here: If that ui presented and you kill the app in Xcode, it will not show up again until after you reboot your iPhone. Yes, you have to reboot. Sad. Have you filed a bug and, if so, what's the bug number? Is it possible to control the UI so that the progress indicator only appears when the app moves to the background? No, your app doesn't have any control over this. If you want us to add API for this, please file a bug describing why you want this control and post the bug number back here. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

I think I went to the right place to put in a feature request. It has been a while since Coded PHY was announced, so I'm sure Apple is aware of it and has a position on it. It would just be good to hear what it is. I see SoCs get significant range, in one test 500 meters (https://www.youtube.com/watch?v=ANqkKXDzWqo&t=52s One Plus Nord N10 5G phone). I also saw Direction Sounding support in another phone(https://www.youtube.com/watch?v=sx-6o64206Q Pixel 10). It would be great to hear if these innovations are coming to iPhone.

@Etresoft, Well there's still the Apple Events capability in Signing & Capabilities. You have to provide a message to the user about why your app needs AppleEvents. I'm not sure what happens if that's missing. I don't remember from when I've done it previously, but I think OS just offers some default message presented to the user. I'm going to go ahead and disagree on that point. But I assume you're only talking about the end result for your use case. I haven't tried it, but osascript just executes scripts, without providing any extra functionality to control them. Since the plain script exhibits the undesirable (for me) behaviour with already existing files, I assume using osascript would result in the same. Are you sure that's even possible? So I think your suspicions here are likely unfounded. I'm not sure, but for the beginning, I first need to programmatically make Finder to react. And at the moment I'm not able to, due to all the explanations I provided in the initial post. I don't understand why it

@DTS Engineer, Not to discount any of that but it seems to me that if you're able to get NSUserAppleScriptTask working you could write a slightly more complicated script that checks for files in the destination before saving and then takes appropriate action inside of the script. The Finder defines an 'exists' verb in its dictionary that should be very helpful for that sort of thing. Right, and it sounds like a very sensible thing to do. However, as I've mentioned at the very beginning of my initial post, I need to programmatically invoke exactly the same behaviour of Finder as if a user copies files in it using standard UI-based methods. Why is that? discussion is out of the scope of the question. I appreciate your effort to help, I really do, but the solution you suggested isn't what I need.

Your best option here is to open a bug report describing this. Since you have a CFBundleSpokenName, how does your app name sound when using VoiceOver on the Home screen? The answer to that question is also one you should include with your report. Once that's filed, please post the FB number here for reference. — Ed Ford,  DTS Engineer

I’ve moved your thread over to Media Technologies > Audio, because this is more of an audio thing that a networking thing. It’s possible that someone with relevant audio expertise might chime in. However, you’re unlikely to get an answer to this: [quote='804668021, Cssoundlab8, /thread/804668, /profile/Cssoundlab8'] Is there a plan on the Apple side to also implement AVnu Milan on top of the AVB Protocol? [/quote] See tip 3 in Quinn’s Top Ten DevForums Tips. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

So, let me start here: The CallKit integration appears to be forcing a different, non-amplifying audio session category or configuration, negatively impacting the user's perceived call volume. Basically, yes, that is exactly what's going on. Internally, both CallKit and the PTT framework really run on a private audio session configuration which is similar to PlayAndRecord, but not identical. Ironically, the most notable difference is that its maximum playback volume is slightly higher than a standard PlayAndRecord session. However, the bigger benefit is that this session configuration has a higher priority than any other audio session time, which is why it can't be interrupted by any of standard audio APIs. We require assistance in resolving a critical audio design conflict within our Push-to-Talk (PTT) application. Just to clarify, are you using CallKit or the PTT framework? Your answer won't really change the audio side of this, but I'd like to have a cl