Цифровой программный кроссовер II

[emaster]

Коллеги!
Завожу отдельную ветку для обсуждения новой версии моего программного кроссовера - dePhonica version3.
Эта версия кроссовера полностью отличается от первой версии, которая обсуждалась здесь как с точки зрения кода (который переписан на 99%) так и с точки зрения функционала.
Разработка версии началась весной 2015 года и в настоящее время (начало 2016) находится в активной стадии.

Скачать preview версию можно по адресу: http://dephonica.com/?lang=ru
Текущая сборка на сайте от 21.03.2016.

Внимание!
Для корректной установки WDM драйвера на windows 7 с отключенными обновлениями, необходимо установить апдейт KB3033929, добавляющий поддержку цифровых подписей SHA-2.

Ссылка для x86 обновления: http://download.microsoft.com/downlo...033929-x86.msu
Ссылка для x64 обновления: http://download.microsoft.com/downlo...033929-x64.msu
Статья по обновлению windows: https://support.gamenet.ru/kb/articles/789-windows


Ограничения preview версии:
- максимум 6 каналов обработки
- требует перезапуска ядра каждые 30 минут

Основные возможности кроссовера:

- собственный WDM драйвер для ввода потока из стандартных аудио и видео плееров, браузеров, навигаторов и других программ.
- собственный ASIO драйвер для ввода потока из аудио плееров поддерживающих ASIO
- низкая задержка: около 50 мсек при использовании IIR фильтров и выводе на ASIO устройство
- поддержка ввода звука в форматах 16 bit integer, 24 bit integer, 32 bit floating point
- 2 входных канала и до 8 выходных
- вывод звука на устройства DirectSound, ASIO, Kernel Streaming
- вся обработка производится в 64 bit floating point
- фильтрация производится FIR фильтрами, IIR фильтрами или IIR фильтрами с автоматическим корректирующим фазовым FIR фильтром
- есть возможность создания фазового фильтра для коррекции ФЧХ внешнего IIR фильтра
- доступны два конволвера для FIR фильтров: FFT конволвер с алгоритмом Overlap-Add и линейный (Straight FIR), без использования FFT
- любой из FIR конволверов может использоваться совместно с одним или более IIR фильтром в каждом канале
- до 128 000 taps на канал при использовании FFT FIR
- доступны формы АЧХ семейств фильтров IIR: Linkwitz-Riley, Butterworth, Chebyshev
- доступен параметрический синтез АЧХ и ФЧХ для типов фильтров Low Pass, High Pass, Band Pass, Band Stop, Low Shelf, High Shelf
- два варианта параметрического задания фильтров Band Pass и Band Stop: нижней и верхней частотой среза или центральной частотой и полосой пропускания
- амплитудный и фазовый эквалайзер для произвольного изменения АЧХ или ФЧХ в канале обработки, с возможностью загрузки АЧХ или ФЧХ из текстового файла или из импульсного отклика в формате WAV
- любое сочетание FIR и IIR фильтров в канале обработки
- полноценный канал предварительной обработки исходного сигнала с отдельным набором фильтров
- возможность автоматической нормализации к 0 дБ АЧХ индивидуальных каналов или группы каналов
- регулировка усиления на входе и на выходе канала
- настраиваемая задержка в каждом канале с отключаемым sub-sample разрешением
- встроенный анализатор фактической частотной характеристики кроссовера с отображением общей АЧХ кроссовера, графиков АЧХ/ФЧХ/ГВЗ для каждого канала и возможностью суммирования АЧХ выбранных каналов в отдельном окне

Пример установки и настройки полной версии кроссовера (уже местами не соответствует действительности и будет перезаписан): http://www.youtube.com/watch?v=CF_YNp0IijE

============
Пополняемый FAQ:

Скрытый текст

Q: Для чего можно использовать кроссовер?
A: Прямое назначение кроссовера – разделить исходный сигнал на несколько сигналов, каждый из которых будет воспроизводиться отдельным динамиком. Для такого использования необходима многоканальная звуковая карта (или ЦАП), многоканальный усилитель (или несколько обычных – стерео или моноблоков) и многополосная акустика, каждый динамик в которой подключен к отдельному каналу усилителя отдельным кабелем. Самый простой и часто встречающийся пример такой акустики – система 2.1 с двумя фронтальными колонками и одним сабвуфером.
A: Кроссовер можно использовать для того, чтобы вывести один и тот-же сигнал (с обработкой или нет) на несколько выходов многоканальной звуковой карты. Например, первые 2 канала – звук для колонок, следующие 2 канала – звук для наушников. На колонки одни настройки эквалайзера (внутри кроссовера), на наушники – другие.
A: Также кроссовер можно использовать даже с обычными наушниками – как точный и продвинутый эквалайзер.

