New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Audio interface revamp #82

Open
AndrewBelt opened this Issue Sep 14, 2017 · 51 comments

Comments

Projects
None yet
@AndrewBelt
Copy link
Member

AndrewBelt commented Sep 14, 2017

The Audio Interface should be replaced with two audio interfaces. Suggestions?

- 2-in/2-out master monitor module
	- VU meter
	- master volume
	- AC/DC couple switch
	- mute button
- N-in/N-out
	- automatic resizing based on number of outputs
	- LED green >-40dB, yellow >-6dB, red clipping
@AndrewBelt

This comment has been minimized.

Copy link
Member

AndrewBelt commented Sep 14, 2017

Internally I will probably switch from portaudio to libsoundio because several people are experiencing lack of audio devices, and this project is more active. (Also, grass is greener falacy.)

@synthi

This comment has been minimized.

Copy link

synthi commented Sep 14, 2017

-about the "master monitor" module, would be great having a multiple built in, and also having two inputs. A nice and clean way for anyone using VCV as a sound source or basic procesing external sounds. A built in envelope follower would be great too

-N in/out module: Please let the user to specify the number of in/outs... f.e. The RME cards have a ton of in/outs but not everybody use the digital (spdif, ADAT) in outs, and the count for those is up to 18 aditional in/out channels depending on the interface model! Using Rearoute and othe virtual asio driver its the same, maybe is no useful having all in/out (32/32 or more) exposed at the front panel.

@AndrewBelt

This comment has been minimized.

Copy link
Member

AndrewBelt commented Sep 14, 2017

Agreed, I should label the inputs Left/Mono and Right. If I have space for two inputs, I don't see why not.

I feel that an envelope follower is a job for a module, not the audio interface.

Hmm, unless the audio interfaces you're talking about have extreme amounts of ins/outs (like 3x as many as are physically on the device), it's probably simpler to leave them on the module. Yes, this makes for a huge module, but you could always hide it partially off-screen.

@synthi

This comment has been minimized.

Copy link

synthi commented Sep 14, 2017

Even some of the simplest RME interface will have expsed to the system 8 analog ins+16Adat ins+SPdif in = 26 inputs + 26 outputs. The MADIFace XT will have 196 Input + 198 Output channels....

@jackokring

This comment has been minimized.

Copy link

jackokring commented Sep 14, 2017

@AndrewBelt

This comment has been minimized.

Copy link
Member

AndrewBelt commented Sep 14, 2017

@synthi Oh geez... I'll think about that then.

@TronicLabs

This comment has been minimized.

Copy link

TronicLabs commented Sep 15, 2017

libsoundio, not have the ASIO backend

@AndrewBelt

This comment has been minimized.

Copy link
Member

AndrewBelt commented Sep 15, 2017

@tildebyte

This comment has been minimized.

Copy link

tildebyte commented Sep 18, 2017

Maybe I'm not understanding some of the comments, but please normalize at least one output pair, i.e. audio into Left/nothing into Right goes out of both channels. I can't stand trying to work with something playing in only one ear...

@AndrewBelt

This comment has been minimized.

Copy link
Member

AndrewBelt commented Sep 18, 2017

^ Already mentioned, but good idea!

@guidozzz

This comment has been minimized.

Copy link

guidozzz commented Sep 20, 2017

Yes, please! I am loving this software and in fact I was wondering how to access the ADAT output of my sound card to connect to an expert sleepers ES 3 module.

@FelipeCortez

This comment has been minimized.

Copy link

FelipeCortez commented Sep 20, 2017

@tildebyte You're probably already aware but you can use the Multiples module to duplicate a signal sending it to both left and right

@tildebyte

This comment has been minimized.

Copy link

tildebyte commented Sep 20, 2017

Indeed. I couldn't find the Mult for a while :)

@djpeterso23662

This comment has been minimized.

Copy link

djpeterso23662 commented Sep 21, 2017

Really impressed with the way RACK audio collects the various flavors of Windows audio interfaces. Wish list: a way to beep and label channels when you have a bunch. Ex USB audio that is dynamically assigned. Maybe just a mouse-over label so it does not clutter the UI?

@djpeterso23662

This comment has been minimized.

Copy link

