После потоветки крови и слез мне наконец удалось создать узел Node C++ и MediaStream
один из стандартных средств MediaStream
в веб-платформу в один из его методов C++. Для совместимости в разных версиях V8 и Node.js я использую Native Abstractions для Node.js(nan):
addon.cc
NAN_METHOD(SetStream)
{
Nan::HandleScope scope;
v8::Local<v8::Object> mediaStream = info[0]->ToObject();
}
addon.js
setStream(new MediaStream());
Для того, что это стоит, это работает правильно (т. MediaStream
процесс визуализации на вид), и я могу проверить наличие объекта MediaStream
, например, вернув его имя конструктора из метода C++:
addon.cc
info.GetReturnValue().Set(mediaStream->GetConstructorName());
При вызове из JavaScript через setStream
это вернет строку MediaStream
, поэтому объект определенно существует. Я также могу вернуть объект mediaStream
сам, и все будет работать правильно, так что это действительно тот объект, который мне нужен.
Итак, как бы я мог читать аудиоданные (т.е. образцы аудио) из этого объекта MediaStream
в C++? В качестве побочного элемента фактические данные (и обработка) будут выполняться в отдельной std::thread
.
Обновление Bounty
Я понимаю, что это было бы проще или возможнее, если бы я сам собирал Electron и/или Chromium, но я бы предпочел не участвовать в этом афере обслуживания.
Мне было интересно, можно ли это сделать без этого, и, насколько мне известно, я убежден, что мне нужно 2 вещи, чтобы сделать это:
- Соответствующие файлы заголовки, для которых я считаю, моргать общественность должны быть адекватными
- Файл библиотеки chromium/blink (?) Для разрешения внешних символов, аналогично файлу node.dylib
Кроме того, как я уже сказал, я считаю, что сам мог бы скомпилировать хром/миг, и тогда у меня будет этот файл lib, но это будет адский ад с Electron. Имея это в виду, я считаю, что этот вопрос в конечном итоге сводится к вопросу о C++. Есть ли другой подход к тому, что я ищу?
редактировать
ScriptProcessorNode не является вариантом в моем случае, так как его производительность делает его практически непригодным для производства. Это потребовало бы обработки звуковых образцов на ui/main thread, что абсолютно безумно.