LINUX.ORG.RU

[iphone][core audio][linear pcm] Захват звука с микрофона

 


0

0

С помощью core audio захватываю звук с микрофона и пишу в файл. Через каждые n секунд получаю указатель и размер буфера сырых linear pcm-данных.

Частота дискретизации - 44100, 2 канала, 16 бит на канал; естественно, 1кадр=1пакет. В моем случае, вышеуказанное n=0.5 сек. Следовательно, каждые пол-секунды я получаю указатель на буфер размером 88200 байт (22050 измерений * (2 канала * 2байта_на_канал)).

Вопрос в том, как парсить эти 8КБ данных? При создании формата стоит флаг BigEndian и SignedInteger. Думал, это просто массив int16, где нечетные - 1 канал, четные - 2ой. Хер там - при разговоре в микрофон, то есть повышении громкости входного сигнала (которая детектится через отдельную хрень и ДАЕТ ВЕРНЫЕ ПОКАЗАНИЯ), среднее арифметическое всех int16 по каналам дает ВСЕГДА 16000 +/- 700, несмотря на имеющееся повышение громкости.

Пробовал SInt16, UInt16, UInt8, SInt8, UInt32, SInt32, float - не пашет - меняется только среднее арифметическое.

Проштудировал кучу манов, педивикию, rfc по lpcm, pcm и wav - ничего годного не нашел.

Кто-нибудь занимался парсингом raw lpcm или может подсказать, куда копать?

★★

Частота дискретизации - 44100, 2 канала, 16 бит на канал; естественно, 1кадр=1пакет. В моем случае, вышеуказанное n=0.5 сек. Следовательно, каждые пол-секунды я получаю указатель на буфер размером 88200 байт (22050 измерений * (2 канала * 2байта_на_канал)).

Ты что-то путаешь. Сначала говоришь, что 44100, потом 22050. И почему 2 канала, это же микрофон?

среднее арифметическое всех int16 по каналам дает ВСЕГДА 16000 +/- 700, несмотря на имеющееся повышение громкости.

Среднее арифметическое для целочисленного типа с диапазоном значений -8191..+8192 не может быть 16000.

Залей куда-нибудь сэмпл, дай ссылку.

mv ★★★★★
()
Ответ на: комментарий от mv

Сначала говоришь, что 44100, потом 22050

44100 в 1 секунду. У меня н=0.5 секунды => 22050 измерений. Здесь расчеты верны.

Почему 2 канала - без понятия. По видимому, надо разобраться с этим для уточнения проблемы. По идее, один из каналов будет заполнен нулями (я подозреваю, что так и есть), а второй - содержать реальные данные.

диапазоном значений -8191..+8192

why? 16бит => -32768...32767 Но среднее арифм. получается, не знаю, почему, около 16000.

Забыл сказать, что если эти данные записывать в файл, то звук великолепно воспроизводится, то есть, ошибки в самих данных нет. Ошибка кроется в том, как я эти данные собираюсь интрепретировать.

Байты с буферами сделаю завтрасегодня.

bk_ ★★
() автор топика
Ответ на: комментарий от bk_

UPD

Почему 2 канала - без понятия.

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

bk_ ★★
() автор топика
Ответ на: комментарий от bk_

диапазоном значений -8191..+8192

why?

Because спать мне надо :\

mv ★★★★★
()

Я сделал моносигнал => 44100 байт на буфер в 0,5 сек. Это, на самом деле, массив unsigned short (16bit). Самое удивительное, что в этих словах переодически получаются «инвертированные значения» (see this) (тут биг ендиан). «Инвертированные» - те, в которых левый-старший байт ff.

Скорее всего, я не до конца понимаю техпроцесс, но откуда там браться инвертированным словам?

Если брать среднее арифм. по словам исходного буфера, то получается 16000 +-700. Если же инвертировать инвертированные слова, то тогда уровень громкости отражается верно.

Что означают инвертированные слова в формате pcm?

bk_ ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.