Поддерживается ли синхронизированный цикл для AKPlayers, которые имеют кратную продолжительность? - PullRequest
Новая
       82

Поддерживается ли синхронизированный цикл для AKPlayers, которые имеют кратную продолжительность?

0 голосов
/ 09 мая 2020

Я хотел бы знать, поддерживается ли синхронизированный цикл для AKPlayer (ов), кратных по продолжительности?

Кажется, это не поддерживается или, если не предназначено, это ошибка? Нашел похожий отчет здесь ( Как использовать l oop, если трек не был запущен с самого начала (с типом буферизации = .always в AKPlayer) ), где я думал, что предлагаю решение, но после множество тестов показали, что предложенное решение тоже не работает. См. Приложение (*)

Я планировал записать несколько циклов с длительностью, равной или кратной наименьшей loop. Во-первых, обнаружил, что синхронизация не удалась при попытке запустить .play для нескольких AKPlayer в одной и той же AVAudioTime начальной точке. После нескольких попыток, исправлено сохранением буферизации .always, среди прочего, например, метода .prepare. Так что, надеюсь, это не в порядке ...

Проблема в том, что я ожидаю прослушать несколько loops звуков синхронно, даже если продолжительность некоторых из них в 2 или 4 раза больше ...

Итак, ожидая работы цикла для основного требования, где: 

 - Loop1 of duration 2.5 [looping]
 - Loop2 of duration 2.5 [looping]
 - Loop3 of duration 5 [looping]

Заметил, что Loop3 ведет себя плохо, где последняя половина повторяется несколько раз, скажем, для 4 / 4, глядя на количество ударов, мы услышим следующее: 

 - Loop1: 1 2 3 4, 1 2 3 4, 1 2 3 4, 1 2 3 4
 - Loop2: 1 2 3 4, 1 2 3 4, 1 2 3 4, 1 2 3 4
 - Loop3: 1 2 3 4  5 6 7 8, 5 6 7 8, 5 6 7 8

Ожидается ли сбой? есть loop отдельных плееров, длительность которых кратна, функция, которая поддерживается?

После еще нескольких тестов я обнаружил, что это происходит после добавления третьего трека. Например: 

 - Loop1: 1 2 3 4
 - Loop2: 1 2 3 4 5 6 7 8

Кажется, пока все работает нормально, но теперь я добавляю новую дорожку:

  • Loop1: 1 2 3 4
  • Loop2: 1 2 3 4 5 6 7 8
  • Loop3: 1 2 3 4

Я слышу:

  • Loop1: 1 2 3 4 1 2 3 4 1 2 3 4
  • Loop2: 1 2 3 4 1 2 3 4 5 6 7 8
  • Loop3: 1 2 3 4 1 2 3 4 1 2 3 4

Я бы попробовал AKClipRecorder, но обнаружил, что мне нужно объявить длину до времени записи, это нарушает основное требование:)

(*) Аудиофайл, раскрывающий проблему, это тест проводился с AKWaveTable, но, похоже, та же проблема. Я постараюсь переписать код, которым будет легче поделиться, чтобы увидеть, связано ли оно с моей реализацией, но есть ссылка, которой я поделился вверху, где кто-то другой обнаруживает ту же проблему.

https://drive.google.com/open?id=1zxIJgFFvTwGsve11RFpc-_Z94gEEzql7

1 Ответ

0 голосов
/ 09 мая 2020

Я считаю, что у меня возникла проблема, и это связано с планированием времени начала воспроизведения для новых лупов.

Раньше я записывал al oop, а затем воспроизводил его на currentTime, который - это ценность главного игрока. Проблема с этим связана с startTime, которое player держит в своем состоянии, которое, с моей точки зрения, является неизменным, учитывая, что оно считывается из памяти. Что всегда будет более или менее верно для конечной точки мастера l oop, которая является средней точкой для записанного l oop, который оказывается в два раза больше или в несколько раз больше основного l oop .

Чтобы решить эту проблему, я запланировал элементы игрока по-другому, а именно: 

player.startTime = 0
player.endTime = audioFile.duration
let offsetCurrentime = ((beatLength * 4.0) - currentTime)
player.play(at: AVAudioTime.now() + offsetCurrentime)

.startTime определяет начало начальной точки l oop, я также объявил длину продолжительности как .endTime; Наконец, я вычислил длину главного bar или главного l oop, которые я использую в качестве эталона (или часов петлителя), которые затем передаются в метод play. Это означает, что я планирую воспроизвести его на startTime, а не на currentTime, поскольку это может вызвать проблемы, как я уже говорил раньше!

Подводя итог, используйте свойство at of метод .play для планирования, когда начинать с starting point, а НЕ с текущего времени, когда l oop играет.

...