Q: Какое оборудование требуется для использования кроссовера?
A: Кроссовер может использоваться для различных целей практически с любым оборудованием. Минимальные требования – компьютер с Windows 7/8/10 и любая звуковая карта.


Q: Как перенаправить в кроссовер звук из программы или плеера, не поддерживающей вывод звука на ASIO устройства?
Q: Как вывести в кроссовер звук из видео плеера?
A: Выберите в плеере вывод на аудио устройство *dePhonica Virtual Audio Device*.

Q: Какие настройки требуются в видео плеере для работы через кроссовер?
A: При использовании в кроссовере IIR фильтров, никакой дополнительной настройки плеера не требуется. При использовании FIR фильтров (или IIR с линеаризацией), в плеере необходимо установить смещение звуковой дорожки в зависимости от порядка FIR фильтра. Например, для FIR фильтра с 8000 taps это около 250 мсек.


Q: Как ввести в кроссовер звук из внешнего источника (виниловый проигрыватель, кассетный магнитофон, пульт и т.д.)?
A: На данный момент можно использовать программу VoiceMeeter от VB-Audio - она поддерживает ввод с внешних источников. Скачать программу можно по ссылке: <a style="color: #505050; font-weight: bold;" href="http://vb-audio.pagesperso-orange.fr/Voicemeeter/">http://vb-audio.pagesperso-orange.fr/Voicemeeter/</a>
В будущем появится непосредственная поддержка ввода сигнала с входов звуковой карты в кроссовер.

[свернуть]

============

Список изменений:

Скрытый текст

30.03.2016

- Более устойчивый алгоритм проверки активации
- Исправлены bypass каналы без фильтров
- Исправлена инициализация таймера в WDM драйвере
- Исправлен номер версии в окне "О кроссовере dePhonica version3"
- Исправлен вывод сообщения "Устройство вывода не выбрано" при первой установке кроссовера


20.03.2016

- Переходные процессы в модуле вывода теперь обрабатывает машина состояний. Фейдинги стали четче, мягче и предсказуемее.
- Появился приоритет ввода с ASIO Sink драйвера - WDM замолкает, когда приходит поток с ASIO.
- Расстояние при редактировании задержки выводится в метрах / сантиметрах / миллиметрах

17.03.2016

- Появился WDM драйвер виртуального аудио устройства для ввода в кроссовер - можно перенаправить в кроссовер весь системный звук
- Уменьшилась latency - для IIR фильтров составляет ~50 мс
- По умолчанию фильтры создаются как IIR. При добавлении в тракт FIR фильтра выводится отключаемое предупреждение о дополнительной задержке в тракте.
- Диалог сообщений в конфигураторе стал отображаться поверх всех окон
- Появилась возможность инвертирования кривой в эквалайзере
- Появилась возможность смещения кривой в эквалайзере

09.03.2016

- Уменьшилась latency до ~500 мсек
- Добавились IIR фильтры Bessel и Legendre
- Тысячные доли миллисекунды меняются при изменении расстояния в компоненте Delay
- Исправлена ошибка с несохранением в пресете канала предварительной обработки при загрузке конфигурации из файла
- Исправлена каша из надписей на шкале Gain на графиках анализатора
- Добавил легенду к графикам в анализаторе
- Улучшена отправка логов - теперь отправляются независимо от IP адреса пользователя
- При перетаскивании канала с удерживаемым Shift (или Ctrl+Shift) копируются только фильтры - задержки и Gain не изменяются

[свернуть]

[sia_2]

Это как так, откуда log(N) в линейной свёртке берётся? AVX2 можно в 16 раз ускорить - но до 1500 всё равно далеко.

Обычный комп или ноут шумит почём халва.

Log(N) - это дерево суммирования частичных произведений. Подразумевается, что собственно FIR идеально параллелится и GPU ядер достаточно, чтобы его считать "в лоб", без FFT.

[Traktorist3d]

Блин конечно не мое дело, подсказывать кому, что делать, но нафига оно вообще нужно на win или mac? Полно продуктов с фильтрами и конвольверами, dephonica, jriver, roon, hqpplayer и т.д. .
Вот на ARM устройства получить нормальный комплекс фильтров, это да, ибо этого нет толком. В планах на одноплатниках работала бы Дефоника новая, но так и не вышла, и ещё проект более мене движется , но только как эндпоинт это Camillia dsp для pi2,3,4. Идеально было бы проект, который ставится на одноплатник, желательно на bbb antminer, который по сети принимает и по сети отдает на эндпоинты. И по отзывам bbb как эндпоинт оказывается лучше чем pi устройства.

