Rack: Audio interface revamp

[AndrewBelt]

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]

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]

-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]

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]

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]

As a wanter of function, anything which easily works is fine. Stereo in on
a dial select "till sound", and similar for an out. If the port is
allocated, noise in, or mute.

On 14 September 2017 at 23:22, Josue Arias [e-mail] wrote:

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

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/VCVRack/Rack/issues/82#issuecomment-329625208, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAkQlXcc7TSZe2LIJuSW5WPIdmVlJ0Rcks5siac0gaJpZM4PYGlL
.

--
http://www.kring.co.uk

[AndrewBelt]

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

[TronicLabs]

libsoundio, not have the ASIO backend

[AndrewBelt]

Will bump https://github.com/andrewrk/libsoundio/issues/23

[tildebyte]

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]

^ Already mentioned, but good idea!

[guidozzz]

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]

@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]

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

[djpeterso23662]

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]

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]

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

[AndrewBelt]

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]

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

[AndrewBelt]

Reverting back to Portaudio. RtAudio is easy to build, but the software has many more issues and incompatibilities than Portaudio.

[AndrewBelt]

Changing my mind, with the condition that
1) I don't support Jack on any platform for v0.5.0
2) I don't help anyone get ASIO to build. That's up for the community to figure out. I have my own hacky methods for the sake of supporting it for v0.5.0

[bontric]

@AndrewBelt The issues with Jack have been fixed with https://github.com/thestk/rtaudio/commit/ce13dfbf30fd1ab4e7f7eff8886a80f144c75e5d pretty quickly after I reported the issue. (Also see https://github.com/thestk/rtaudio/issues/113) So using the latest git version should resolve the issues. (If you don't want to include this in the upstream version in the rack build, we can simply advise Jack users to build the library manually)

I also discussed the other problem with Jack here https://github.com/thestk/rtaudio/issues/111 which concluded that what shouldn't use getDeviceName too frequently, but I think even calling it every 15 seconds in AudioInterface toJson shouldn't cause a problem on a reasonably new system.

[2johjoh2]

Andrew, I'm on Mac, so no issues with ASIO ao (so not completely unbiased), so I hope the backend gets sorted out without to much of your effort ...
Anyhow : from a UI elegance perspective, I think synti has got a point - you might easily get huge modules for quite a few interfaces out there.
But again : you have the insight knowledge to balance results vs efforts so ...

[AndrewBelt]

@bontric Great! For the v0.5.0 release, I haven't figured out how to implement the logic If you have Jack on your system, use Jack, otherwise disable it and not crash so I'll look at this later.

[bontric]

I'm not sure whether I'm missing something, but I don't see the need for this logic:

I haven't figured out how to implement the logic _If you have Jack on your system, use Jack, otherwise disable it and not crash_

More specifically, I don't see a need to "disable it" since the bug won't occur when using other audio systems.

If I missed your point.. A simple approach to implement this logic would be to pass an additional argument to make dep to specify the audio compatibility (Similar to RtAudio's ./configure --with-jack) .

[AndrewBelt]

If I distribute a binary linked to Jack, I could have it rely on the OS's version of libjack, in which case I'd have to make sure RtAudio is calling dlopen() on libjack instead of load-time linking, which I don't think it does.

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.

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.

[AndrewBelt]

Solved a lot of the audio problems with 2bc6678ca5e838134ca7b040e043ff223b270e84, 4f703e394404c733e18d68d6cf5256a4e2bc561e, d1f213a3e1f7a9220f9ea792709f41f20ed8ef06, and 91d414376c04a45d1874fb702df75d18550546c0

[bontric]

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 :wink: , 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]

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

[bontric]

Ohh, now I get what you mean :octopus: Sorry..

[Cordoha]

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]

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]

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]

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]

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

[simonvanderveldt]

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]

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? :+1: for no longer use JACK, :-1: for still use JACK.

[ndrspcfd]

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]

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]

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

[simonvanderveldt]

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]

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]

@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]

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]

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

[Coirt]

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]

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

[Coirt]

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]

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]

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]

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]

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.