Code Monkey home page Code Monkey logo

audify's People

Contributors

almoghamdani avatar daviddudson avatar marcelblum avatar shinysaana avatar treffynnon avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

audify's Issues

Resampling needed to support 44.1khz sample rate

As I understand it, there's a critical issue with this library: Opus only supports a small set of sample rates, like 48khz.

If a user has a device that's different (like 44.1khz), then what you need is the following: RtAudio -> resample -> Opus encode.

I figure most people will find this to be a problem with this otherwise great library. But who knows!

rtAudio.openStream device id missing.

Hi,
I've recently come across an issue with the rtAudio object. Even though I'm passing a device ID to the object, it still gives me an error.

let device= 0;
rtAudio.openStream(
            {
                deviceId: device,
                nChannels: 1
            },
            RtAudioFormat.RTAUDIO_SINT16,
            48000,
            1920,
            "Output",
            mixer => rtAudio.write(mixer)
        );

Error: The 'device id' stream parameter is missing or invalid!
I've also tried with rtAudio.getDefaultOutputDevice(), and I still get the same issue. Any ideas?

Unable to set specific ASIO device for capture

When using the windows-asio API, it seems to ignore what deviceId I set when constructing the audio stream. It always picks a device that I don't have plugged in:

Error: RtApiAsio::probeDeviceOpen: error (Hardware input or output is not present or available.) initializing driver (ASIO 2.0 - ESI U24XL).

How can I solve this?

macOS older version support: latest Darwin builds seem to only work on macOS 12+

Was doing some testing on older Macs and noticed latest Audify (1.8.x) does not work on several macOS versions on which previous generation (1.7.x) did work. require("audify") fails immediately. Error messages suggest the RtAudio binary is the culprit because it "was built for Mac OS X 12.0" but I'm not sure if the problem is hardcoded in the RtAudio source or if it's in the way Audify itself is built.

On macOS 10.15 Catalina when trying to initialize Audify I get:

Uncaught Error: dlopen(audify.node, 1): Symbol not found: __ZNKSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEE3strEv
    Referenced from: librtaudio.6.dylib (which was built for Mac OS X 12.0)
    Expected in: /usr/lib/libc++.1.dylib

On even older 10.13 High Sierra a little different and less specific:

cannot load 'audify.node' (load command 0x80000034 is unknown)

The next highest macOS I have available to test is 13 Ventura on which Audify 1.8.1 works fine.

Cant build 1.6.3 on linux

First of all, thanks for the package. It is great and made my life much easier.
Now to the point: on windows and my personal linux machine, everything works like a charm, but on my prod server with astra linux, I have problems building. The error pops up on 97% of build process and says like "In file included from /.../.../.../node_modules/audify/src/audify.cpp:4:0:
/.../.../.../node_modules/audify/src/opus_encoder.h:21:41: error: ‘constructor’ declared as an ‘inline’ field
inline static Napi::FunctionReference constructor;"
I have latest cmake and gcc installed. I believe, that it may be somehow connected to glibc version, which is 2.24 on our machine, and the warning at the start of the build says " version `GLIBC_2.29' not found". If thats correct, what am I supposed to do? If not, what can i do to fix it? Using node 14.18.0 and electtron 15.1.2 if that is relevant in any way. Thanks in advance.

`getChannelCount()`, `getFormat()`

In addition to the existing getSampleRate(), it would be useful to getChannelCount() as well as getFormat() so we could know these parameters for the audio being recorded. That way, if we end up using the device default channel count and format, we can know what we're getting in the samples returned.

openStream crash my microphone on every other application on the machine

Hi, I'm trying to use the openStream api like the following

const st = rtAudio.openStream(
  undefined,
  {
    deviceId: inputName || rtAudio.getDefaultInputDevice(), // Input device id (Get all devices using `getDevices`)
    nChannels: 1, // Number of channels
    firstChannel: 0, // First channel index on device (default = 0).
  },
  RtAudioFormat.RTAUDIO_SINT16, // PCM Format - Signed 16-bit integer
  48000, // Sampling rate is 48kHz
  1920, // Frame size is 1920 (40ms)
  "MyStream", // The name of the stream (used for JACK Api)
  (pcm) => {
    //logic to detect if the person is with voice active
  },
  () => {}
);
rtAudio.start();

It works as expected, and I can get the data that I need from the inputCallback without issues.

The thing is, when i execute rtAudio.start() every other application stop detecting the audio input from the computer until until I restart that application.

