Browser sound in QLab

[tcgass]

Is there an easy way to have an audio stream from Google Chrome or any external streaming application to be integrated in QLab in order to distribute the sound to the defined QLab outputs?

I could of course have the stream/streaming application on a second computer connected directly to the sound console and fade, mute etc. via OSC, but I'm pretty sure there must be a way to do this directly on the computer running QLab, correct?

Thanks for any hint, Thomas

[M K]

Hi,

I would suggest installing Existential Audio's "Blackhole" virtual sound card (free and very handy).  Route the browser audio to it.  Select it is your audio input source in QLab and take things from there:

https://existential.audio/blackhole/

Mike

--
Contact support anytime: sup...@figure53.com
Follow QLab on Twitter: https://twitter.com/QLabApp
User Group Code of Conduct: https://qlab.app/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/0d4df062-7abd-4caf-8fa6-23a4a8b17626n%40googlegroups.com.

[Brian James]

You may also like Virtual Cable 

https://vb-audio.com/Cable/index.htm?gclid=Cj0KCQiA15yNBhDTARIsAGnwe0Xr4ipi2EMfdg9AUzAeFoqfE8g1o-rMaJMw3p9m-iqta4r60FV7xC8aAqp0EALw_wcB

Or my favorite (but  bit pricier)

https://rogueamoeba.com/loopback/

Brian 

Sent from my iPhone

On Dec 1, 2021, at 03:41, M K <mikek...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/CAGDaxEuL-44rTvrAqHV%3D0rQ5WFzu1nMcShDNU9atAO7yqkV7KA%40mail.gmail.com.

[micpool]

i second Mike’s suggestion, but you will have to create an aggregate device with your audio interface, as a mic cue in QLab4  uses the same interface for input and output,.

Mic

[tcgass]

Thanks for all your valuable input! Before posting here I already made a similar approach using Rogue Amoebes "AudioHijack" and an aggregate device, but it seems I either don't understand the principle correctly ;-) or there's something wrong with my setup:

My approach:

1. I have to use a mic cue for bringing in browser audio - 2. I use AudioHijack to send the browser sound to e.g. Nexus, Blackhole, GroundControl or a similar digital routing app - 3. I define an aggregate device in my system containing

the routing app and my main interface - 4. In QLab preferences for Audio Cues Output Patch 1 I select this aggregate device and in Mic Cues Output Patch 1 I select the chosen digital routing app - 5. In the Mic cue containing the browser sound I chose Input/Output patch 1 (showing the name of the digital routing app).

Bingo. When I fire the mic cue, I see the sound coming into that QLab cue - but I don't hear anything... ???

What am I doing wrong?

[micpool]

I think you;re overcomplicating things. You only need to use your virtual cable app and your audio device in your aggregate.

In the screenshots below I'm using a Blackhole 2ch instance and the external Headphone OP of a 2018 Mac mini.

The audio from Safari Is just routing through the output selected in System preferences.

But first a very important point. QLab only looks at the Audio devices available AND THEIR CONFIGURATION at workspace open! So you can't edit your aggregate device while your workspace is open.

There are 2 ways the aggregate could be, depending on the order you patched it. Here's aggregate version 1

The aggregate device is patch 1 in the output patch assignments FOR MIC CUES (There are separate patches for audio cues and mic cues)

 The blue device in the aggregate is Blackhole which has IP on ch 1+2 and OP on 3+4 ( so we never want to route the inputs to 3+4!!)

The grey device is the External Headphone OP which conveniently is on OP 1+2 so the routing is very straightforward

If you had selected the devices in the other order you would end up with this

The blue device in the aggregate is Blackhole which has IP on ch 1+2 and OP on 1+2 ( so we never want to route the inputs to 1+2-which is of course  the default!!)

The grey device is the External Headphone OP which this time is  on OP 3+4 so we have to re route IP 1+2  to Cue outputs 3+4 in the Cue Matrix

The important thing is to look at the input and output channels of your aggregate, which will be more complex using a multichannel device with  its of inputs and outputs and set up the cue matrix accordingly.

Mic

[jamesjen...@gmail.com]

It’s worth asking about the risk assessment for this project. If this Mac+Qlab is only relaying a livestream for a conference or panel, then sure, experiment away.

Though if this is a Qlab with a full theatrical sound design (and perhaps a wish for some live streamed preshow music), I would be fairly hesitant to dive into some of the suggestions above. I’ve run into serious trouble with aggregate devices and “virtual audio cabling” one too many times. It takes up processing power, and introduces new and mysterious points of failure.

I might loop back around to OP’s original inclination - “I could of course have the stream/streaming application on a second computer connected directly to the sound console and fade, mute etc. via OSC” and say, yes, that is the most reliable way to do it.

Personally, instead of OSC controlling a mixer, I’ve often plugged a second device (Macbook, Intel NUC, retired mobile phone, Raspberry Pi…) into the interface (or mixer, if that’s your interface) and used a Microphone Cue to patch it in. As that way, you have the full Qlab control over the signal. Hitting “esc” mutes the signal, ect.

Plus, there are benefits to keeping your main show computer offline.

Though, it would be neat if Qlab one day supported .m3u sources. Until then, my inclination is to keep the “Livestream” machine separate from the “Theatrical Sound Design” machine.

[tcgass]

A big thanks to all of you providing such great information regarding my question! @Mic: thanks for clearing in detail all about the aggregate device, which in fact works great and finally made me understand everything! However, I decided to follow James' advice and use a separate laptop connected directly to the mixing console, especially because this is a ongoing show and I think one should "never change a winning setup" ;-) We're only using this for one special performance, where we need this live situation to surprise and honour one of the actors, so i don't have to change anything in the orginial QLab session.
Once again this is proof to me, that I will always use QLab for shows - not only 'cause it's a great piece of software, but also because you guys are simply great in supporting quickly whenever a problem occurs!
Thanks again to all of you, wishing you a pieceful and relaxing X-mas time!

[micpool]

On Thursday, December 2, 2021 at 2:26:39 AM UTC jamesjen...@gmail.com wrote:

. I’ve run into serious trouble with aggregate devices and “virtual audio cabling” one too many times. It takes up processing power, and introduces new and mysterious points of failure.

I generally agree with this, but have sometimes used aggregate devices. As with all things it’s a matter of testing any set up thoroughly before, deploying  in a mission critical  situation.

If you have an interface with analog inputs ,and outputs there is of course the possibility of  making physical aggregate devices by interconnecting interfaces. e.g  mac headphone output to mic inputs 1+2 on your main interface.

You can use the same technique to make physical loopbacks on a single interface to route audio between applications, route LTC between QLab workspaces for testing purposes etc.

With both aggregate devices, or physical connections you have to be very careful about not creating feedback loops and in some configurations you might get ground loop problems.

Mic