Post not yet marked as solved
It seems that my code was not ready to work with the voices which have a sample rate of 16000. This caused the issue with the sound, it was not related to voices returned by AVSpeechSynthesisVoice.speechVoices not being available. Everything is working fine in iOS 17.
Post not yet marked as solved
Do "available" and "installed" still mean the same in iOS 17? When I use "speechVoices" I get voices such as "grandpa" and "grandma" and others which do not produce any sound. When I check the available voices in Settings > Accessibility > Spoken Content > Voices, these voices are not even listed there or are inside the voice "Eloquence"
I was thinking about letting the user choose the voice for TTS, but it seems unfeasible now, I would have to warn the user to test the voice first to see if it works... Is there something I am missing? Is there another way to know if a voice returned in "speechVoices" is really available for TTS?
Post not yet marked as solved
I filed the feedback request:
FB11928291
I hope a policy update will reconsider this use case.
Thank you.
It turns out the audio session was active when changing the category, and this worked in foreground, but in background failed, although this had worked in several iOS releases before. This is the Stack Over Flow thread which gave me the clue:
https://stackoverflow.com/questions/73349619/ios-16-beta-5-avaudiosession-setcategory-produces-strange-error-what
Post not yet marked as solved
Thank you very much. Indeed I had not figured it out yet. I had tried a number of combinations, including this one, but most of them with long press. It is strange you edit other widgets with long press and lock screen widgets with a single tap...
Well after more testing, background audio is working for me. What seems different between iOS 15 and 16 is:
[AVAudioSession sharedInstance].currentRoute.outputs
In iOS 15, it seemed to work in the background and with not activation of the audio session, so I could check if the device was connected to CarPlay. It seems that in iOS 16 it doesn't work that way, so I have changed my code to compensate. This is what caused for me that audio did not seem to work, I was sending the audio to a route different from CarPlay, when the device was connected to CarPlay.
Regarding the original question, do you have an active Audio Session when you are in the background?
Same here. My app is written in Objective-C (most of it), has location updates and audio background mode. When testing in iOS 16 beta 7, I can reproduce the issue. The app plays a warning when approaching some locations while driving. In a long trip I did today while I was testing the app on the road, I could reproduce the issue all the time. Audio is working on the foreground, but as soon as I lock the device, audio does not work. I have just tested in the simulator, and in the simulator it is working fine.
Background audio has worked in my app in the last releases of iOS with no issue. It is the same code I am using with iOS 16 beta 7.
Any idea? Thank you.
Thanks for confirming it won't work in an Objective-C app and that the user interface won't update with the wrist down.
It is a pity some new features are only being brought to SwiftUI. This app has been available since WatchOS 2.0 and the work to port it to get this feature is not currently worthwhile. Maybe in the future, when more new features are cut out from Objective-C.
No, I din't implement intentUI. The code I posted has worked since iOS 12 until iOS 14.2 with no modifications. I do not see anything in the docs or WWDC sessions which suggest that in iOS 14.3 you should do more to show up as an action in the Shortcuts app...