It's any workaround for this? Am I doing something wrong?

Support Arm

Trying to use your Lib on a Raspberry Pi 4 fails. Your bins are all x64. Could you offer advice to compile for ARM?.

RtAudio input stops after ~7 seconds, when output is not opened

I'm having trouble with the basic audio input example. The audio input callback stops being called after about 7 seconds. Some notes:

  • This occurs with both WASAPI and DirectShow audio APIs.
  • It doesn't matter which audio device I use.
  • The exact time duration before failure varies from run to run, slightly, as does the number of times the input callback is called.
  • DirectShow devices fail 1-2 seconds sooner than WASAPI devices, even if the same physical device is used.
  • Changing the frame size option will change the number of times the callback is called, but will not change the time duration or number of bytes received. That is, if I double the frame size, the callback is called about half the number of times, but the total time duration and byte count is about the same.
  • Changing the sample format option of course changes the number of bytes I receive, but the number of times the callback is called is not changed, and neither is the total time duration.
  • I'm not using an audio output. Input only.
  • The error callback is never called.
  • None of the RtAudioStreamFlags have any impact on this problem.
  • Windows 10 x64. Node.js 18.3.0. Audify 1.7.1.

Any thoughts as to the cause of this and how it can be solved?

crashes in Electron 14+ renderer when reloading

I think this must be related to Electron's deprecation of app.allowRendererProcessReuse and related changes introduced with Electron 14. I'm using Audify in Electron in the renderer process. But in Electron versions later than 13, if I reload the renderer or navigate away to a different page after having already created an instance of Audify, the renderer crashes with error -36861 if I then try to instantiate Audify again after navigating back to the original page or reloading it. The following works in Electron <=13 with app.allowRendererProcessReuse=false but crashes in 14+:

const audify = require("audify");
location.reload();
//...
const audify = require("audify"); //crash!

My guess is that some kind of proper cleanup/unload function in Audify could resolve this. Any ideas as to how to approach this or what specifically could lead to this crash that would need to be cleaned up? In the renderer I've tried trickery like this but it doesn't prevent the crash:

const audify = require("audify"); 
audify = null;
gc();
webContents.reloadIgnoringCache();
//...
const audify = require("audify"); //still crashes here

Also, interestingly, this happens:

BrowserWindow.loadFile("somepage.html");
//...
const audify = require("audify");
BrowserWindow.loadFile("differentpage.html");
//...
const audify = require("audify"); //no crash!
BrowserWindow.loadFile("somepage.html");
//...
const audify = require("audify"); //crash when tried again back at the first page

Audify can be instantiated multiple times over different renderer page loads without crashing, but if I try to instantiate it more than once during different "visits" to the same page in the same renderer session, it will crash, suggesting Electron is keeping a different v8 context for each page, and caching or faulty garbage cleanup is to blame for the crash.

Update: Strike the above, I'm also sometimes getting crashes when doing the above on different pages, albeit less consistently than after doing a simple location.reload().

Error compiling 1.5.3 on Raspbian

I get an error when compiling Audify 1.5.3 on Raspbian 10/Raspberry Pi 4 with ALSA support. I used the following commands to install the necessary dependencies on a fresh install of Raspbian:

sudo apt update
sudo apt upgrade
sudo apt install git nodejs npm
sudo apt install cmake make gcc libasound2-dev

When running npm install in a repository using Audify 1.5.3 I get the following error during compilation:

[ 90%] Building C object opus/CMakeFiles/opus.dir/celt/arm/celt_neon_intr.c.o
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c: In function ‘xcorr_kernel_neon_float’:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:6740:1: error: inlining failed in call to always_inline ‘vdupq_n_f32’: target specific option mismatch
 vdupq_n_f32 (float32_t __a)
 ^~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:118:11: note: called from here
    SUMM = vdupq_n_f32(0);
           ^~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:10392:1: error: inlining failed in call to always_inline ‘vld1q_f32’: target specific option mismatch
 vld1q_f32 (const float32_t * __a)
 ^~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:117:12: note: called from here
    YY[0] = vld1q_f32(yi);
            ^~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7997:1: error: inlining failed in call to always_inline ‘vmlaq_lane_f32’: target specific option mismatch
 vmlaq_lane_f32 (float32x4_t __a, float32x4_t __b, float32x2_t __c, const int __d)
 ^~~~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:151:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YEXT[2], vget_high_f32(XX[1]), 1);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7267:1: error: inlining failed in call to always_inline ‘vget_high_f32’: target specific option mismatch
 vget_high_f32 (float32x4_t __a)
 ^~~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:151:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YEXT[2], vget_high_f32(XX[1]), 1);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:8845:1: error: inlining failed in call to always_inline ‘vextq_f32’: target specific option mismatch
 vextq_f32 (float32x4_t __a, float32x4_t __b, const int __c)
 ^~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:150:17: note: called from here
       YEXT[2] = vextq_f32(YY[1], YY[2], 3);
                 ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7997:1: error: inlining failed in call to always_inline ‘vmlaq_lane_f32’: target specific option mismatch
 vmlaq_lane_f32 (float32x4_t __a, float32x4_t __b, float32x2_t __c, const int __d)
 ^~~~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:149:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YEXT[1], vget_high_f32(XX[1]), 0);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7267:1: error: inlining failed in call to always_inline ‘vget_high_f32’: target specific option mismatch
 vget_high_f32 (float32x4_t __a)
 ^~~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:149:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YEXT[1], vget_high_f32(XX[1]), 0);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:8845:1: error: inlining failed in call to always_inline ‘vextq_f32’: target specific option mismatch
 vextq_f32 (float32x4_t __a, float32x4_t __b, const int __c)
 ^~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:148:17: note: called from here
       YEXT[1] = vextq_f32(YY[1], YY[2], 2);
                 ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7997:1: error: inlining failed in call to always_inline ‘vmlaq_lane_f32’: target specific option mismatch
 vmlaq_lane_f32 (float32x4_t __a, float32x4_t __b, float32x2_t __c, const int __d)
 ^~~~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:147:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YEXT[0], vget_low_f32(XX[1]), 1);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7346:1: error: inlining failed in call to always_inline ‘vget_low_f32’: target specific option mismatch
 vget_low_f32 (float32x4_t __a)
 ^~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:147:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YEXT[0], vget_low_f32(XX[1]), 1);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:8845:1: error: inlining failed in call to always_inline ‘vextq_f32’: target specific option mismatch
 vextq_f32 (float32x4_t __a, float32x4_t __b, const int __c)
 ^~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:146:17: note: called from here
       YEXT[0] = vextq_f32(YY[1], YY[2], 1);
                 ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7997:1: error: inlining failed in call to always_inline ‘vmlaq_lane_f32’: target specific option mismatch
 vmlaq_lane_f32 (float32x4_t __a, float32x4_t __b, float32x2_t __c, const int __d)
 ^~~~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:145:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YY[1], vget_low_f32(XX[1]), 0);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7346:1: error: inlining failed in call to always_inline ‘vget_low_f32’: target specific option mismatch
 vget_low_f32 (float32x4_t __a)
 ^~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:145:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YY[1], vget_low_f32(XX[1]), 0);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7997:1: error: inlining failed in call to always_inline ‘vmlaq_lane_f32’: target specific option mismatch
 vmlaq_lane_f32 (float32x4_t __a, float32x4_t __b, float32x2_t __c, const int __d)
 ^~~~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:143:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YEXT[2], vget_high_f32(XX[0]), 1);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7267:1: error: inlining failed in call to always_inline ‘vget_high_f32’: target specific option mismatch
 vget_high_f32 (float32x4_t __a)
 ^~~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:143:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YEXT[2], vget_high_f32(XX[0]), 1);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:8845:1: error: inlining failed in call to always_inline ‘vextq_f32’: target specific option mismatch
 vextq_f32 (float32x4_t __a, float32x4_t __b, const int __c)
 ^~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:142:17: note: called from here
       YEXT[2] = vextq_f32(YY[0], YY[1], 3);
                 ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7997:1: error: inlining failed in call to always_inline ‘vmlaq_lane_f32’: target specific option mismatch
 vmlaq_lane_f32 (float32x4_t __a, float32x4_t __b, float32x2_t __c, const int __d)
 ^~~~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:141:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YEXT[1], vget_high_f32(XX[0]), 0);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7267:1: error: inlining failed in call to always_inline ‘vget_high_f32’: target specific option mismatch
 vget_high_f32 (float32x4_t __a)
 ^~~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:141:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YEXT[1], vget_high_f32(XX[0]), 0);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:8845:1: error: inlining failed in call to always_inline ‘vextq_f32’: target specific option mismatch
 vextq_f32 (float32x4_t __a, float32x4_t __b, const int __c)
 ^~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:140:17: note: called from here
       YEXT[1] = vextq_f32(YY[0], YY[1], 2);
                 ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7997:1: error: inlining failed in call to always_inline ‘vmlaq_lane_f32’: target specific option mismatch
 vmlaq_lane_f32 (float32x4_t __a, float32x4_t __b, float32x2_t __c, const int __d)
 ^~~~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:139:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YEXT[0], vget_low_f32(XX[0]), 1);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7346:1: error: inlining failed in call to always_inline ‘vget_low_f32’: target specific option mismatch
 vget_low_f32 (float32x4_t __a)
 ^~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:139:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YEXT[0], vget_low_f32(XX[0]), 1);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:8845:1: error: inlining failed in call to always_inline ‘vextq_f32’: target specific option mismatch
 vextq_f32 (float32x4_t __a, float32x4_t __b, const int __c)
 ^~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:138:17: note: called from here
       YEXT[0] = vextq_f32(YY[0], YY[1], 1);
                 ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7997:1: error: inlining failed in call to always_inline ‘vmlaq_lane_f32’: target specific option mismatch
 vmlaq_lane_f32 (float32x4_t __a, float32x4_t __b, float32x2_t __c, const int __d)
 ^~~~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:137:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YY[0], vget_low_f32(XX[0]), 0);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7346:1: error: inlining failed in call to always_inline ‘vget_low_f32’: target specific option mismatch
 vget_low_f32 (float32x4_t __a)
 ^~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:137:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YY[0], vget_low_f32(XX[0]), 0);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:10392:1: error: inlining failed in call to always_inline ‘vld1q_f32’: target specific option mismatch
 vld1q_f32 (const float32_t * __a)
 ^~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:134:15: note: called from here
       XX[1] = vld1q_f32(xi);
               ^~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:10392:1: error: inlining failed in call to always_inline ‘vld1q_f32’: target specific option mismatch
 vld1q_f32 (const float32_t * __a)
 ^~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:132:15: note: called from here
       XX[0] = vld1q_f32(xi);
               ^~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:10392:1: error: inlining failed in call to always_inline ‘vld1q_f32’: target specific option mismatch
 vld1q_f32 (const float32_t * __a)
 ^~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:130:15: note: called from here
       YY[2] = vld1q_f32(yi);
               ^~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:10392:1: error: inlining failed in call to always_inline ‘vld1q_f32’: target specific option mismatch
 vld1q_f32 (const float32_t * __a)
 ^~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:128:15: note: called from here
       YY[1] = vld1q_f32(yi);
               ^~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7997:1: error: inlining failed in call to always_inline ‘vmlaq_lane_f32’: target specific option mismatch
 vmlaq_lane_f32 (float32x4_t __a, float32x4_t __b, float32x2_t __c, const int __d)
 ^~~~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:176:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YEXT[2], vget_high_f32(XX[0]), 1);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7267:1: error: inlining failed in call to always_inline ‘vget_high_f32’: target specific option mismatch
 vget_high_f32 (float32x4_t __a)
 ^~~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:176:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YEXT[2], vget_high_f32(XX[0]), 1);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:8845:1: error: inlining failed in call to always_inline ‘vextq_f32’: target specific option mismatch
 vextq_f32 (float32x4_t __a, float32x4_t __b, const int __c)
 ^~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:175:17: note: called from here
       YEXT[2] = vextq_f32(YY[0], YY[1], 3);
                 ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7997:1: error: inlining failed in call to always_inline ‘vmlaq_lane_f32’: target specific option mismatch
 vmlaq_lane_f32 (float32x4_t __a, float32x4_t __b, float32x2_t __c, const int __d)
 ^~~~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:174:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YEXT[1], vget_high_f32(XX[0]), 0);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7267:1: error: inlining failed in call to always_inline ‘vget_high_f32’: target specific option mismatch
 vget_high_f32 (float32x4_t __a)
 ^~~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:174:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YEXT[1], vget_high_f32(XX[0]), 0);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:8845:1: error: inlining failed in call to always_inline ‘vextq_f32’: target specific option mismatch
 vextq_f32 (float32x4_t __a, float32x4_t __b, const int __c)
 ^~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:173:17: note: called from here
       YEXT[1] = vextq_f32(YY[0], YY[1], 2);
                 ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7997:1: error: inlining failed in call to always_inline ‘vmlaq_lane_f32’: target specific option mismatch
 vmlaq_lane_f32 (float32x4_t __a, float32x4_t __b, float32x2_t __c, const int __d)
 ^~~~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:172:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YEXT[0], vget_low_f32(XX[0]), 1);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7346:1: error: inlining failed in call to always_inline ‘vget_low_f32’: target specific option mismatch
 vget_low_f32 (float32x4_t __a)
 ^~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:172:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YEXT[0], vget_low_f32(XX[0]), 1);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:8845:1: error: inlining failed in call to always_inline ‘vextq_f32’: target specific option mismatch
 vextq_f32 (float32x4_t __a, float32x4_t __b, const int __c)
 ^~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:171:17: note: called from here
       YEXT[0] = vextq_f32(YY[0], YY[1], 1);
                 ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7997:1: error: inlining failed in call to always_inline ‘vmlaq_lane_f32’: target specific option mismatch
 vmlaq_lane_f32 (float32x4_t __a, float32x4_t __b, float32x2_t __c, const int __d)
 ^~~~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:170:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YY[0], vget_low_f32(XX[0]), 0);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7346:1: error: inlining failed in call to always_inline ‘vget_low_f32’: target specific option mismatch
 vget_low_f32 (float32x4_t __a)
 ^~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:170:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YY[0], vget_low_f32(XX[0]), 0);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:10392:1: error: inlining failed in call to always_inline ‘vld1q_f32’: target specific option mismatch
 vld1q_f32 (const float32_t * __a)
 ^~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:167:15: note: called from here
       XX[0] = vld1q_f32(xi);
               ^~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:10392:1: error: inlining failed in call to always_inline ‘vld1q_f32’: target specific option mismatch
 vld1q_f32 (const float32_t * __a)
 ^~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:165:15: note: called from here
       YY[1] = vld1q_f32(yi);
               ^~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:10392:1: error: inlining failed in call to always_inline ‘vld1q_f32’: target specific option mismatch
 vld1q_f32 (const float32_t * __a)
 ^~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:185:14: note: called from here
       YY[0]= vld1q_f32(++yi);
              ^~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7997:1: error: inlining failed in call to always_inline ‘vmlaq_lane_f32’: target specific option mismatch
 vmlaq_lane_f32 (float32x4_t __a, float32x4_t __b, float32x2_t __c, const int __d)
 ^~~~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:184:14: note: called from here
       SUMM = vmlaq_lane_f32(SUMM, YY[0], XX_2, 0);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:10664:1: error: inlining failed in call to always_inline ‘vld1_dup_f32’: target specific option mismatch
 vld1_dup_f32 (const float32_t * __a)
 ^~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:183:14: note: called from here
       XX_2 = vld1_dup_f32(xi++);
              ^~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:10970:1: error: inlining failed in call to always_inline ‘vst1q_f32’: target specific option mismatch
 vst1q_f32 (float32_t * __a, float32x4_t __b)
 ^~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:191:4: note: called from here
    vst1q_f32(sum, SUMM);
    ^~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:7997:1: error: inlining failed in call to always_inline ‘vmlaq_lane_f32’: target specific option mismatch
 vmlaq_lane_f32 (float32x4_t __a, float32x4_t __b, float32x2_t __c, const int __d)
 ^~~~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:189:11: note: called from here
    SUMM = vmlaq_lane_f32(SUMM, YY[0], XX_2, 0);
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:37:
/usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:10664:1: error: inlining failed in call to always_inline ‘vld1_dup_f32’: target specific option mismatch
 vld1_dup_f32 (const float32_t * __a)
 ^~~~~~~~~~~~
