Моё музыкальное приложение c воспроизводит звук с AVAudioEngine и использует звук между приложениями для публикации sh вывода движка в других приложениях. Это позволяет пользователям передавать звук в приложение микшера, работающее на том же устройстве. Поскольку IAA устарела на iOS и не поддерживается на Ma c, я пытаюсь заменить эту функцию на аудиоустройства.
Я добавил расширение аудиоустройства типа augn, используя Шаблон XCode, и я понимаю, internalRenderBlock это то, что на самом деле возвращает аудиоданные. Но как расширение может получить доступ к аудиоплееру в приложении контейнера (основного)?
Возможно ли это? Я ожидал бы, что это будет общий случай использования, поскольку аудиоустройства позиционируются как замена для IAA, но я не видел примеров того, чтобы кто-то делал что-то подобное. Я не хочу обрабатывать ввод из хост-приложения и не хочу генерировать звук с нуля; Мне нужно подключиться к звуку, который воспроизводит содержащее приложение.
ОБНОВЛЕНИЕ
Я только что прочитал раздел «Как взаимодействует расширение приложения» в Руководство по программированию расширения приложения . Это не выглядит многообещающе:
Расширение приложения напрямую связывается только с приложением хоста. Нет прямой связи между расширением приложения и содержащим его приложением; как правило, содержащее приложение даже не работает, пока работает автономное расширение.
Кроме того:
Виджет Сегодня (и никаких других типов расширений приложения) может запрашивать система, чтобы открыть содержащее ее приложение, вызывая openURL: завершение: метод класса NSExtensionContext. Любое расширение приложения и содержащее его приложение могут получить доступ к общим данным в определенном частным общим контейнером.
Если это степень обмена данными между контейнером и расширением, я не понимаю, как это могло бы Работа. Расширению потребуется доступ к узлу AVAudioEngine в режиме реального времени, поэтому, если пользователь содержащего приложения изменяет звуки, воспроизводит, приостанавливает, изменяет громкость и т. Д. c. все это будет отражено в выходных данных, которые получает хост-приложение.
И все же я чувствую, что убираю IAA, если AUv3 не имеет этой возможности, оставляет большой пробел в платформе. Надеюсь, есть еще один подход, о котором я не думаю.
Может быть, это должно работать наоборот, поэтому в моем случае приложение микшера предложит расширение аудиоустройства, а затем мое приложение (аудио player) будет хостом и предоставит аудио для расширения микшера. Но тогда у приложения микшера возникла бы та же проблема: он не мог получить входящий звук из своего расширения.