Обработка данных, полученных со входа звуковой карты

[ImmortalAlexSan]

Здравствуйте. Думаю, что это подходящий раздел для этой темы. Язык программирования мало интересует, нужна информация другого плана. Сейчас опишу то, что имею на данный момент.
На вход звуковой карты подаются какие-то данные. Для приема и обработки этих данных я использую драйвер ASIO4ALL и, соответственно, библиотеку (NAudio), которая содержит функции для работы с этим драйвером. Сейчас пользуюсь C# + WinForms. Проблема в следующем. Не могу разобраться в каком формате приходят данные. При приеме данных в буфер типа byte[кол-во сэмплов в буфере * 4] данные выглядят так: 0, x1n, x2n, x3n, n = 0 .. размер сэмпла. Т.е. в каждой тетраде я всегда имею первый 0. Если массив представлять как int[кол-во сэмплов в буфере], то появляется другая закономерность: 223454, 344556, 445656, 344400, 223487, 143456, 89800, -20345, -123405, -234543, -345356 и снова возрастание. Тут я уже как бы вижу свою синусоиду, подаваемую на вход. Трудность в определении амплитуды в каждой точке n (0..кол-во сэмплов в буфере) по временной оси. Кроме этого интересует определение уровня звукового сигнала, его частоты и прочих основных параметров. Знаю, что при ДПФ/БПФ тактовая частота - 1/n, где n - номер гармоники с наивысшей амплитудой. Верны ли мои предположения по этому второстепенному вопросу? Если не сложно, растолкуйте подробно о приведении входных данных к виду осциллограммы или же можно ссылками на источник, где это можно узнать.

[ImmortalAlexSan]

Вопрос решен. Решил калибровкой, а также вспомнил о замечательной формуле: dB = 10 * log10(A / A0).

[ImmortalAlexSan]

Хочу вот еще что спросить. Как реализовать механизм синхронизации? Строю я эту вольт-временную зависимость и вместо плавно идущего графика получаю в отображении два графика, смещенных по фазе относительно друг друга. Проверяю данные - четко одна синусоида, приостанавливаю программу - отображается одна синусоида, а при работе их две... Ну это и очевидно. Запись 689 буфферов по 64 фрейма каждый в 1 секунду на вход звуковухи (примерно 44100 Fд), а отрисовка этих буфферов с помощью OpenGL идет минимум в 10 раз быстрее, следовательно все равно играет роль скорость приема данных. Если ее замедлить, то данные потеряются. Вот каким образом можно отрисовать 689*64*4 байт/секунду? Как правильно синхронизироваться?
P.S. В глубине души я понимаю, что этот вопрос снова повиснет в воздухе... Но все-таки?

[waleri]

Сообщение от ImmortalAlexSan

Вот каким образом можно отрисовать 689*64*4 байт/секунду? Как правильно синхронизироваться?

Тут два вопроса. Насчет "как рисовать" не скажу, ибо не совсем понятно что надо нарисовать. Насчет "как синхронизоваться" - у вас есть частота сэмплирования, у вас есть объем полученных данных, отсюда не проблем вычислить время и наоборот. Вопрос, *что* с *чем* надо синхронизовать? Картинку с данными? По индексу в данных вычисляем время по времени вычисляем позицию на экране.

[s-andriano]

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

А вообще, звук принято отображать на экране результатом Фурье-преобразования в логарифмическом либо двойном логарифмическом масштабе.

И еще: современные звуковые контроллеры, как правило, аппаратно выдают только 48кГц, а 44.1 получается посредством программной интерполяции. Так что лучше брать с карты прямой сигнал, а не преобразованный драйверами.

На всякий случай: отсчет 4 байта - это 16-разрядный стереосигнал, т.е. два двухбайтовых отсчета для левого и правого каналов.

Вдогонку: кажется, понял, что значит "синхронизироваться" - это в режиме осциллограммы (не БПФ) чтобы на экране была не мешанина сигналов, а стабильная синусоида.
Если так, то не следует стремиться отобразить целое количество буферов - пусть момент синхронизации (начало развертки на экране) будет находиться внутри буфера, а не на его границе. Рассматривай последовательность буферов как один непрерывный поток, и "режь" его в нужных местах.

[ImmortalAlexSan]

Тут два вопроса. Насчет "как рисовать" не скажу, ибо не совсем понятно что надо нарисовать. Насчет "как синхронизоваться" - у вас есть частота сэмплирования, у вас есть объем полученных данных, отсюда не проблем вычислить время и наоборот. Вопрос, *что* с *чем* надо синхронизовать? Картинку с данными? По индексу в данных вычисляем время по времени вычисляем позицию на экране.

Как раз так и делаю. В результате получается мешанина сигналов.

На всякий случай: отсчет 4 байта - это 16-разрядный стереосигнал, т.е. два двухбайтовых отсчета для левого и правого каналов.

Ну я беру сигнал и так напрямую. ASIO для этого и написана. Вот только там 1 сэмпл - это 4 байта, и когда звуковая карта может воспроизводить только 8 бит, 3 старших байта превращаются в нули/мусор (самый старший байт всегда равен нулю). И для каждого канала там отдельный буфер. Т.е. я на 100% уверен, что при приеме и воспроизведении с одного канала, там только одна синусоида.

Вдогонку: кажется, понял, что значит "синхронизироваться" - это в режиме осциллограммы (не БПФ) чтобы на экране была не мешанина сигналов, а стабильная синусоида.
Если так, то не следует стремиться отобразить целое количество буферов - пусть момент синхронизации (начало развертки на экране) будет находиться внутри буфера, а не на его границе. Рассматривай последовательность буферов как один непрерывный поток, и "режь" его в нужных местах.

Видимо, вы действительно поняли о чем я. Можно подробнее об этом методе, а то не очень понял. Как определить "нужные" места для резки? Это же непрерывный поток данных, а вдруг будет не периодический сигнал? Тогда я тупо теряю какую-то часть из визуального восприятия.
Мне тут пришла идея, но она не нравится мне из-за постоянно растущего объема используемой памяти (примерно размер приходящих данных в секунду, счет идет на КБ данных). Записывать в память все приходящие данные, а с помощью OpenGL смещать матрицу проекции ровно на размер буфера/вида отображения со скоростью 25 кадров в секунду. Тогда при приостановке анализа, можно будет прокрутить вперед или назад отображение сигнала.