djpeterso23662 commented Sep 21, 2017

Maybe a database of what hardware is used in the community could be created to facilitate testing and development of a compatible hardware list?

@djpeterso23662

This comment has been minimized.

Copy link

djpeterso23662 commented Sep 21, 2017

Maybe a little mouse-over message saying what RACK thinks is assigned to the socket, for the current audio module?

@AndrewBelt AndrewBelt added this to the v0.4.0 milestone Sep 25, 2017

@AndrewBelt

This comment has been minimized.

Copy link
Member

AndrewBelt commented Sep 28, 2017

Decided to stick with Portaudio. I can't handle the lack of ASIO support with libsoundio and really don't want to write one.

@AndrewBelt

This comment has been minimized.

Copy link
Member

AndrewBelt commented Oct 12, 2017

I've been evaluating RtAudio and it looks much more appealing than portaudio. Hopefully less audio interface incompatibilities once I make the change.

@bontric

This comment has been minimized.

Copy link
Contributor

bontric commented Nov 21, 2017

I'd rather just not include it at all, because what's the point? VCV Bridge will solve that problem for VST/AU hosts anyway with about 1% the code complexity.

I'm not sure whether we are talking about the same thing or I'm just lost 😉 , but I can't see how this relates to the VST/AU bridge.
Anyway.. since I can just compile/install RtAudio for myself I don't need Jack support to be distributed with Rack. Additionally any Linux user should be able to easily compile the latest RtAudio with jack support given the instructions. I can also provide a script to automate this for linux users.

Solved a lot of the audio problems with 2bc6678, 4f703e3, d1f213a, and 91d4143

This looks great!

@AndrewBelt

This comment has been minimized.

Copy link
Member

AndrewBelt commented Nov 21, 2017

Supporting Jack in dev is easy. Adding it to the versioned releases, not so much.

@bontric

This comment has been minimized.

Copy link
Contributor

bontric commented Nov 21, 2017

Ohh, now I get what you mean 🐙 Sorry..

@Cordoha

This comment has been minimized.

Copy link

Cordoha commented Nov 23, 2017

So my only option is to include libjack with the distributable for Mac/Linux. I'd first have to decide which jack to include (jack1 or jack2), and I'd have to bite the bullet and include Rack's first LGPL library, which I've been avoiding since Rack began.

It'd be awesome to include jackd2. But I'm not too sure what that would sacrifice. I have Jackd2 installed, which uses other newer applications as well. Cadence, Catia, etc.. I often find that when trying to remove jackd2, other dependencies that I use/ need often will get removed. Though, I'm not sure if they need jackd2 or if they'll also use jackd1 as a dependency as well.

With shipping a jackd version, will it also interface with externally installed applications? Or will it interface like Ardour does? You can enable jack within Ardour, but if you have another external variant running, it'll use that.

At a non-developer, myself, I'd go jackd2 if you're going to do it. But if it doesn't externally interface or interfere with anything else, I guess it wouldn't matter. I'd just hate to see it affect the way I use jack. Not that my opinion matters, but figured I'd just throw it out there.

@AndrewBelt

This comment has been minimized.

Copy link
Member

AndrewBelt commented Dec 26, 2017

Can anyone actually figure out how to compile JACK support into RtAudio so that linking to it from a computer which does not have JACK libraries installed doesn't yield a linker error?

@mrVanDalo

This comment has been minimized.

Copy link

mrVanDalo commented Dec 28, 2017

I used this tool : (but I had to patch pulseaudio, but it was simple)
https://github.com/DeaDBeeF-Player/deadbeef-plugin-builder/blob/master/tools/apbuild/relaytool

@simonvanderveldt

This comment has been minimized.

Copy link

simonvanderveldt commented Jan 12, 2018

Can anyone actually figure out how to compile JACK support into RtAudio so that linking to it from a computer which does not have JACK libraries installed doesn't yield a linker error?

Runtime linking would probably be something to discuss with the rtaudio devs, doesn't seem like it's currently supported.

@AndrewBelt

This comment has been minimized.

Copy link
Member

AndrewBelt commented Jan 12, 2018

@simonvanderveldt Yes, either that would be required, or a wrapper library, or perhaps supplying the JACK library in the Rack distribution itself?

