try audio.engine.start() audio.node.play() for q in interval.cues { audio.node.scheduleBuffer(q.buffer, at: AVAudioTime(hostTime: q.hostTime)) }

It didn't like the word "c u e"

Hello, I have been working on an audio module that plays a specific sound at regular intervals -- similar to a workout timer that alerts the user to switching exercises every few minutes. I'm configuring my audio session like this: let session = AVAudioSession.sharedlnstance() try session.setCategory( .playback, mode: default, options: [.interruptSpokenAudioAndMixWithOthers, duckOthers] ) self.engine.attach(self.player) self.engine.connect(self.player, to: self.engine.outputNode, format: self.audioFormat) try session. setActive(true) I schedule playback using a DispatchQueue (that's what scheduleAudio does): self.scheduleAudio(at: interval.start) { do { try audio.engine.start() audio.node.play() for kue in interval.cues { audio.node.scheduleBuffer(kue.buffer, at: AVAudioTime(hostTime: kue.hostTime)) } } catch { print (Audio activation failed: \(error)") } } This works perfectly in the foreground. But once the app goes into the background, the scheduled callback runs, yet the audio engine does not start, resulting in 'AVAudioSession.ErrorCode.cannotStartPlaying'. Interestingly, if the app is already playing audio before going to the background, the scheduled sounds continue to play as expected. I have added the required background audio mode to my Info plist file by including the key UlBackgroundModes with the value audio. Is there anything else I should configure? What is the best practice to play periodic audio cues when the app runs in the background? How do apps that do turn-by-turn navigation handle continuous audio playback in the background? Any advice or pointers would be greatly appreciated!

Alas, I don't know the answer to your question. But at least now you can post it without using such naughty language.

This is a signal test.

This is another test: let redacted = "signal"

It looks like you're using the deprecated "metadata" property. I'm not familiar with these AV APIs, but it looks like modern versions make the asynchronous nature of this operation explicit, as in this example.

It's more likely that Finder is calling a network-specific file operation for the SMB or AFP connection. You said you "could" work around the problem by manually doing a recursive delete. But does that mean that this actually works? Permissions can be complicated, especially on a Linux-based file server that the user could have configured in an unusual fashion.

Try doing diff -r --brief /path/to/Xcode/SDK /path/to/Xcode-beta/SDK and then opendiff on each line. You might need to wrap it in some extra logic because versions numbers in the headers will have been updated, so pretty much every file has been updated. But otherwise, it clearly shows the differences.

[quote='847713022, Etresoft, /thread/791376?answerId=847713022#847713022, /profile/Etresoft'] This is another test:[/quote] This is nice. 😄

[quote='849091022, DTS Engineer, /thread/792821?answerId=849091022#849091022'] [quote='848905022, pbierre, /thread/792821?answerId=848905022#848905022, /profile/pbierre'] 2. How was it decided to install them in the wrong place? [/quote] [/quote] Thanks!

What is "logPath"? It sounds like you may have sandboxed the app. It probably no longer has access to whatever logPath is. Since this is your own app, the easiest solution would be to disable the sandbox. If you want to be clever, you could give yourself a temporary exception entitlement for that path.

[quote='post, Baylward, /thread/793561, /profile/Baylward'] This seems contrary to what the documentation says here [/quote] That documentation specifically refers to a security-scoped URL. That is a URL that you've retrieved from a security-scoped bookmark. If you've retrieved the URL from some other means, then these methods may not necessary (but see below). [quote='post, Baylward, /thread/793561, /profile/Baylward'] why not save and retrieve the URL immediately in order to avoid having to make any additional calls to url.startAccessingSecurityScopedResource?[/quote] Saving and retrieving a URL is a time-consuming hassle, especially compared to calling these two methods. You only want to do that if you really need to. You can call start/stopAccessingSecurityScopedResource on any URL. You just have to pay attention to the result from startAccessingSecurityScopedResource. You only need to call stop if start returned true. When you get a URL via the standard UI pickers, then it already has an implicit "start". That's why it works. There's no problem with calling "start" again, as long as you don't call "stop" if "start" returns false. This is handy for cases where you do the URL handling elsewhere. You can just always call start/stop, and if you do it correctly, it will always work. In some cases, especially on macOS, saving and loading bookmarks can be more tricky, so that's another reason to avoid it if you don't need to do that.

According to this post: https://stackoverflow.com/questions/76238555/why-are-txt-records-set-to-nil-when-using-nwbrowser-for-network-framework the problem is in the NWBrowser. There are two different descriptor types, .bonjour and .bonjourWithTXTRecord. Hopefully that will fix it. If not, you'll have to work your way through the debugging path.

[quote='849503022, Baylward, /thread/793561?answerId=849503022#849503022, /profile/Baylward'] the 'Summarise folder without permission' button does NOT work, so there doesn't seem to be any implicit "start" [/quote] I'm sorry, but I don't know what you mean by "does NOT work". Is it throwing an exception? Or failing in some other way? What is the specific context of this "failure"? You aren't checking the result of startAccessingSecurityScopedResource(). So then you are calling stopAccessingSecurityScopedResource() based only on the permission value, which is wrong. You should only call stopAccessingSecurityScopedResource() if startAccessingSecurityScopedResource() returns true. [quote='849503022, Baylward, /thread/793561?answerId=849503022#849503022, /profile/Baylward'] Strangely running the identical code on a simulator DOES work, which I also find confusing. [/quote] That part's easy enough. Whenever there is a discrepancy between the behaviour of the simulator vs. a real device, the simulator is always wrong. [quote='849503022, Baylward, /thread/793561?answerId=849503022#849503022, /profile/Baylward'] errors occurring when accessing hundreds of URLs, each bracketed by the accessing calls [/quote] I don't know how you're ever going to get hundreds of URLs on iOS. Normally, the user selects a single URL. If you are loading and saving bookmarks, you're probably only doing that for a few URLs at a time. It makes sense to put the accessing calls at a higher level of code. That way, when your lower-level code accesses the contents, perhaps with hundreds of URLs, you don't have to worry about any of this. Those are then just regular 'ole URLs. [quote='849503022, Baylward, /thread/793561?answerId=849503022#849503022, /profile/Baylward'] my main concern is that the code doesn't seem to be behaving as expected from the documentation, and I don't understand why! [/quote] As I said, the documentation is very explicit about when these accessing calls are required. You only need them when loading from a security-scoped bookmark. In your case, because you need them when loading from a security-scoped bookmark, they work, even though you aren't using them correctly. In this case, it just so happens that startAccessingSecurityScopedResource() returns true and then your call to stopAccessingSecurityScopedResource() also works. But then when you use them incorrectly in the case where you don't need them, they fail, because you haven't checked the result of startAccessingSecurityScopedResource() and you call stopAccessingSecurityScopedResource() when you shouldn't. My recommendation is to simply use the API correctly and then everything works. That way, your lower-level code never needs to know about any of this. Your code is also portable across other Apple platforms like macOS where these bookmarks behave differently. And your code is more robust because it will then work regardless of where the URL came from. You can use the same business logic for a URL read from a file or defaults, or selected by the user.