[Кичай Данил]

Блин конечно не мое дело, подсказывать кому, что делать, но нафига оно вообще нужно на win или mac? Полно продуктов с фильтрами и конвольверами, dephonica, jriver, roon, hqpplayer и т.д. .
Вот на ARM устройства получить нормальный комплекс фильтров, это да, ибо этого нет толком. В планах на одноплатниках работала бы Дефоника новая, но так и не вышла, и ещё проект более мене движется , но только как эндпоинт это Camillia dsp для pi2,3,4. Идеально было бы проект, который ставится на одноплатник, желательно на bbb antminer, который по сети принимает и по сети отдает на эндпоинты. И по отзывам bbb как эндпоинт оказывается лучше чем pi устройства.

Приемлим ли одноплатник NVIDIA Jetson Nano? И чем обычный ПК не подходит? "Шумом" в цифровых потоках?

[E.Sokol]

Блин конечно не мое дело, подсказывать кому, что делать, но нафига оно вообще нужно на win или mac? Полно продуктов с фильтрами и конвольверами, dephonica, jriver, roon, hqpplayer и т.д.

Моих фильтров там совершенно точно нет.

---------- Сообщение добавлено 10:27 ---------- Предыдущее сообщение было 10:26 ----------

чем обычный ПК не подходит? "Шумом" в цифровых потоках?

Шумом вентиляторов и HDD.

[Meta|_]

Ну, если вы реализуете многопоточность на си через POSIX - на windows оно точно не откомпилится.

Вы про mingw? Не помню, что в нём с потоками, но скорее всего, они работают как надо.

А существующие open-source проекты все прошерстили? типа такого.

Я не шерстил, но точно знаю, что GNU Octave свёртку с помощью fft (fftconv() или что-то в этом роде из пакета signal) считает хорошо - неотличимо от свёртки в лоб до 10+ знаков после запятой. На чём написано и с использованием каких API/библиотек/систем команд - не интересовался.

Если сделать блокировки в потоках на семафорах/мьютексах, то будут потери на сменах контекста неприемлемые.

Так использовать соответствующие структуры и не переключать контекст без необходимости. Да и переключение в Линуксе - куда дешевле Винды...

[E.Sokol]

Вы про mingw?

Нет, я про функции типа _beginthread в в винде и pthread_create в линуксе.

Offтопик:
На хабре кто-то украл ваш аватар)

[Кичай Данил]

Так использовать соответствующие структуры и не переключать контекст без необходимости. Да и переключение в Линуксе - куда дешевле Винды...

А что потоку делать, когда он всё сделал? Сам ведь, без передачи контекста он не заблокируется..., ну то есть он может каким-либо системным вызовом типа epoll/select заблокироваться, передав ядру информацию о списке событий, при которых он просит отдать обратно управление. Реакция на эти события ядром будет рассмотрена не так быстро, как хотелось бы, более того время реакции мало предсказуемо и сильно зависит от конфигурации ядра, а значит использовать такой алгоритм недопустимо. Можно конечно вообще потоку завершиться, ну и потом потоки заново генерить, но это будет ещё дороже, чем блокировка.

[Meta|_]

Offтопик:

На хабре кто-то украл ваш аватар)

Я сам украл)

А что потоку делать, когда он всё сделал?

Если данных для обработки больше нет, то не вижу ничего плохого в том, чтобы заблокироваться в ожидании семафора. Если данные есть, значит их уже напихают в кольцевой буфер.
Простейший вариант примерно такой:
Управляющий поток получает входные данные, выделяет выходные буферы и раздаёт "задания" (скажем, указатели на буферы) worker-thread*ам через кольцевые буферы. Если соответствующий воркер спит - пробуждает его. У этого потока работы мало, так что бОльшую часть времени он будет спать.
Каждый из воркеров обрабатывает свои задания из своего буфера пока он не пуст. Если он опустел - засыпает.
Уведомлять управляющий поток о выполнении задания можно через аналогичный кольцевой буфер.

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

[Кичай Данил]

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

Так блокировка потока передаст управление ядру ОС, а потом, при возникновении события epoll/select, ядро ОС обратно передаст управление потоку программы. В итоге ядру ОС придётся для каждого потока сохранять контекст (текущие значения всех регистров ядра процессора в момент выполнения потока программы и некоторых дополнительных параметров выполнения), восстанавливать его обратно (что бы поток программы дальше начал выполняться после блокировки и ничего не заметил). Ядро ОС также вынуждено для каждого потока такой программы каждый раз выполнять планирование её потоков в очередь выполнения при возникновении ожидаемого события (наполнения буфера). Все это будет происходить довольно часто, а при увеличении количества потоков суммарное время может расти более чем линейно из-за специфик работы некоторых планировщиков процессорного времени в ядре.
Если писать программу с учётом глобальной совместимости (с разными ядрами), то такой подход не применим. (Это моё мнение, - можно конечно писать миллион версий для разных ядер и случаев...)

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

[Meta|_]

В случае интеграции библиотеки функций фильтра стандарта LADSPA в подсистему ALSA, блокировок в алгоритме фильтра не происходит вообще.

Ну так одно из двух - либо меньше потоков, либо больше переключений контекста. Я так и не понял, чего Вы хотите.
Есть ещё способ ждать в "бесконечном" цикле, как часто делают в мелких микроконтроллерах, но это негуманно в отношении ОС и других программ.

[Кичай Данил]

Ну так одно из двух - либо меньше потоков, либо больше переключений контекста. Я так и не понял, чего Вы хотите.
Есть ещё способ ждать в "бесконечном" цикле, как часто делают в мелких микроконтроллерах, но это негуманно в отношении ОС и других программ.

Способ с бесконечным циклом не применим в контексте применения многозадачной ОС, это верно. В МК его применяет при отсутствии ОС.
Каждый поток имеет свой контекст. Увеличение количества потоков только усугубляет проблему накладных расходов на их переключения.
Если ваша система "фильтрации" представляет из себя обёртку над функцией отправки буфера в звуковую подсистему и выполняется в программе проигрывателя в её собственном потоке процессорного времени, то блокировки в коде фильтрации не нужны. Я именно об этом. То есть, вы НЕ работайте обработчиком пополнения некоторого буфера, который должен блокироваться при отсутствии в нём новых данных и пробуждаться при их появлении. Вы просто обслуживаете функцию отправки буфера звуковых данных для чужой программы, она сама вызывает функцию Вашей библиотеки, а звуковая подсистема получает вместо оригинального пакета семплов изменённый Вашей функцией пакет. В таком исполнении не происходят блокировки и смены контекста в момент обработки звука. Если же в такой схеме попытаться увеличить количество потоков, получится, что вызываемая функция фильтра должна разделить исходные данные на части, передать их на фильтрацию в другие потоки и дождаться завершения фильтрации этими потоками. После завершения фильтрации потокам придётся или заблокироваться или закрыться, и то и другое обслуживает ОС. В случае блокировоки - это переключение контекста туда-обратно и постановка в очередь потока процессорного времени, в случае завершения/создания потоков - все совсем дорого, - создание/удаление структуры данных состояния для каждого потока в ядре.

[Meta|_]

Ещё раз. Вы хотите распараллеливать обработку или таки нет?
Если один поток и так успевает, то естественно, распараллеливать нет смысла, в т. ч. по описанным вами причинам. А если не успевает - придётся параллелить и мириться с накладными расходами.
Так и не понимаю, в чём вопрос...

[Кичай Данил]

Ещё раз. Вы хотите распараллеливать обработку или таки нет?
Если один поток и так успевает, то естественно, распараллеливать нет смысла, в т. ч. по описанным вами причинам. А если не успевает - придётся параллелить и мириться с накладными расходами.
Так и не понимаю, в чём вопрос...

