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)

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!

I schedule playback using a DispatchQueue (that's what scheduleAudio does):

self.scheduleAudio(at: interval.start) { do { } catch { print ("Audio activation failed: \(error)") } }

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!