Пытаюсь реализовать возможность записи звука с микрофона, подключенного в диф. режиме к плате L791. Записываю файл с параметрами NCh=1, Chn[0]=0x00. dKadr = 0, dFreq = 192. Конечный файл преобразую в wav с параметрами Sample Rate = 192000, Byte Per Sec = 32, Channels = 1. Микрофон с усилителем и фильтром.
Голос пишется, но с жуткими искажениями. Ярко выраженные металлические ноты и огромное количество шума, похожего на скрежет. Разобрать можно, но с большим трудом. Пытался подключить вместо микрофона сигнал с генератора и делать запись с теми же параметрами (генератор дает чистые 500Гц), так вот звук координально отличается если я слушаю генератор напрямую через наушники или слушаю записанный файл.
В чем может быть проблема??? Могу выслать записанные мной файлы в чистом виде и преобразованные в wav, любые логи и иную информацию. Бьюсь с этим косяком достаточно долго и пока безрезультатно...

Извините там имелось в виду Bit Per Second = 32

Забыл уточнить. Пишу из буфера сразу в файл так, как это реализовано в примере из драйверов test.cpp. Операционная система Astra Linux 64 bit

Konstantin, давайте разберёмся с аппаратной точки зрения. Ответьте на вопросы:
1. L-791 используете в одноканальном режиме? Какая частота АЦП? Какие настройки кадра? Какие настройки диапазона? К какому номеру контакта сигнального разъёма L-791 какая цепь подключена?
2. Та электрическая цепь, которая подключена ко входу L-791 (усилитель + фильтр), какие электрические параметры имеет (выходное  сопротивление, импеданс)? Если не знаете ответа на эти вопросы, выложите либо схему усилителя и фильтра, либо документацию  вышлете на support@lcard.ru .  Кабелем какой длины ЭТО  подключено к L-791? Тип кабеля?
3. Если наушники подключить к выходу усилителя, то там качество нормальное?
4. В LGraph или LGraph2 пробовали посмотреть форму и спектр сигнала, идущего с L-791 (обязательно при тех же самых настройках)? Например, при эксперименте с генератором искажения формы или спектра должны быть хорошо видны, если Вы наблюдаете на столько искаженный  сигнал, как Вы это описываете. Но если в L-Graph всё ОК, тогда см. п.5.
5. Вы уверены, что при преобразованиии в wav-файл что-то не перепуталось? Например, байты в слове. Или дополнительный код интерпретируется как прямой, или ещё что-то?...

Причины может быть примерно две: неправильное подключение сигнала или неправильное преобразование отсчетов.
Что такое 32 bits per second? Bits per sample, что ли? Но плата L791 выдает 16-битные отсчеты (с 12 значащими битами), Вы их преобразуете как-то или просто в заголовке WAV выставляете 32 бита (и куда столько?)

А действительно сохраните сырой факл и полученный из него wav (только небольшой, пожалуйста), можно его выложить на какой-нибудь файлхостинг и прислать ссылку.

Это 14-битный АЦП, т.е. 14 значащих бит.

кстати, один из простых способов получить похожее по описанию звучание - это перепутать знаковый/беззнаковый формат.

...при подаче чистого синуса можно и самостоятельно проконтролировать адекватность сырых данных, посмотрев в бинарном редакторе или, например, в Audacity (import raw, signed 16-bit pcm).

Для одноканального файла можно, например, преобразовать в WAV программой sox
sox -t raw -s -b 16 -c 1 -r 192000 myfile.raw myfile.wav

Konstantin, в подобной составной сложной системе нужно пытаться проверить систему по частям, локализуя проблемы. Например, можно и на вход L-791 генератор правильно подключить, чтобы проверить эту часть системы...

Давайте по порядку...
-> Гарманов Александр:
   1) Схема подключения - 16 диф. каналов, но запись ведется с 1-ого, остальные на земле. Все в соответствие со схемой в руководстве к плате.
   2) На этот вопрос ответить не смогу, ибо не электрик. Попробую выяснить. Хотя разработчики железа божились, что подключение на 100% соответствует Вашей схеме из руководства к плате.
   3) Сейчас данный вариант не представляется возможным, т.к. требуется перепайка разъема. Но попробуем сделать
   4) Да действительно посмотрел запись с генератора в программе LGraph1  и визуально никаких искажений не обнаружил. Чистый синус. Я так понимаю, что там должны быть очень очевидные искажения.
   5) Исходя из п.4 предполагаю, что ошибка именно в этом, но смущает слишком сильное искажение сигнала... Раньше занимался записью со звуковой платы и кодированием звука, но с такими искажениями при преобразовании raw->wav, raw->mp3 не сталкивался...

-> Александр Е:
   Тут на форуме мне сказали, что плата L791 выдает 32 бита на каждый отсчет! Т.е. 4 байта. Исходя из этого я просто указывал в заголовке wav файла BitsPerSample = 32. Если это не верно, тогда сколько же мне указывать бит в этом поле, 12, 14 или 16? Насколько я знаю 12 BitsPerSample быть не может...
   Насчет знакового и без знакового формата... Я указываю в заголовке wav  формат pcm это то, что вы имели в виду? По-моему там по умолчанию идет знаковый формат (pcm16). Хотя могу ошибаться...
   А каким образом в бинарном редакторе я могу увидеть искажения синуса? Поясните, пожалуйста.
   Делаю преобразование своей программой, используя стандартный файл wav.h с описанием wav заголовка, написанный по спецификации. Попробую Ваш метод, но подозреваю, что разницы не будет.

Спасибо! Жду Ваших ответов!

32-битный формат информации от L-791 описан в п.
"5.3.9. Формат данных буфера АЦП"  в http://www.lcard.ru/download/l791_users_guide.pdf

Там старшую часть 32-битного слова нужно отбросить, чтобы выделить только данные АЦП. - Похоже, что в этом проблема и состоит...

Знаковость WAV-PCM, насколько я знаю, такая: 8-bit unsigned, остальное signed.
Да, про служебные поля я не подумал - если Вы записали в файл _совсем_ сырые данные с платы, то там действительно ТЕХНИЧЕСКИ 32-битные слова, только данные АЦП в них занимают младшую половину, поэтому без преобразования не обойтись.
data16[i] = (int16_t)(data32[i] & 0xFFFF)
(signed 16-bit PCM).
(Это будет негромко, 1/4 диапазона)
Или чтобы погромче:
data16[i] = (int16_t)((data32[i] & 0xFFFF) << 2)

Мда... Читал п.5.3.9 дважды и как-то у меня наличие служебных данных в каждом отсчете с моей ошибкой не состыковалось Уверен, что ошибка именно в этом!
Значит, как я понял, младшие 16 бит из 32 - это как раз то, что мне нужно? Соответственно параметр BitsPerSecond = 16. Сейчас все исправлю! Огромное спасибо за помощь!

Ну да, только, как я написал, можно еще подправить усиление по вкусу, потому что 14-битные отсчеты L791 в диапазоне [-8192, 8191] займут 1/4 диапазона (-12 dB). При желании их можно умножить на 2 или на 4.

Александр, в руководстве (п. 5.3.9) значащие биты с 0 по 15 => 16 бит. Я не совсем понимаю, о каких 14 значащих битах идет речь. Поясните пожалуйста.

Т.е. 32 битные отсчеты с 16 бит данными + 16 бит служебной информации. А 14 бит это при каких тогда условиях? Или я опять что-то не понял?

Попробую объяснить. Для 16-битного целого со знаком диапазон представления чисел -32768...32767 -- это соответствует 16-ти значащим битам. Но у нас 14-битный АЦП, который использует диапазон -8192...8191 этого 16-битного целого, что теоретически соответствует 14-ти значащим битам. "Значащий" - это значит несущий информацию. Понятно?

Т.е. Вы просто не используете весь диапазон 16 битного числа. Это я могу понять. Но тем не менее по факту это 16 бит данных. А глубина квантования высокая мне и не нужна, ибо за качеством не гонюсь... Спасибо за помощь!!!

"Т.е. Вы просто не используете весь диапазон 16 битного числа"
-Именно так, поэтому Александр E предлагал  умножить на 4, чтобы "громкость" выравнить.

Константин, вопрос терминологический
Плата имеет 14-разрядный АЦП, но, поскольку данные передаются целыми байтами, отсчет представляется в виде 16-битного значения. Старшие 2 бита незначащие (содержат знаковое расширение, т.е. 0 для неотрицательных чисел и 1 для отрицательных).

Но Ваша звуковая подсистема будет считать эти отсчеты "по-настоящему" 16-битными, т.е. если для 14-битного знакового 8191 - это максимум диапазона, то для 16-битного это 1/4 его часть.

Если же выравнивать по "старшему" краю (т.е. сдвинуть значащие биты [13:0] в биты [15:2] 16-битного отсчета, а младшие 2 бита, например, обнулить), то будет использоваться полный диапазон (т.е. максимальная громкость звука) без потери информации. -8192*4 = -32768 (0x8000), 8191*4 = 32764 (0x7FFC).

Если для дальнейшей обработки абсолютный уровень сигнала безразличен, тогда совершенно все равно как выравнивать биты.

Остаётся добавить, что старшие 2 незначащие биты [15:14] содержат знаковое расширение, т.е. нули  для неотрицательных чисел и единицы для отрицательных, согласно принципу "дополнительного кода" представления отрицательных чисел, который используется в большинстве  компьютерных форматов данных. См. http://ru.wikipedia.org/wiki/%C4%EE%EF% … 1%EB%E0%29

Сделал парсинг служебной информации из 32 бит в 16, как Вы писали выше. Результата особого это не дало, эффекты металлических нот остались Опять не пойму, в чем дело. Ниже код парсинга:

    for (long int i = 0; i < flen/4; i++)
    {
    fread(buf4byte, 4, 1, input_fd);
    *buf2byte = (*buf4byte & 0xFFFF);
    fwrite(buf2byte, 2, 1, output_fd);
    }

flen - длина записанного файла,
buf4byte и buf2byte это int*.

А вот структура wav файла:
class formatChunk
{
public:
    string formatTag;            // "fmt "
    int formatSize;                // Size of chunk following this value
    short audioFormat;            // Two bytes here; value 1 for PCM
    short nChannels;            // Two bytes here, stereo here
    int sampleRate;                // 44100 here
    int byteRate;                // sampleRate * channels * bitsPerSample/8
    short bytesPerSample;        // channels * bitsPerSample/8, two bytes
    short bitsPerSample;        // Two bytes here
    formatChunk ()
    {
        formatTag = "fmt ";
        formatSize = 16;        // PCM default
        audioFormat = 1;        // PCM default
        nChannels = 1;            // Stereo default
        sampleRate = 44100;        //Default
        bitsPerSample = 16;        // Default
        bytesPerSample = nChannels *
            bitsPerSample / 8;
        byteRate = bytesPerSample * sampleRate;
    }
};

Посмотрите, пожалуйста, может я где ошибся...

Ну если заголовок как пишется в файл, а потом правильный data chunk, то в первом приближении как будто бы должно работать.

Покажите пример входных и выходных данных, что ли. Или в виде файлов, или, например, hex dump небольшого файла.