2016-11-22 14 views
2

Я пытаюсь разработать приложение, которое воспроизводит данные PCM с сервера.Как проигрывать потоковые данные PCM с сервера в iOS?

Я использовал AudioQueue, но он не работает.

PCM формат данных (от сервера):

Sample rate = 48000, num of channel = 2, Bit per sample = 16 

И, сервер не потоковом фиксированные байты клиента.

(Streaming переменные байты Ex: 30848., 128, 2764, ... байт)

Мой исходный код:

Здесь ASBD структура, что я выставиться & создать аудио очереди объекта (язык: Свифт)

// Create ASBD structure & set properties. 
var streamFormat = AudioStreamBasicDescription() 

streamFormat.mSampleRate = 48000 
streamFormat.mFormatID = kAudioFormatLinearPCM 
streamFormat.mFormatFlags = kLinearPCMFormatFlagIsSignedInteger | kAudioFormatFlagIsPacked 
streamFormat.mFramesPerPacket = 1 
streamFormat.mChannelsPerFrame = 2 
streamFormat.mBitsPerChannel = 16 

streamFormat.mBytesPerFrame = (streamFormat.mBitsPerChannel/8) * streamFormat.mChannelsPerFrame 
streamFormat.mBytesPerPacket = streamFormat.mBytesPerFrame 
streamFormat.mReserved = 0 

// Create AudioQueue for playing PCM streaming data. 
var err = AudioQueueNewOutput(&streamFormat, self.queueCallbackProc, nil, nil, nil, 0, &aq) 

... 

Я выставиться структура ASBD & объекта создаются как и звуковыми сообщения выше.

воспроизведения звуковых сообщений в потоковом данных PCM очень хорошо в течение нескольких секунд,

но вскоре играет звук и выключается. Что я могу сделать?

(по-прежнему потоковое воспроизведение и очереди звуковых сообщений)

Пожалуйста, дайте мне любую идею.

+0

работать с более низкой шириной полосы пропускания? –

+0

Pardon? Я не знаю, что ты говоришь хорошо. – user6081283

+0

Это работает, когда вы пытаетесь передать более компактный формат, например, mp3? –

ответ

5

Вам нужно сделать (по крайней мере) две вещи:

Вам нужно для буферизации данных для обработки задержки джиттера и различных размеров пакетов между данными с сервера, а также данные о том, что аудио запросов очереди обратного вызова. Типичное решение включает использование кругового fifo/buffer, предварительно заполненного определенным количеством данных, достаточным для работы с худшим сетевым дрожанием (вам нужно будет статистически проанализировать это число). Обратный вызов очереди звука может просто скопировать запрошенный объем данных из кругового fifo. Сетевой код пытается сохранить его заполненным.

Вам также может понадобиться какой-то способ скрыть ошибки, когда две скорости не являются достаточно идентичными: например, каким-то образом дублировать или синтезировать дополнительный звук, когда скорость сети слишком медленная, и каким-то образом не учитывать выборки, когда скорость сети слишком высока, причем оба способа пытаются быть настолько неразборчивыми, насколько это возможно, и без громких щелчков при любых скоростях разрывов или выбывших из сети.

+0

Вторая часть применяется только в том случае, если это поток в реальном времени. В противном случае клиент может контролировать, как быстро он считывает данные с сервера и адаптирует его к скорости воспроизведения. – Codo

+0

Даже потоки, не относящиеся к реальному времени, могут подвергаться временным отключениям сети (перегрузка, слишком много потерянных пакетов и т. Д.). – hotpaw2

+0

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