2010-03-04 4 views
4

У меня есть UISlider, действующий как скруббер. При перетаскивании большого пальца я выполняю следующее:Использование MPMusicPlayerController, настройка musicPlayer.currentPlaybackTime, чтобы искать, но занимает второе место, чтобы вступить в силу

- (void) _seekTo:(double)playbackTime { 
    mPlayer.currentPlaybackTime = playbackTime; 
} 

Это прекрасно работает, музыка ищет вперед. После выпуска большого пальца, я перезапускаю NSTimer, чтобы отправлять обновления времени, чтобы синхронизировать UISlider. Проблема заключается в том, что при выпуске большого пальца первые несколько обратных вызовов содержат предыдущее значение времени. Это приводит к тому, что большой палец возвращается в исходное положение перед возвратом к новому значению. Очень неприглядно.

У кого-нибудь есть опыт работы с этим поведением и способ исправить? Я могу предоставить образец проекта, если вы хотите, чтобы это продемонстрировало эту аномалию.

ответ

1

Возможно, это потому, что в буфере уже есть декодированные данные, когда вы начинаете искать. Вы ищете минуту вперед, но в буфере есть несколько миллисекунд аудио, и когда эти ведра играют, игрок сообщает свою позицию в файле как текущую. Только тогда появятся новые ведра из обновленной позиции, и маркер начнет вести себя. (Просто теория.)

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

+0

Спасибо за ответ. Это то, о чем я думал, но был удивлен, что игрок не будет нести ответственность за то, что при установке времени currentPlayBack, что он сделает любой необходимый сброс кэшированного аудио и просто продолжит работу из заданного местоположения. Идея фильтрации, которую вы предлагаете, - это то, что я рассматривал до этого поста, но хотел знать, кто-то испытал это, и если я упустил что-то очевидное. Поскольку нигде в документации нет упоминания об этом, я бы склонялся к тому, чтобы классифицировать это как ошибку или, по крайней мере, плохую реализацию. Ура! – gnasher