@simonvanderveldt

This comment has been minimized.

Copy link

simonvanderveldt commented Jan 12, 2018

or a wrapper library

You think that's feasible?

or perhaps supplying the JACK library in the Rack distribution itself?

At least for Linux I don't think that's something you want to/should get into. It's already difficult enough for most distro's to properly handle JACK1 and JACK2, probably don't want to add a bundled one to the mix.

@AndrewBelt

This comment has been minimized.

Copy link
Member

AndrewBelt commented Jan 12, 2018

A wrapper was @mrVanDalo's suggestion.

Here's a survey for current Rack+JACK users: Will you no longer have a use for JACK as Rack's audio driver when the VCV Bridge is released? 👍 for no longer use JACK, 👎 for still use JACK.

@ndrspcfd

This comment has been minimized.

Copy link

ndrspcfd commented Jan 12, 2018

Please bear with these non-expert suggestions :)

Would it be possible to either a) supply an alternative jack-enabled librtaudio.so (linked against system libjack) for linux users preferring JACK (I guess this could be enabled at run-time with a fairly simple commandline option to Rack.sh) or b) write a dedicated JACK audio iO module whose plugin.so linked to system libjack?

As an experiment, I dropped a librtaudio.so built against my system libjack (as per the wiki page here) into place in the root dir of the linux Rack download from vcvrack.com, and this appeared to work fine.

@shreeswifty

This comment has been minimized.

Copy link

shreeswifty commented Jan 13, 2018

hi i followed the wiki suggestion for adding jack and it does in fact appear in the drop down when i make run but i cannot select [no device appears] Linux64 ubunutu 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 22:00:44 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

@shreeswifty

This comment has been minimized.

Copy link

shreeswifty commented Jan 13, 2018

it could be because i am using FFADO with a berenger firewire device FCA610

@simonvanderveldt

This comment has been minimized.

Copy link

simonvanderveldt commented Jan 21, 2018

hi i followed the wiki suggestion for adding jack and it does in fact appear in the drop down when i make run but i cannot select [no device appears] Linux64 ubunutu 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 22:00:44 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

It seems like Rack is coded in such a way that an output device needs to be selected. I guess this means Rack would create a client and connect that client to the chosen output? (it's not working for me, my device has 8 ports and for some reason Rack want to connect 6 of them and that fails, so I can't check).
I think it would be easier if Rack would just create a client so that the user can choose what to connect it to.

@Coirt

This comment has been minimized.

Copy link

Coirt commented Jan 24, 2018

I was going to suggest a built in true peak limiter for the audio module mainly because I have come across at least 3 modules so far that could have had the potential to damage my hearing and blown my monitors.

What I want to suggest though instead of a limiter, which probably won't help anyway, is a built in fuse, lets call it, for the audio module. When the dB level of +10 or +20 is detected the audio module just completely cuts out saving your ears and your monitors from injury or damage. If you are monitoring at a high volume which I say most of us would, probably 70-80dB maybe more and you get a sudden burst of sound from a bugged out module at such a high volume you could be potentially be listening to a 130dB for a few seconds before your adrenaline kicks in and you kill the sound, not good!

There is a bug I have come across on a couple of reverb modules which caused a sudden burst of a constant white noise like sound. There was another I encountered while beta testing a module, which I also seen before beta test an EQ in other Software. Sending a high frequency LFO to modulate the Hz position that was on a high res peak would cause the audio to glitch out/Feedback into it self because of the High peak and multiple frequencies being boosted at the same time, much like how I seen it with the beta module in VCV. I measured the the beta one in the other software to be over 200dB internally, reaching the peak and going over the limit of the meter.

I only mention it because there is a way to detect how loud the audio is passing through the audio device already so it would just be a matter of muting the master automatically, temporally until you can find the offending module and remove its cable or initialise the module or delete if necessary. Having a safegaurd done with code would be a much quicker way to do it. If a certain level is detected +20dB audio module gets muted or cables removed even.

I seen that there is a bug with audio dropouts and I came across it with that module I was beta testing. From my understanding the bug was causing the audio to cut because it was getting overloaded I guess. Having a safeguard there for audio that produces to much volume on the audio module and to have the audio blow the fuse would be the best way to deal with any complaints that may arise from bugged modules and your ears live to hear another day or a few more years longer than you would get out of them listening to a sudden burst of sound at the threshold of pain.