Я пишу несколько движков (реализаций логики фильтра), хочу найти наиболее интересный вариант для себя и других пользователей. В одном из них (где я упарываюсь распараллеливанием) выполнение функции фильтра происходит в GPU, а для CPU остаётся единственный поток обработки, который действительно получает дополнительную нагрузку по времени в роли нескольких смен контекста туда/обратно при блокировке в момент синхронизации памяти host<->device и ожидании завершения ядра (мультипольной программы) GPU, но ничего другого он не выполняет вообще. Само распараллеливание происходит между потоками GPU, а в нём есть своя внутренняя логика планирования и отслеживания завершённости всех параллельных потоков из grid (некоторой заказанной параллельной задачи в нескольких потоках), которая не "отвлекает" ядро ОС.
Мои вопросы связаны с получением понимания для себя о том, как и кто решает конкретные проблемы производительности, и решает ли их вообще. Что именно предлагается конечному пользователю. Я ещё раз повторяюсь, что я не критикую, а хочу понять то, как именно обыграны конкретные моменты.
Пока из всего написанного вокруг конкретного решения я предполагаю, что для фильтрации используется fftw либа с БФП алгоритмом в одном потоке, сама либа возможно использует SSE (если скомпилирована с нужными ключиками). Подозреваю, что скользящий буфер исходных данных всегда сдвигается, что бы передать функциям либы fftw массивы данных в нужном порядке. Так ли это? И умеет ли fftw обслуживать односвязные/двусвязные кольцевые списки с указателем на первый элемент и длину списка (это нужно, что бы избежать сдвига буфера, и просто добавлять элемент в нужное место "кольца")? Какая логика генерации скользящего фильтра применяется (если это не список со связями) и сколько процессорного времени примерно тратится именно на эту генерацию в исследованиях сравнения производительности фильтров?

[E.Sokol]

1. Если вы хотите использовать многопоточность - нужно изучать современный с++, в котором оно встроено в язык включая все примитивы синхронизации. Без вариантов. Особенно если вы хотите, чтобы ваше решение было интересно ещё кому-то, кроме вас.

2. Для особого ленивых в FFTW есть поддержка многопоточности, так как БПФ тоже параллелится. Не один к одному, но достаточно.

3. в FFTW ничего, кроме БПФ нет. Кольцевые буферы нужно делать самому.

4. Использовать односвязный список для кольцевого буфера - это бред. Абсолютно ничего не даёт, ресурсов потребляет в десятки раз больше. Обычный массив с двумя указателями + инфаструктура на копирование блока данных в промежуточный буфер для БПФ. После БПФ также копируется (с частичным наложением) в выходной кольцевой буфер.

5. Вам также нужно определиться, делаете вы FIR с задержкой или без. Если заморачиваться на распараллеливание и GPU - то имеет смысл идти до конца и делать без задержки.

[Кичай Данил]

1. Если вы хотите использовать многопоточность - нужно изучать современный с++, в котором оно встроено в язык включая все примитивы синхронизации. Без вариантов. Особенно если вы хотите, чтобы ваше решение было интересно ещё кому-то, кроме вас.

2. Для особого ленивых в FFTW есть поддержка многопоточности, так как БПФ тоже параллелится. Не один к одному, но достаточно.

3. в FFTW ничего, кроме БПФ нет. Кольцевые буферы нужно делать самому.

4. Использовать односвязный список для кольцевого буфера - это бред. Абсолютно ничего не даёт, ресурсов потребляет в десятки раз больше. Обычный массив с двумя указателями + инфаструктура на копирование блока данных в промежуточный буфер для БПФ. После БПФ также копируется (с частичным наложением) в выходной кольцевой буфер.

5. Вам также нужно определиться, делаете вы FIR с задержкой или без. Если заморачиваться на распараллеливание и GPU - то имеет смысл идти до конца и делать без задержки.

1. Странно говорить о многопоточности вокруг языка программирования. Потоки - сущности операционной системы и язык программирования не сможет решить проблему генерации потоков никаким способом, кроме как прося операционную систему системными вызовами это сделать.
2. Я уже писал выше о том, как будет работать многопоточность при частых получениях малых порций данных. Совершенно не важно, в какой части кода будет происходить блокировка, внутри либы или в вашем коде.
3. Спасибо.
4. ок, я уже писал выше, что оно даёт исключение необходимости формирования промежуточного буфера, а вот экономия ОЗУ - вот это бред ИМХО.
ПС. Ну и порядки потерь на односвязный кольцевой список - по одному указателю для каждого элемента, то есть для x86 с float32 x2, если у вас буфер sizeof(float[4096])=16384 байт, то тут будет sizeof(struct self[4096] {float x, struct * self next})=32768 байт.
5. Задержка чего?

Я вполне могу считать себя junior в равной степени, как в контексте применения СИ, так и плюсов. И я как раз не буду использовать "встроенные в язык" многопоточные решения, так как я понимаю, как именно они работают на уровне операционной системы.

[E.Sokol]

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

И что? Файл - это тоже сущность операционной системы, однако это не мешает вам писать cout вместо open_file / write_to_file / close_file (ну или как они там в линуксе называются)