/home/pi/aes67-monitor/node_modules/audify/vendor/opus/celt/arm/celt_neon_intr.c:188:11: note: called from here
    XX_2 = vld1_dup_f32(xi);
           ^~~~~~~~~~~~~~~~
make[2]: *** [opus/CMakeFiles/opus.dir/build.make:1857: opus/CMakeFiles/opus.dir/celt/arm/celt_neon_intr.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:146: opus/CMakeFiles/opus.dir/all] Error 2
make: *** [Makefile:152: all] Error 2

Using the same steps with version 1.5.2 works flawlessly.

I also tried using clang instead of gcc. I then get a different error:

[ 98%] Building CXX object CMakeFiles/audify.dir/src/rt_audio.cpp.o
In file included from /home/pi/aes67-monitor/node_modules/audify/src/rt_audio.cpp:5:
/home/pi/aes67-monitor/node_modules/audify/src/rt_audio_converter.h:22:9: error: use of overloaded operator '[]' is ambiguous
      (with operand types 'Napi::Array' and 'int')
                        array[i] = Napi::Value::From(env, items[i]);
                        ~~~~~^~
/home/pi/aes67-monitor/node_modules/node-addon-api/napi-inl.h:1145:49: note: candidate function
inline Object::PropertyLValue<uint32_t> Object::operator [](uint32_t index) {
                                                ^
/home/pi/aes67-monitor/node_modules/node-addon-api/napi-inl.h:1157:22: note: candidate function
inline Value Object::operator [](uint32_t index) const {
                     ^
/home/pi/aes67-monitor/node_modules/audify/src/rt_audio_converter.h:22:9: note: built-in candidate operator[](struct napi_value__ *, int)
                        array[i] = Napi::Value::From(env, items[i]);
                             ^
/home/pi/aes67-monitor/node_modules/audify/src/rt_audio_converter.h:22:9: note: built-in candidate operator[](const struct napi_value__ *, int)
/home/pi/aes67-monitor/node_modules/audify/src/rt_audio_converter.h:22:9: note: built-in candidate operator[](volatile struct napi_value__ *, int)
/home/pi/aes67-monitor/node_modules/audify/src/rt_audio_converter.h:22:9: note: built-in candidate operator[](const volatile struct napi_value__ *, int)
1 error generated.
make[2]: *** [CMakeFiles/audify.dir/build.make:102: CMakeFiles/audify.dir/src/rt_audio.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:119: CMakeFiles/audify.dir/all] Error 2
make: *** [Makefile:152: all] Error 2

Windows ASIO output and frameSize conflicts

ASIO is a strange bird and I've been running into an issue where many devices have control panels in which the user can specify buffer size settings. These settings seem to override any attempt to specify frameSize in RtAudio's openStream(). The problem is if a frameSize is specified in openStream() that is not exactly equal to whatever the user selected in their control panel, then calls to write() fail silently. The frameOutputCallback is never called following the write(), no error is fired, and isStreamOpen and isStreamRunning both return true. So the RtAudio instance is in this weird state where buffers keep piling up in the queue with every call to write() but are never played. There's no way that I can see to detect the user-set buffer size and pick the right magic number for frameSize when instantiating an RtAudio stream. Is there a way to have getDevices() return the device's current preset buffer size? Or perhaps some flag that forces overriding the control panel setting?

Here are 2 examples of the sort of ASIO device control panels I'm referring to:

Untitled

You can see that in the MOTU device panel both sample rate and buffer size are configurable, but interestingly the sampleRate specified in openStream() does override the panel setting (I can see the change reflected in the panel as soon as I open the RtAudio stream).

I guess an ugly workaround would be to brute force it by continuously opening streams and checking if the frameOutputCallback was called, and if not, open a new stream and try again with a different power of 2 value until arriving at the magic number that works, but it would be nice to have a more elegant solution.

Audio interface disconnected detection and bugs

I am having an issue with Audify on Windows 10. When an audio device is disconnected (for example disabling it via sound device settings), various things might happen. on WASAPI, the entire program just crashes immediately, on DirectSound, the audio stops working and will never start working again, and ASIO just flat out doesn't work in the first place. After talking with friends who have used other programs that use rtAudio, this is also an issue in those programs as well, however they claimed the errorCallback on openStream could be used to handle these kind of situations? Though it looks like this is a known issue already. Audify doesn't seem to support the errorCallback method or any way of detecting dropped audio/catching errors that might crash the entire application. This is very bad, because in my application, users may lose hours worth of progress on their project simply because the program crashes seemingly out of nowhere. For reference, this is how I use rtAudio at the moment.

Any input on potential fixes/workarounds/other solutions? Preferably I'd be able to detect when the device is disconnected so I can re-create it with rtAudio, but being able to not crash at the very least would really be preferred.

Builds Not Working (1.6.1)

Okay so the build crashed on master, and by looking the travis builds, my first guess would because of artifact caching between builds, and that we indeed need the latest version and not the LTS one

Originally posted by @ShinySaana in #15 (comment)

Get one application audio?

Is there anyway to get a single application audio? For example only capture a game but nothing else. It can be done using wasapi but I don't know how.

ASIO on Windows Electron don't working

I have been tried the example loopback audio from microphone that is in the documentation, and set the audio api as ASIO from Windows. But after set it, if I execute the get api method, shows me that still being WASAPI (the standard Windows API).

Is not finished this ASIO API? Or maybe I'm doing something wrong?

If it's supossed to be finished I can send you more information about the code and my environment.

using audify with the web audio api via electron

Audify includes AFAICT the only currently maintained and fully working Node implementation of RtAudio, giving it quite a bit of utility for routing audio - awesome! I am looking for a way to pipe audio rendered in realtime by the Web Audio api into an instance of Audify's RtAudio in an Electron app. My goal is to be able to output audio generated by the browser (e.g. Electron's renderer process) to an ASIO-only device on Windows. Does anyone have any idea on approaches for this? I was thinking perhaps through a WebRTC MediaStream (AudioContext.createMediaStreamDestination()) but I am not sure if this is the optimal route. Any ideas/pointers/nudges in the right direction would be appreciated!

Can't use devices that have a different channel count for input vs output.

Whenever I try to use Audify for opening a channel on a device (like my macbook pro) where the channel count for the microphone doesn't match the channel count for the output, the library throws an exception:

Error: RtApiCore::probeDeviceOpen: the device (1) does not support the requested channel count.

Am I correct to assume that this is an RtAudio bug?

Get microphone input stream?

Is there an easy way to get the continuous mic input stream? I don't think the callback function can do this efficiently. If there isn't a way then could you please consider adding it as a feature? Thanks.

For example: mic and node-record-lpcm16 have this feature.

Linux: Capturing audio on loopback device

I've been trying to capture audio on a loopback device in Linux. I've enabled a loopback device through:

modprobe snd-aloop

This adds a new virtual card to my environment:

arecord -l
**** List of CAPTURE Hardware Devices ****
card 2: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 2: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7

To test if the loopback device is working a ran the following examples:

1st terminal:

arecord -D hw:2,1,0 -r 44100 -c 2 -f S16_LE record.wav

2nd terminal (sample wav):

aplay -D hw:2,0,0 -f S16_LE -c2 play.wav

Afterwards I'm able to successfully play the recorded file back:

aplay record.wav

Next it was time to try capturing the input through Audify. The below code snippet tries to capture data from Loopback device.

const { RtAudio, RtAudioFormat, RtAudioApi } = require('audify');

const rtAudio = new RtAudio(RtAudioApi.LINUX_ALSA);
const audioDevices = rtAudio.getDevices();
console.log('Device #, Name, # of Channels');
for(let i = 0; i < audioDevices.length; i++){
  let device = audioDevices[i];
  if(device.inputChannels > 0){
  	console.log(i, device.name, device.inputChannels);
  }
}

rtAudio.openStream(null, { deviceId: 2, nChannels: 2, firstChannel: 0 }, RtAudioFormat.RTAUDIO_FLOAT32, 48000, 48, 'testing', (outputBuffer) => {
  console.log(outputBuffer);
});
rtAudio.start();

Outputs:

Device #, Name, # of Channels
0 Default ALSA Device 32
1 PulseAudio Sound Server 32
2 Loopback (Loopback PCM) 32
<Buffer 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... 334 more bytes>
<Buffer 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... 334 more bytes>
<Buffer 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... 334 more bytes>
<Buffer 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... 334 more bytes>
<Buffer 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... 334 more bytes>
<Buffer 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... 334 more bytes>
etc..

The empty buffers indicate no audio data is captured.

@almoghamdani Have you by any chance tested loopback devices? Might be I'm doing something wrong tho.

RtAudio bugs in latest release v1.8.0

Have only tested the latest release on Windows so far and I noticed a couple critical (probably interrelated) bugs introduced with this release:

  1. The Windows driver type API enums are mismatched between WASAPI and ASIO. Their numbers are reversed in this new version, where new RtAudio(6) creates an ASIO instance and new RtAudio(7) creates a WASAPI instance. Previously it was the other way around. Meanwhile RtAudioApi still shows the old values for WINDOWS_ASIO and WINDOWS_WASAPI. So for example new RtAudio(audify.RtAudioApi.WINDOWS_ASIO) returns a WASAPI instance.
  2. openStream seems to always fail with "RtApi::openStream: output device ID is invalid" no matter which API or device ID I try.

FWIW my local Windows build from when I worked on #34 did not have these issues, though it was from before some more recent commits so used the older rtaudio source.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.