@AndrewBelt

This comment has been minimized.

Copy link
Member

AndrewBelt commented Jan 24, 2018

@LKHSogpit It clips 0dBV (at 10V reference), or rather your audio driver clips it for you. Anything below that will/should pass through unchanged. If your monitors can handle a sine wave at all frequencies at 0dBV, it can handle any arbitrary signal as long as it is bounded under 0dBV.

The white noise bug is likely because of uncleared buffers. Which ones do you mean?

@Coirt

This comment has been minimized.

Copy link

Coirt commented Jan 24, 2018

It clips to let you know the audio is going over a threshold but it doesn't stop the audio from reaching more than 0dB. If there was a meter between your ears and the monitors the level you would see would be increased more than what your reading was before it started clipping adding decibels to the perceived loudness. Its the perceived loudness that could hurt.

@AndrewBelt

This comment has been minimized.

Copy link
Member

AndrewBelt commented Jan 24, 2018

If you want "choke audio for some duration if >10V is reached", that's the job of another module, not the Audio Interface.

@Coirt

This comment has been minimized.

Copy link

Coirt commented Jan 24, 2018

It should be a safeguard of the audio module not another modules responsibility though. It would be a few lines of code would it not. Just a matter of muting the signal when more than a set amount is reached.

@AndrewBelt

This comment has been minimized.

Copy link
Member

AndrewBelt commented Jan 24, 2018

No, end of discussion. That's very surprising behavior.

@Coirt

This comment has been minimized.

Copy link

Coirt commented Jan 24, 2018

Hope you are not dismissing just out of need this could be serious Andrew dead monitors and damaged ears! You have not heard how loud this sound is so I can understand. But we have not discussed anything. I stated how loud it can reach you said but it can't. Sorry but it can.

If you experience the sound yourself you'll understand. When the volume on the interface at 0% you can still hear the sound bleeding into the monitors. Its a bug with a 3rd party module but being open source these bugs will slip through the cracks.

@AndrewBelt

This comment has been minimized.

Copy link
Member

AndrewBelt commented Jan 24, 2018

It's a great idea for a module, but module recommendations are not encouraged on the issue tracker. I suggest bringing it up in the Facebook User Group or making it yourself if you're able.

It doesn't belong in the Audio Interface, even as a switched feature. That module is also used for CV, where clipping is much more desirable than jumping to 0V for a duration of time. Imagine playing a live show and your entire mix silences for a second. Absolutely ridiculous behavior. Most people don't work with as much headroom as you do, so loud sounds should just play as loud sounds.

@Coirt

This comment has been minimized.

Copy link

Coirt commented Jan 25, 2018

You would not send cv and audio on the same Audio module and even if you did more than likely you would not be sending CV through 1+2 as you would typically want to hear what is played back. It could be something that is toggled so even in the rare case of sending CV through the Audio module's out 1+2 it could be turned off.

I wasn't suggesting as a module just a tweak for the Audio Interface. I'd say you would not use modules that are known to be buggy in a live show anyway you would be well used to what modules are in a patch if you were using live probably have the likes of effects predone.

It probably would be fine for silicon tweeters but for ribbons sending a sine on all frequencies is not recommended from the manufactures and can blow the ribbons out. A sudden burst of sound can cause the damage to anyone with ribbons. The headroom is probably too little alright I'll give you that. What purpose would sending more than 10 volts to modules in VCV serve? genuinely asking. Thought you should not send more than 12v to modular hardware.

@AndrewBelt

This comment has been minimized.

Copy link
Member

AndrewBelt commented Jan 25, 2018

I wasn't suggesting as a module just a tweak for the Audio Interface

And your request was denied, so now your only option is to suggest a module through the channels I mentioned.

@a1laserboy

This comment has been minimized.

Copy link

a1laserboy commented Jan 27, 2018

Seems that you need to use some outboard hardware/software to fix your 'problem' LKHSogpit.

Don't expect the audio source to protect your hardware. YOU protect your hardware.

@VCVRack VCVRack deleted a comment from Coirt Jan 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment