Виртуальные кабеля, ASIO и задержки

[E.Sokol]

Попробовал использовать виртуальные аудио-кабеля отсюда и отсюда, чтобы обрабатывать аудио-поток через своё приложение. И всё вроде работает, только совершенно дикая задержка в 2-3 секунды. Проблема точно не в приложении, поскольку при использовании реальных устройств всё чётко. Может, кто-нибудь сталкивался?

Искал похожее для ASIO, но не нашёл. В принципе, не так уж и сложно написать самому, но не хочется заморачиваться, да и скорее всего, тут я тоже чего-то не догоняю.

---------- Сообщение добавлено 07.02.2022 в 13:17 ---------- Предыдущее сообщение было 06.02.2022 в 20:34 ----------

Всё-таки это я лошара! У меня проблема, весьма неочевидный баг оказался. Но тему пока не закрываю, потому что вопрос с ASIO всё ещё открытый.

[E.Sokol]

Это разными process*ами, или всё в одном?

Не понял вопрос.
3) Входные/выходные данные не обязательно ограничивать числами с плавающей точкой. У меня там лежит ещё один double, который можно или игнорировать, или воспринимать как мнимую часть, или как производную, или как расширенную точность. Ещё лежат int и bool на всякий случай.
4) для этого предполагался специальный тип контейнера, который самостоятельно делает FFT до и после.

А почему тогда maxDelay = 48k в примере?

Потому что под линию задержки нужно выделять память и хз, кому её сколько надо. Поэтому секунда по-умолчанию. Можно изменить на любое другое в процессе, перекомпиляция не потребуется.

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

Ну сегодня меньше, завтра больше Так всегда, сначала хорошая идея, потом народ подтянется

Ну да, подтянется и начнёт рассказывать о бесполезности и ненужности

[mellowman]

Не понял вопрос.
3) Входные/выходные данные не обязательно ограничивать числами с плавающей точкой. У меня там лежит ещё один double, который можно или игнорировать, или воспринимать как мнимую часть, или как производную, или как расширенную точность. Ещё лежат int и bool на всякий случай.
4) для этого предполагался специальный тип контейнера, который самостоятельно делает FFT до и после.

А, то есть каждый плагин работает с чем-то одним (fft/double/complex/тп) понятно тогда.

Потому что под линию задержки нужно выделять память и хз, кому её сколько надо. Поэтому секунда по-умолчанию. Можно изменить на любое другое в процессе, перекомпиляция не потребуется.

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

Это в 48к секунда, а в 44.1 уже не секунда. Не увидел в примере задержки ничего про поддержку разных частот, поэтому и уточнил

[E.Sokol]

Нужно

В таком случае не могли бы вы поделиться своими соображениями (остальные тоже могут) по поводу минимальной необходимой функциональности, при которой имеет смысл выкладывать это творение на всеобщее обозрение? Потому что если ориентироваться на мои собственные хотелки, то оно не закончено будет никогда

А хочется примерно следующего:

WASAPI ввод/вывод для разных устройств одновременно - 50% сделано, сейчас прямо над этим работаю;
WASAPI синхронизация ввода/вывода для минимизации задержек - 0% сделано, вроде бы в WASAPI есть инструмент для этого;
синхронизация разных устройств вывода через микрофон - 0% сделано, сложно в реализации, но есть непроработанные идеи касательно необходимого мат.аппарата;
синхронизация АЧХ разных колонок - 0% сделано, ещё сложнее - но тоже есть идеи;
ASIO хост - 1% сделано, но сделать несложно должно быть;
Загрузка VST-плагинов - 1% сделано - нашёл подходящую библиотеку, но ещё не вникал в неё;

Задержка сигнала - сделано;
Стандартные биквад-фильтры - сделано;
Произвольные биквад-фильтры - 99% сделано, не определился с тем, стоит их выносить в отдельный модуль или сделать частью предыдущего, и как лучше задавать параметры (через входа или свойства);
Фильтры Чебышева-Баттерворта - вроде нашёл готовую реализацию, но она не особо стабильно работает;
Быстрая свёртка с FIR-фильтром - сделано;
Особо быстрая свёртка с FIR-фильтром - 80% сделано, нужно адаптировать ассемблерный код под x64 платформу;
Свёртка с нулевой задержкой - 0% сделано, но знаю как;
Произвольный FIR-кроссовер - раскидан кусками по разным проектам;

Генератор белого/розового шума - есть, но пока только через random;
генератор синусоиды - есть;
генератор свип-тона с линейной АЧХ - есть;

Спектроанализатор на уровне концепции - только логарифмический масштаб, только один вход, только одна, зато настраиваемая оконная функция;
Осциллограф на уровне концепции - только один вход, фиксированный масштаб;
Элементы управления - только ручка (Knob), и ту переделывать надо;

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

---------- Сообщение добавлено 17.02.2022 в 11:55 ---------- Предыдущее сообщение было 16.02.2022 в 15:49 ----------

Чем это лучше VST?

Принципиальная разница в том, что для VST-плагинов нужен хост. Объём минимального кода для написания VST-хоста можно оценить, например, в этом проекте (и в лучших традициях c++ кода он конечно же не скомпилируется сразу из-за отсутствия файлов из VST SDK, которые внезапно ещё и с официального сайта Steinberg скачать уже нельзя из-за прекращения поддержки версии 2). В моём случае никаких хостов не нужно, потому что устройства ввода/вывода это такие же модули, наследующие общий интерфейс, а c# сам подгружает необходимые dll-ки.

Вот, например, как выглядит код для вывода синусоиды на устройство вывода по-умолчанию:

var sine = new SineGenerator();
sine["Hz"] = 1000; // частота
var waveout = new WasapiOut();
var box = new ModuleContainer();
Module.Wire(sine, "out", "L", waveout);
Module.Wire(sine, "out", "R", waveout);
box += sine / waveout;
box.Sort(); // топологическая сортировка
box.Reset(); // сброс внутренних состояний
waveout.Start();

Всё.

[mellowman]

Принципиальная разница в том, что для VST-плагинов нужен хост.

Никакой разницы нет, тот же minihost который я кидал можно использовать и отдельно и как плагин.

Объём минимального кода для написания VST-хоста можно оценить, например, в этом проекте (и в лучших традициях c++ кода он конечно же не скомпилируется сразу из-за отсутствия файлов из VST SDK, которые внезапно ещё и с официального сайта Steinberg скачать уже нельзя из-за прекращения поддержки версии 2).

1) Какая разница сколько кода нужно для хоста?
2) Можно оценить и чуть по-другому: https://github.com/RustAudio/vst-rs/...simple_host.rs более точно, так сказать

В моём случае никаких хостов не нужно, потому что устройства ввода/вывода это такие же модули, наследующие общий интерфейс, а c# сам подгружает необходимые dll-ки.

Вот, например, как выглядит код для вывода синусоиды на устройство вывода по-умолчанию:

var sine = new SineGenerator();
sine["Hz"] = 1000; // частота
var waveout = new WasapiOut();
var box = new ModuleContainer();
Module.Wire(sine, "out", "L", waveout);
Module.Wire(sine, "out", "R", waveout);
box += sine / waveout;
box.Sort(); // топологическая сортировка
box.Reset(); // сброс внутренних состояний
waveout.Start();

Всё.

А частоту (fs), старт/стоп, весь роутинг — сами по себе плагины решают? Или всё-таки Module.Wire и есть хост? (тут непонятно конечно что за Module, и почему не box.wire, наверно тоже c# сам всё делает)

[E.Sokol]

Никакой разницы нет

Тогда покажите ваш вариант с 10-ю строчками кода, решающую ту же задачу.

---------- Сообщение добавлено 14:46 ---------- Предыдущее сообщение было 14:30 ----------

А частоту (fs), старт/стоп, весь роутинг — сами по себе плагины решают?

Так в коде есть роутинг (функция Wire, специально её явно прописал, хотя есть более краткий вариант записи), и старт (функция Start(), куда очевиднее-то?). Частота дискретизации привязана к контейнеру, модуль её получает через Owner.Samplerate, устройства ввода/вывода также могут её установить исходя из поддерживаемых форматов. 44100 или 48000 обычно все поддерживают. Нужна другая - пишем box.Samplerate = 384000 перед стартом.

Или всё-таки Module.Wire и есть хост?

Нет.

тут непонятно конечно что за Module

Имя базового класса, от которого все наследуются.

и почему не box.wire

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

---------- Сообщение добавлено 14:59 ---------- Предыдущее сообщение было 14:46 ----------

Можно оценить и чуть по-другому: https://github.com/RustAudio/vst-rs/...simple_host.rs более точно, так сказать

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

var plugin = Module.Load("myplugin.dspm");

Ну и роутинг на вывод звука я что-то там не обнаружил. Инкапсулировать загрузку dll в отдельный метод много ума не надо.

[mellowman]

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

Чтобы пыль не садилась?

А почему они хранятся с сложением и делением? Только сейчас заметил кстати

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

Ну так да, в 2 раза лучше минимум

var plugin = Module.Load("myplugin.dspm");

Главное в try catch не оборачивать, как в сравниваемом варианте

Ну и роутинг на вывод звука я что-то там не обнаружил. Инкапсулировать загрузку dll в отдельный метод много ума не надо.

Так вывод никакого отоношения к vst не имеет. Сам Wasapi тоже не в 3 строчки написан, для выбора бэкенда (кроссплатформенно), девайса, формата частоты в отдельные библиотеки. Прокинуть туда/оттуда буфер думаю должно быть под силу

[E.Sokol]

А почему они хранятся с сложением и делением? Только сейчас заметил кстати

Перегрузил эти операции ради краткости записи, чтобы можно было в одну строчку писать. Так же и роутинг для последовательного соединения можно в одну строчку записать:

--player["L","L",mono];
--player["R","R",mono]["out","in",filter]["out","lfe",waveout];

Выход с плеера на моно-микшер, затем на фильтр, затем на вход для сабвуфера.

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

Так вывод никакого отоношения к vst не имеет

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

[mellowman]

Перегрузил эти операции ради краткости записи, чтобы можно было в одну строчку писать. Так же и роутинг для последовательного соединения можно в одну строчку записать:

--player["L","L",mono];
--player["R","R",mono]["out","in",filter]["out","lfe",waveout];

Выход с плеера на моно-микшер, затем на фильтр, затем на вход для сабвуфера.

Так ещё раз, роутинг где хранится? В sine / waveout, или статическом Module (.Wire)?

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

Вот при решении задачи разработчик и набирает то что ему нужно. А библиотека делает только своё, но на все случаи жизни.

[E.Sokol]

Так ещё раз, роутинг где хранится?

В явном виде нигде не хранится. Input[] и Output[] в модулях это не массивы значений, как в VST, а массивы указателей на значения (а точнее, на объекты, хранящих эти значения). Метод Wire просто подменивает эти указатели. Указатели с Input одного модуля ссылаются на Output другого.

[mellowman]

В явном виде нигде не хранится. Input[] и Output[] в модулях это не массивы значений, как в VST, а массивы указателей на значения (а точнее, на объекты, хранящих эти значения). Метод Wire просто подменивает эти указатели.

А, вон оно как. Если аккуратно wire*ить, то наверно нормально, хотя я бы так не делал. Если 3 выхода, то 3 раза start(), и они например от одного входа, то у него будет 3 раза process()? Или это хост (ой, нет же хоста, box конечно же), отсортирует?

[E.Sokol]

Работает так.

Чтобы не вызывать Process() для каждого модуля по отдельности

player.Process();
mono.Process();
filter.Process();

его можно вызвать у контейнера, в котором они лежат:

box.Process();

И тот сам в цикле его выполнит:

public override void Process()
{
foreach (var m in Modules)
           m.Process();
}

Чтобы модули вычислялись в правильном порядке, предварительно используется топологическая сортировка Sort() (один раз).

А метод Start() вызывается у WaveOut, который запускает отдельный поток и вызывает box.Process() столько раз, сколько нужно для заполнения буфера звуковой карты. Когда буфер заполнился, он отправляется на воспроизведение, и поток ждёт его освобождения.

[mellowman]

А метод Start() вызывается у WaveOut, который запускает отдельный поток и вызывает box.Process() столько раз, сколько нужно для заполнения буфера звуковой карты. Когда буфер заполнился, он отправляется на воспроизведение, и поток ждёт его освобождения.

Т.е. если выходных звуковых карт 3, то каждая получит только 1/3 входных семплов, т.к. каждый выход...

...запускает отдельный поток и вызывает box.Process() столько раз, сколько нужно для заполнения буфера звуковой карты.

[E.Sokol]

Т.е. если выходных звуковых карт 3, то каждая получит только 1/3 входных семплов, т.к. каждый выход...

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

---------- Сообщение добавлено 21:24 ---------- Предыдущее сообщение было 19:09 ----------

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

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

Если аккуратно wire*ить, то наверно нормально, хотя я бы так не делал.

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

[mellowman]

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

Не проще просто доверить это всё хосту?

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

Так хорошо, тоже почему-то сразу не подумал что так можно Заодно и всякие underrun*ы легко искать

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

То что оно не выпало segfault*ом, не значит что правильно работает Или удобно в использовании/поддержке/развитии

[E.Sokol]

Не проще просто доверить это всё хосту?

От задач синхронизации это всё равно не спасёт. И как много ты знаешь хостов с поддержкой нескольких устройств ввода/вывода одновременно?

---------- Сообщение добавлено 09:31 ---------- Предыдущее сообщение было 09:16 ----------

То что оно не выпало segfault*ом, не значит что правильно работает

segfault в управляемом коде не грозит. Грозит утечка памяти, если не сбрасывать связи на ссылаемый модуль при его удалении, причём никогда. Нужно очень сильно постараться, чтобы провернуть такой сценарий.

---------- Сообщение добавлено 09:37 ---------- Предыдущее сообщение было 09:31 ----------

Заодно и всякие underrun*ы легко искать

Полезное замечание Добавлю событие на это в интерфейс.

[mellowman]

От задач синхронизации это всё равно не спасёт. И как много ты знаешь хостов с поддержкой нескольких устройств ввода/вывода одновременно?

В Element есть (раз его попробовал, был сыроват, сейчас выглядит лучше). Я делал в линуксе, там вообще с этим проблем не было, но для хоста все виделись как 1 с несколькими каналами, так что не совсем корректный пример получился

[E.Sokol]

В линуксе, я слышал, подсистема вывода звука немного проще.

[domician]

В таком случае не могли бы вы поделиться своими соображениями (остальные тоже могут) по поводу минимальной необходимой функциональности, при которой имеет смысл выкладывать это творение на всеобщее обозрение? Потому что если ориентироваться на мои собственные хотелки, то оно не закончено будет никогда

Все верно, если не отдернуть себя вовремя, то или останется в виде мечты или вечные переделки.
Из того, что написали "хочу все" , но особенно порадовали бы поддержка VST плагинов и произвольный FIR-кроссовер.
Спектроанализатор - не плохо, но можно сторонний. В VST плагине

[E.Sokol]

порадовали бы поддержка VST плагинов. Спектроанализатор - не плохо, но можно сторонний. В VST плагине

Есть что-то интересное на примете из VST-плагинов? Отлаживать на чём-то надо же всё равно.

[Ломатель]

E.Sokol, Евгений, мне такая разработка точно интересна.

В домашней аудиосистеме хочу в цифре сделать ФВЧ на 30 Гц + режектор комнатных мод, и чтобы это работало со стриминговыми приложениями типа Tidal / Qobuz. С помощью указанной утилиты потенциально такое реализуемо.

Немного оффтоп: Евгений и все кто читает. Вопрос. Какие есть способы реализовать указанную задачу с сохранением качества звука? Equalizer APO знаю, но не уверен за качество его обработки. А еще какие есть варианты? Посоветуйте плиз. В обход микшера, без передескретизации, с поддержкой WASAPI Exclusive / Asio ?