ок, я уже писал выше, что оно даёт исключение необходимости формирования промежуточного буфера, а вот экономия ОЗУ - вот это бред ИМХО.
ПС. Ну и порядки потерь на односвязный кольцевой список - по одному указателю для каждого элемента, то есть для x86 с float32 x2, если у вас буфер sizeof(float[4096])=16384 байт, то тут будет sizeof(struct self[4096] {float x, struct * self next})=32768 байт.

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

Задержка чего?

Фильтрованного сигнала. С использованием БПФ в чистом виде она составляет размер БПФ-блока.

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

Стало быть, разработчики с++ наряду с комитетом по стандартизации - глупцы? Ну ок.

[Кичай Данил]

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

Память выделяется или резервируется для кольцевого списка ровно один раз. Её НЕ нужно перевыделять или освобождать во время работы фильтра.

Примером кольцевого односвязного списка является массив структур struct element[bufferSize] {float data, struct * element p, struct * element n} circteBuffer, для работы с ним также потребуется указатель на первый элемент struct * element entrypoint. Работа с таким кольцевым списком представляет из себя замену первого элемента на текущий entrypoint.data = current и перемещение указателя первого элемента на следующий entrypoint=entrypoint.next .

Что касается плюсов и дураков, отвечу так, что цель плюсов - облегчить читаемость и удобство разработки кода программистам с попыткой минимизации рациональности этого кода после компиляции, но не без неё. Именно поэтому, низкоуровневые части программ, где важно то, как именно будет выполнятся код, а не то, как он написан пишутся на СИ, простым примером того является ядро Linux или библиотека fftw.

В моём фильтре задержка накладывается только самим ядром фильтра.

А про файлы и cout, так вас и не понял, могу только предложить учить матчасть, например, http://stolyarov.info/books/programming_intro/vol3 . И это я предлагаю с целью изучения того, как именно работает среднестатистическая операционная система, а не с какой-то другой.

[E.Sokol]

Память выделяется или резервируется для кольцевого списка ровно один раз. Её НЕ нужно перевыделять или освобождать во время работы фильтра.

Примером кольцевого односвязного списка является массив структур struct element[bufferSize] {float data, struct * element p, struct * element n} circteBuffer, для работы с ним также потребуется указатель на первый элемент struct * element entrypoint. Работа с таким кольцевым списком представляет из себя замену первого элемента на текущий entrypoint.data = current и перемещение указателя первого элемента на следующий entrypoint=entrypoint.next .

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

Что касается плюсов и дураков, отвечу так, что цель плюсов - облегчить читаемость и удобство разработки кода программистам с попыткой минимизации рациональности этого кода после компиляции, но не без неё. Именно поэтому, низкоуровневые части программ, где важно то, как именно будет выполнятся код, а не то, как он написан пишутся на СИ, простым примером того является ядро Linux или библиотека fftw.

Когда важно, как именно должен выполняться код - он пишется на ассемблере. Линукс написан на си, потому что когда он начал писаться, никаких плюсов не было. FFTW написан на си просто потому, что его авторы не знают с++, и это приносит много неудобств при работе с этой библиотекой (к счастью, для БПФ у меня есть своя, которая в некоторых случаях FFTW даже обгоняет).

Смысл использования с++ для многопоточности в том, что он позволяет писать платформенно-независимый код, позволяя избавиться от кучи конструкций в виде #ifdef LINUX ... #ifdef WINDOWS ... #ifdef MACOS ... и необходимости знать как именно происходит взаимодействие с объектами синхронизации на отдельно взятой платформе.

А ещё, когда программист говорит, что с++ не нужен - то это только потому, что он его не знает. С++ и был придуман для того, что освободить программиста от рутинной работы и головной боли, в первую очередь по отслеживанию выделения/освобождения/утечек памяти и злоупотребления глобальными переменными.

А про файлы и cout, так вас и не понял, могу только предложить учить матчасть, например, http://stolyarov.info/books/programming_intro/vol3

Вот и ответ, кому именно здесь нужно учить матчасть.

1) даже самый начинающий линуксоид знает, что "всё есть файл". Однако программировать исходя из концепции "всё есть файл" довольно неудобно, поэтому в языках программирования, в том числе и в си, существуют высокоуровневые абстракции для этого (printf например, раз о cout вы не знаете).

2) Единственная книга, по которой нужно учить устройство ОС - это классический труд "Современные операционные системы" Таненбаума, по которому учился Торвальдс и который дополняется и переиздаётся до сих пор.

[fulton]

Извиняюсь, что влез.
Но новость, сервер активации вновь работает. мне удалось активировать программу.

[алек-сей]

Скачал, номер прислали.

fulton,