“Popping Sound”

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

I'm aware that IOBufferMemoryDescriptor::Create can be used in DriverKit to allocate memory and share it with user space. However, is the allocated memory physically contiguous? True physical continuity is largely irrelevant on our platforms. At this point, all of our platforms include an IOMMU which manages mapping 64-bit memory ranges into the physical addresses visible to devices on the PCI bus. You can read more about how this actually works in Background Info on PCI Address Translation. Can it guarantee that when I subsequently call PrepareForDMA in IODMACommand, there will be only one segment? Yes. Many of our DEXTs actually check that segmentsCount==1 and assert (crash) on any value other than 1. Having the descriptor segment would imply that the machine was so far out of the expected behavior range that they'd prefer to crash instead of trying to sort it out. I'm actually not sure a DEXT could get IODMACommand to segment. Inside the kernel, this is typically caused by IOMultiMemoryDescriptor, but that

I got the same issue after updating to Tahoe. I haven't changed anything in the project, and it still makes a sound in iOS 26, but it doesn't work on Tahoe. The sound works if I use AVAudioPlayer.

The audio recorded by clicking the Bluetooth device button is noise. The method called by Bluetooth devices is (requestBeginTransmitting), which enables AVAudioEngine recording in the (channelManager: PTChannelManager, didActivate audioSession: AVAudioSession) method. First off, I want to clarify that possible background activation paths here: The user pushes the talk button using the systems on screen UI. The app is Bluetooth authorized and adds directly calls requestBeginTransmitting() because of a BLE event from a proprietary accessory. The app has set setAccessoryButtonEventsEnabled(...) to true and the user sends non-HFP* remote control event to the PTT system. The standard example of this is pressing the play button on an A2DP/HFP Bluetooth accessory that's currently in playback mode. *HFP events are automatically handled by the system through the standard delegate system. Expanding on #3, this is how the PTT system provides its own support for the experience many PTT apps had previously implem