Search form

[audio_jungle]

Before trying anything advanced with Rogue Amoeba's Loopback, here is something that I want to use it for that shouldn't be difficult to set up, yet it is...

@Desmond, I can definitely use your help here!

Every weekend, I am busy listening to (and recording) syndicated radio shows off of the Internet. For example, "Casey Kasem's American Top-40 - The 80s"

I have been doing so for over a decade with my old Macintosh, and I use Soundflower to allow me to record from a browser into Audacity. Now I need a similar set up using Loopback.

And the goal is that once I set things up, I shouldn't have to touch the settings again.


Here is where the confusion exists...

First, based on feedback issues that I was having when I tried to use Loopback to record a podcast, Rogue Amoeba's tech support told me that I should *never* set the System Preferences > Sound > Input and System Preferences > Sound > Output to point to Loopback.

Instead, they said that I should always leave Sound > Input and Sound > Output "set to my computer's hardware" (e.g. "Internal microphone" or "Internal speakers"). It was implied this could also include external hardware like my "Logitech USB Headset".

Second, when I read the online manual that came with Loopback, it implies that when you launch Loopback, that the default virtual machine called "Loopback Audio" was a "pass-through" device, meaning that out-of-the-box, this virtual machine should capture any applications (e.g. Firefox) on your Macintosh and allow them to be used as the "input" into other applications (e.g. Audacity).


Knowing points #1 and #2 above, I set out to use Loopback to capture a streaming radio station (i.e. "www.98.3cifm.com") playing in Firefox and recording it to Audacity.

Based on the advice in point #1, I set System Preferences > Sound as follows...
Input > Internal Microphone (muted)
Output > Internal Speakers (normal listening volume)


In Audacity, under Preferences > Devices, I chose the following...
Playback Device > Built-In Output
Recording Device > Loopback Audio

Also, in Loopback...
Loopback Audio > checked
Mute audio sources > unchecked
Monitor audio through > unchecked

With these settings, Loopback should serve as a "pass-through" which allows me to capture streaming audio in Firefox, and pass it along to Audacity to record, since Audacity is pointing to this "Loopback Audio" virtual machine.

With the radio stream playing in my Mac's speakers, I pressed "record" in Audacity, but all I get is a flat line... (i.e. nothing is captured)


Now, there are two ways to fix this issue, but both of them seem to contradict Points #1 and #2 above...


Fix #1:
If I return to System Preferences > Sound and set things to...
Output > Loopback Audio

Then I can see Audacity recording the radio stream, however, I have lost audio on my Macintosh's speakers?!

I can, of course, choose "Monitor audio through: Built-In Output" in Loopback, but this approach will create another problem...

If all I did was record radio shows online, then Fix #1 would work. But as I mentioned above, my goal is to set things up so I don't have to fiddle with audio settings as I go about doing different things!!

To create a configuration that should allow me to record radio shows, record phone calls, and record podcasts that might include a phone call and background music, I tried this set up...

In Loopback...
I created a new virtual-device called: "Loopback: Headset+iTunes+Zoiper"

Audio Sources:
- Logitech USB Headset
- iTunes
- Zoiper

Mute audio source > unchecked
Monitor audio through > Logitech USB Headset

In System Preferences, I chose...
Sound > Output > "Loopback: Headset+iTunes+Zoiper

In Audacity...
Playback Device > Built-in Output
Recording Device > Loopback: Headset+iTunes+Zoiper

While this configuration records streaming audio okay, if I also try to record my voice - say in a podcast - then I get lots of feedback?!


In Loopback, if I changes things to...
Mute audio source > unchecked
Monitor audio through > unchecked

...then the feedback goes away when recording my voice, but I can't hear the streaming music or my voice in my headset, and this is necessary to do a proper voice recording - not to mention being able to speak on the phone!!


So with Fix #1, I can record streaming radio shows and listen to them simultaneously on my Mac's internal speakers, but if I try to record a Zoiper phone call or do a podcast, my voice will be distorted.

And this is why Rogue Amoeba tech support told me to "always point your System Preferences to your Mac's hardware".

However, this is not a working solution either!


Fix #2:
In Loopback, I made the following changes to "Loopback: Headset+iTunes+VLC"...

Audio Sources:
- Logitech USB Headset
- iTunes
- Zoiper
- Firefox <=== NEW

Mute audio source > unchecked
Monitor audio through > unchecked

In System Preferences...
Sound > Output > Logitech USB Headset

In Audacity...
Playback Device > Logitech USB Headset
Recording Device > Loopback: Headset+iTunes+Zoiper


Now I can record streaming audio in Audacity, and as I simultaneously speak into my USB headset, I get NO FEEDBACK and yet my voice is successfully recorded on top of the music.

And I suppose this configuration could be used as a "catch-all" allowing me to set up my Macintosh so that I can: 1.) Record radio shows, 2.) Record phone calls, and 3.) Record podcasts (potentially with a caller and background music), but these settings just feel *wrong* because they go against my what Points #1 and #2 above said...

I cannot ever remember something so complicated as this?!

So what do you think about all of this?!

Thanks,


Audio Jungle

[desmond]

First, based on feedback issues that I was having when I tried to use Loopback to record a podcast, Rogue Amoeba's tech support told me that I should *never* set the System Preferences > Sound > Input and System Preferences > Sound > Output to point to Loopback.

That's good advice from Support. It mostly doesn't make sense to do this.

Instead, they said that I should always leave Sound > Input and Sound > Output "set to my computer's hardware" (e.g. "Internal microphone" or "Internal speakers"). It was implied this could also include external hardware like my "Logitech USB Headset".

Yep.

Second, when I read the online manual that came with Loopback, it implies that when you launch Loopback, that the default virtual machine called "Loopback Audio" was a "pass-through" device,

Correct.

meaning that out-of-the-box, this virtual machine should capture any applications (e.g. Firefox) on your Macintosh and allow them to be used as the "input" into other applications (e.g. Audacity).

No. This is an incorrect assumption on your part, and you thinking it works in a way which is incorrect is creating some confusion.

What "pass-through" means in this context is *not* "it should capture any applications".
In this context, no applications are *captured* at all.

It means whatever your *route* to Loopback's input, will appear at Loopback's output - exactly the same as how SoundFlower works.

So, an an example, if you had an application that let you specify which device to use as it's output (say, one DAW like Logic), and you set that to output to your Loopback virtual device, then in another application (say, a second DAW like Reaper), you could choose the Loopback device as it's input. The audio output from Logic now passes through Loopback, to Reaper.

Applications are only *captured* (ie, the audio output of an application is "hijacked" and diverted to Loopback) in Loopback if you add those applications as sources in Loopback's preferences. If there are no apps there, there is no capturing going on at all.

Knowing points #1 and #2 above, I set out to use Loopback to capture a streaming radio station (i.e. "www.98.3cifm.com") playing in Firefox and recording it to Audacity.

Based on the advice in point #1, I set System Preferences > Sound as follows...
Input > Internal Microphone (muted)
Output > Internal Speakers (normal listening volume)

In Audacity, under Preferences > Devices, I chose the following...
Playback Device > Built-In Output
Recording Device > Loopback Audio

Also, in Loopback...
Loopback Audio > checked
Mute audio sources > unchecked
Monitor audio through > unchecked

With these settings, Loopback should serve as a "pass-through" which allows me to capture streaming audio in Firefox, and pass it along to Audacity to record, since Audacity is pointing to this "Loopback Audio" virtual machine.

No, there will be zero audio in Loopback at all, because you have nothing routed to it, and no apps hijacked to it.

With the radio stream playing in my Mac's speakers, I pressed "record" in Audacity, but all I get is a flat line... (i.e. nothing is captured)

You should now hopefully see why that is the case!

Now, there are two ways to fix this issue, but both of them seem to contradict Points #1 and #2 above...

Fix #1:
If I return to System Preferences > Sound and set things to...
Output > Loopback Audio

No, this is incorrect, and you should (as per the support advice you were given) never route the system output back to Loopback, as you will either get feedback or lose the ability to hear what you are doing.

Then I can see Audacity recording the radio stream, however, I have lost audio on my Macintosh's speakers?!

Because you've told your system not to output to the speakers, by choosing a different system output device.

To create a configuration that should allow me to record radio shows, record phone calls, and record podcasts that might include a phone call and background music, I tried this set up...

In Loopback...
I created a new virtual-device called: "Loopback: Headset+iTunes+Zoiper"

Audio Sources:
- Logitech USB Headset
- iTunes
- Zoiper

Mute audio source > unchecked
Monitor audio through > Logitech USB Headset

In System Preferences, I chose...
Sound > Output > "Loopback: Headset+iTunes+Zoiper

No, don't do this. Don't set the system output to Loopback, it will just give you problems.

Fix #2:
In Loopback, I made the following changes to "Loopback: Headset+iTunes+VLC"...

Audio Sources:
- Logitech USB Headset
- iTunes
- Zoiper
- Firefox <=== NEW

Mute audio source > unchecked
Monitor audio through > unchecked

In System Preferences...
Sound > Output > Logitech USB Headset

In Audacity...
Playback Device > Logitech USB Headset
Recording Device > Loopback: Headset+iTunes+Zoiper

Now I can record streaming audio in Audacity, and as I simultaneously speak into my USB headset, I get NO FEEDBACK and yet my voice is successfully recorded on top of the music.

Yes, this is the config you want.

And I suppose this configuration could be used as a "catch-all" allowing me to set up my Macintosh so that I can: 1.) Record radio shows, 2.) Record phone calls, and 3.) Record podcasts (potentially with a caller and background music), but these settings just feel *wrong* because they go against my what Points #1 and #2 above said...

They feel wrong to you because they are based on an incorrect assumption you made.
Hopefully now you feel better about it!

Note: You don't need to combine the two separate tasks (recording radio show, record podcast) into the same setting.
You can create Loopback device called "Radio Record" which hijacks Firefox alone, and a separate Loopback device called "Podcasting" with the config above minus Firefox.

Why? It keeps thing simpler, and means you're not accidentally recording you talking while recording from radio shows...

[audio_jungle]

@Desmond,

Working hard to "grok" all of this sound stuff!

Thank you for the last response - it helped to reinforce the conclusions that I basically came to on my own.

However, after experimenting some more, and re-reading what you said, I would like to disagree with a couple of your comments...

meaning that out-of-the-box, this virtual machine should capture any applications (e.g. Firefox) on your Macintosh and allow them to be used as the "input" into other applications (e.g. Audacity).

No. This is an incorrect assumption on your part, and you thinking it works in a way which is incorrect is creating some confusion.

What "pass-through" means in this context is *not* "it should capture any applications".
In this context, no applications are *captured* at all.

It means whatever your *route* to Loopback's input, will appear at Loopback's output - exactly the same as how SoundFlower works.

First off, I now understand why choosing Loopback as either an Input or Output device in System Preferences creates issues.

I totally get that.

However, it is incorrect to say that Loopback doesn't capture/route sound between applications automatically.

Why am I disagreeing?

Because of these settings mentioned earlier...

In Loopback...
Default virtual-device: "Loopback Audio" > checked

Audio Sources:
- n/a

Mute audio source > unchecked
Monitor audio through > unchecked


In System Preferences...
Input > Internal Microphone (muted)
Output > "Loopback Audio"


In Audacity...
Playback Device > Built-in Output
Recording Device > "Loopback Audio"


With the above configuration, Loopback most certainly is "routing" audio from Firefox to Audacity, because I can see it recording my radio show now!

So, out-of-the-box, Loopback is in "pass-through" mode and can route audio between applications.

However, to your point - which I am not contesting - this is not the way you should use Loopback in more advanced situations (e.g. wanting to record both from Firefox and a USB Headset).

Maybe now you can better understand why I was getting so confused?

Loopback allows you to capture audio in a couple of different configurations, and some are better than others!!

If Rogue Amoeba was able to better articulate this with their Tech Support or in their manual, then all of this confusion could have been avoided on my part, and it would give me back at least a week of my life!!

(I hate lazy software companies!)

Then again, to "grok" something, I guess you have to fall down at least a couple of times to truly learn?!

Applications are only *captured* (ie, the audio output of an application is "hijacked" and diverted to Loopback) in Loopback if you add those applications as sources in Loopback's preferences. If there are no apps there, there is no capturing going on at all.

Again, this is not true.

No, this is incorrect, and you should (as per the support advice you were given) never route the system output back to Loopback, as you will either get feedback or lose the ability to hear what you are doing.

For anything more than simply capturing streaming radio from Firefox, this indeed does happen.

Again, Rogue Amoeba should do a better job explaining this to people, because it is NOT obvious. (After all... It even tripped you up!)

Note: You don't need to combine the two separate tasks (recording radio show, record podcast) into the same setting.

You can create Loopback device called "Radio Record" which hijacks Firefox alone, and a separate Loopback device called "Podcasting" with the config above minus Firefox.

Why? It keeps thing simpler, and means you're not accidentally recording you talking while recording from radio shows...

Yes and no. I am all for dividing up responsibilities. However, I also know I am horrible at remembering why I set things up on my computer as I did.

In the end, when I am running late to record my upcoming radio show online, or I finally get a call-back from some slime ball business, or I am feeling "inspired" and want to quickly capture my thoughts in a podcast, I do NOT want to screw up capturing any of those items because I chose the wrong settings or because I have to take a few minutes fiddling around to switch from one capture mode to the next!

Now that I better understand how Loopback works - thanks a lot in part to you - my next challenge is coming up with a "workflow" that helps me to meet the above goal.

More questions to follow!

Thanks,


Audio Jungle

[desmond]

However, it is incorrect to say that Loopback doesn't capture/route sound between applications automatically.

No, I am correct in how I described it working, and I checked/verified before posting.

Your comment was that with no apps hijacked, and no audio routed to Loopback, Loopback captures all of the system output automatically by default (this was your understanding of what Pass-Through meant).

I told you this is not the case, and you then contested this advice with an example setup where you routed audio to Loopback, and said "I can record Firefox, so your comment was wrong."

Loopback does not hijack or contain the output of all applications in pass-through mode by default, as you suggest. It does no hijacking at all. But yes, if you *route your system audio output to Loopback*, you are indeed routing audio through Loopback, in pass-through mode, but that's because you've chosen to route it there, not because it inherently behaves like this, or does it automatically with no routing going on.

Why am I disagreeing? Because of these settings mentioned earlier...
In System Preferences...
Output > "Loopback Audio"

With the above configuration, Loopback most certainly is "routing" audio from Firefox to Audacity, because I can see it recording my radio show now!

What is happening in this config is that you have set your system output to Loopback. (Which as we've already said is a poor thing to do for the reasons already mentioned.)

So Firefox plays out to your system output (which is normally your speakers) but because you have changed the system output to route to Loopback, that's why there is audio. In short, you've manually routed some audio (everything the system generates) to the Loopback device, in exactly the way I suggested, and this is why you get audio there. Put your system output back to your speakers, and you'll see no audio on Loopback, because you now haven't hijacked Firefox, or routed any audio to Loopback.

In Pass Through mode, no applications are "hijacked", and the only audio that will be on the Loopback bus is audio you have routed there. In your config, you routed your system output there. Which is all exactly as I have described Loopback works.

So, out-of-the-box, Loopback is in "pass-through" mode and can route audio between applications.

Sure, as I said in the first post, with no applications hijacked (ie specified in the sources box), Loopback will only contain audio you route to it. That's what pass through mode is - whatever you route to Loopback will be sent there, and available in another application when they receive audio from Loopback.

Loopback allows you to capture audio in a couple of different configurations, and some are better than others!!

Of course. The same is true with mixing desk, a tape machine and a some other audio devices - there are many ways to hook things up, and not all are optimum, but they will vary according to need. Figuring out how to route things is part of the audio engineer's job, and it's not trivial in many cases!

Applications are only *captured* (ie, the audio output of an application is "hijacked" and diverted to Loopback) in Loopback if you add those applications as sources in Loopback's preferences. If there are no apps there, there is no capturing going on at all.

Again, this is not true.

Sorry, but yes it is. Perhaps you are misunderstanding what I'm writing. I'm trying to be as clear as I can, but I can only go so far.

I know you are new here, so don't really know how to qualify my comments/advice. All I can say is, I do not help, advise or even really comment on things unless I know what I'm talking about, and my advice is solid. If I didn't do this, there are plenty of others here who would show me up for being wrong in a heartbeat.

I didn't comment, for example, on your initial posting about your podcasting setup, as I knew I'd have to spend time understanding what you wanted to do, and check out some of the tools you were using as I didn't have direct experience of Loopback in particular to know it's exact behaviour or interface, to be at all helpful. All of which requires some effort on my part. However, when you weren't getting much other help, I dived in, and actually got and installed the tools, and ran through various setups to be *sure* of how things worked, and then weighed in to try to help.

I know you are struggling with some of these issues, and you find them a bit complex, but for me they are pretty straightforward. And I've been hijacking and routing audio around my system for many years.

To recap: Audio enters the Loopback device in two ways *only*:

- If an application (that usually outputs to the System output) is added to the Sources box for the active Loopback device, it's audio is Hijacked, and instead of normally being routed to the system output, gets diverted to Loopback. This application's audio is hijacked (this terminology - and technology - comes from their own Audio Hijack app, which as I said I've been using for years.)

- If an application has an audio output setting you can change, and you manually set it to the Loopback, then the application now sends it's audio to Loopback. This is *routing* audio to Loopback, and involves no app hijacking at all.

(Of course you can do both things at once.)

Part of the reason Hijacking is so useful is it allow you to control where the audio output of applications go, when you otherwise normally don't have any control as they go to the system output by default.

So, in pass through mode, where Loopback is active, but you have not hijacked any applications, and have not routed any audio to Loopback, there will be nothing on the Loopback bus at all. If you want to record from Firefox, hijack it's output by adding it as a source, and in Audacity record from Loopback.

Again, Rogue Amoeba should do a better job explaining this to people, because it is NOT obvious. (After all... It even tripped you up!)

No, it did not. My understanding of these apps and inter-app routing (and audio routing in general) is solid, tested/verified to make sure I understood the behaviour, and I know what I'm talking about.

[audio_jungle]

This is what I get for questioning a jedi...

Loopback does not hijack or contain the output of all applications in pass-through mode by default, as you suggest. It does no hijacking at all. But yes, if you *route your system audio output to Loopback*, you are indeed routing audio through Loopback, in pass-through mode, but that's because you've chosen to route it there, not because it inherently behaves like this, or does it automatically with no routing going on.

Fair enough.

Why am I disagreeing? Because of these settings mentioned earlier...
In System Preferences...
Output > "Loopback Audio"

With the above configuration, Loopback most certainly is "routing" audio from Firefox to Audacity, because I can see it recording my radio show now!

What is happening in this config is that you have set your system output to Loopback. (Which as we've already said is a poor thing to do for the reasons already mentioned.)

So Firefox plays out to your system output (which is normally your speakers) but because you have changed the system output to route to Loopback, that's why there is audio. In short, you've manually routed some audio (everything the system generates) to the Loopback device, in exactly the way I suggested, and this is why you get audio there. Put your system output back to your speakers, and you'll see no audio on Loopback, because you now haven't hijacked Firefox, or routed any audio to Loopback.

Fair enough.

So, out-of-the-box, Loopback is in "pass-through" mode and can route audio between applications.

Sure, as I said in the first post, with no applications hijacked (ie specified in the sources box), Loopback will only contain audio you route to it. That's what pass through mode is - whatever you route to Loopback will be sent there, and available in another application when they receive audio from Loopback.

Okay.

Sorry, but yes it is. Perhaps you are misunderstanding what I'm writing. I'm trying to be as clear as I can, but I can only go so far.

I know you are new here, so don't really know how to qualify my comments/advice. All I can say is, I do not help, advise or even really comment on things unless I know what I'm talking about, and my advice is solid. If I didn't do this, there are plenty of others here who would show me up for being wrong in a heartbeat.

I never questioned your wisdom or integrity... I simply thought that some comments you made seemed a tad off.

Reading your last comments, and pondering things some more, I can see how my words and understanding weren't completely right.

Again, this entire process is not nearly as intuitive as it is to an expert like you...

I didn't comment, for example, on your initial posting about your podcasting setup, as I knew I'd have to spend time understanding what you wanted to do, and check out some of the tools you were using as I didn't have direct experience of Loopback in particular to know it's exact behaviour or interface, to be at all helpful. All of which requires some effort on my part. However, when you weren't getting much other help, I dived in, and actually got and installed the tools, and ran through various setups to be *sure* of how things worked, and then weighed in to try to help.

And I really appreciate all of your help, and have thanked you a bunch.

I suspected that you installed Loopback and started playing around with things based on your responses, and I thank you immensely for the help!

I know you are struggling with some of these issues, and you find them a bit complex, but for me they are pretty straightforward. And I've been hijacking and routing audio around my system for many years.

That is why you are an "expert" and I am a "newbie"!

To recap: Audio enters the Loopback device in two ways *only*:

- If an application (that usually outputs to the System output) is added to the Sources box for the active Loopback device, it's audio is Hijacked, and instead of normally being routed to the system output, gets diverted to Loopback. This application's audio is hijacked (this terminology - and technology - comes from their own Audio Hijack app, which as I said I've been using for years.)

Based on what I have seen today, it also appears that the *hijacked* audio is ultimately allowed to continue on its way to the System output. And this is why when I add Firefox as an "audio source" in Loopback, that is I have my System > Output set to my Internal Speakers/USB Headset that I can listen to the streaming radio on Firefox while Loopback makes it available to other applications like Audacity, right?

- If an application has an audio output setting you can change, and you manually set it to the Loopback, then the application now sends it's audio to Loopback. This is *routing* audio to Loopback, and involves no app hijacking at all.

Okay.

Part of the reason Hijacking is so useful is it allow you to control where the audio output of applications go, when you otherwise normally don't have any control as they go to the system output by default.

Like with Firefox...

So, in pass through mode, where Loopback is active, but you have not hijacked any applications, and have not routed any audio to Loopback, there will be nothing on the Loopback bus at all.

Okay.

If you want to record from Firefox, hijack it's output by adding it as a source, and in Audacity record from Loopback.

That is what I have been experimenting with today...

Again, Rogue Amoeba should do a better job explaining this to people, because it is NOT obvious. (After all... It even tripped you up!)

No, it did not. My understanding of these apps and inter-app routing (and audio routing in general) is solid, tested/verified to make sure I understood the behaviour, and I know what I'm talking about.

So I stand corrected... It did not trip YOU up.

Nonetheless, the documentation - and answers I got from support - could be much better.

After several attempts, Rogue Amoeba is unable to truly explain how its software works.

Thank God for experts on the Internet like you who are willing to take time to help out a stranger!!



Sincerely,


Audio Jungle

[desmond]

Based on what I have seen today, it also appears that the *hijacked* audio is ultimately allowed to continue on its way to the System output. And this is why when I add Firefox as an "audio source" in Loopback, that is I have my System > Output set to my Internal Speakers/USB Headset that I can listen to the streaming radio on Firefox while Loopback makes it available to other applications like Audacity, right?

So... Yes, but not *quite*

It's a *little* more complicated than that (for good reasons), because Loopback is trying to help you not make routing mistakes, such as routing the same audio multiple times through to the same output etc.

Let's try and explain Loopback's behaviour with an example.

So, let's say you have audio playing in Firefox, which is going to the system output as per normal operation.
You then enable Loopback, and have Firefox as a hijacked source. Audacity is not running.

At the moment Firefox is still playing to your system output (either Loopback is hijacking Firefox, and passing it on to the system output by default, *or* Firefox hasn't *technically* been actually hijacked yet, it's impossible to know how Loopback is programmed, we can just observe the behaviour). But the bottom line is that, at this moment, Firefox audio so far isn't doing anything beyond normal.

*But* - as soon as you have another application that's set to receive audio from Loopback (eg, you run Audacity which has Loopback set as it's audio input), Loopback now knows it's "in use" and has to divert the audio away from it's regular use, and instead pass it through Loopback, so it can be recorded to Audacity.

(Verified by me sticking meters at various points in the signal path and observing what audio is being passed around when.)

So the moment you set Loopback as an input to something, that's when audio starts to get sent to the Loopback device. Otherwise it just behaves as normal.

Ok. So what's our path to *hearing* Firefox, under these conditions?

In Loopback, if "Mute audio sources" is checked, Firefox will *only* send to Loopback (while active of course), but if it's unchecked, Firefox will *also* be sent to the normal system output path as well. You can think of this as the Firefox audio is sent *both* to Loopback, and the system output. The checkbox only works when hijacking is taking place (ie, when another app is listening to the Loopback input), otherwise it does nothing. It's normally best left on.

And the second "Monitor Through" option lets you choose *another* output device to monitor to, in addition to the path above. Leave this off for now, you likely won't need it.

Note: The manual explains both these checkboxes in a straightforward enough manner, and also says that enabling the Monitor Through checkbox will *always* make Loopback active/in use *even if no apps are using the Loopback device*. I mention this just to be thorough about the above behaviour - like I say, just forget about the second option for now.

However, there is also yet *one more* monitor pathway - Audacity is receiving audio from Loopback, but it itself probably has the system output set as it's output. If Audacity is set to monitor sources, then it will pass incoming audio through to it's output so you can hear it.

This is why your monitoring options are useful, as it's all to easy to, for example, have Loopback passing your audio to the system output, and also have Audacity passing a copy of it to the system output, leading to not so nice results.

I'd suggest the easiest way to proceed is to leave "Mute Audio Sources" checked in Loopback, and monitor via Audacity (but you can if you prefer do it the other way around.)

Hopefully I'm clear enough in explaining this - but if at any stage you're not sure what I'm saying, just let me know and I'll try to be clearer.

Part of the reason Hijacking is so useful is it allow you to control where the audio output of applications go, when you otherwise normally don't have any control as they go to the system output by default.

Like with Firefox...

Exactly!

Thank God for experts on the Internet like you who are willing to take time to help out a stranger!!

No worries - that's what makes the internet (and this forum in particular) so cool!. We all benefit from learning from others and I'm sure others reading this thread struggling with similar issues will hopefully find something useful too.

[audio_jungle]

Based on what I have seen today, it also appears that the *hijacked* audio is ultimately allowed to continue on its way to the System output. And this is why when I add Firefox as an "audio source" in Loopback, and I have my System > Output set to my Internal Speakers/USB Headset that I can listen to the streaming radio on Firefox while Loopback makes it available to other applications like Audacity, right?

So... Yes, but not *quite*

It's a *little* more complicated than that (for good reasons), because Loopback is trying to help you not make routing mistakes, such as routing the same audio multiple times through to the same output etc.

Let's try and explain Loopback's behaviour with an example.

So, let's say you have audio playing in Firefox, which is going to the system output as per normal operation.

You then enable Loopback, and have Firefox as a hijacked source. Audacity is not running.

At the moment Firefox is still playing to your system output (either Loopback is hijacking Firefox, and passing it on to the system output by default, *or* Firefox hasn't *technically* been actually hijacked yet, it's impossible to know how Loopback is programmed, we can just observe the behaviour). But the bottom line is that, at this moment, Firefox audio so far isn't doing anything beyond normal.

Agreed.

*But* - as soon as you have another application that's set to receive audio from Loopback (eg, you run Audacity which has Loopback set as it's audio input), Loopback now knows it's "in use" and has to divert the audio away from it's regular use, and instead pass it through Loopback, so it can be recorded to Audacity.

(Verified by me sticking meters at various points in the signal path and observing what audio is being passed around when.)

How exactly did you put meters in between these virtual parts?

Ok. So what's our path to *hearing* Firefox, under these conditions?

In Loopback, if "Mute audio sources" is checked, Firefox will *only* send to Loopback (while active of course), but if it's unchecked, Firefox will *also* be sent to the normal system output path as well. You can think of this as the Firefox audio is sent *both* to Loopback, and the system output. The checkbox only works when hijacking is taking place (ie, when another app is listening to the Loopback input), otherwise it does nothing. It's normally best left on.

And the second "Monitor Through" option lets you choose *another* output device to monitor to, in addition to the path above. Leave this off for now, you likely won't need it.

Okay.

Note: The manual explains both these checkboxes in a straightforward enough manner, and also says that enabling the Monitor Through checkbox will *always* make Loopback active/in use *even if no apps are using the Loopback device*. I mention this just to be thorough about the above behaviour - like I say, just forget about the second option for now.

On what page of the PDF is that?


Taking into consideration what you said above, here is what I observe...

These are my current settings...

System Preferences:
Input > Logitech USB Headset
Output > Logitech USB Headset


Loopback
Virtual Device > vHeadset+Firefox

Sources:
- Logitech USB Headset
- Firefox

Mute audio sources > checked
Monitor audio through > unchecked


Audacity
Playback Device > Logitech USB Headset
Recording Device > vHeadset+Firefox


Firefox
Playing streaming audio...

- I am wearing my USB headset.
- Firefox is on, and pointing to http://www.cifm.com
- Audacity is off.
- My Loopback virtual device is unchecked.

- I can hear music from the online radio station.

- If I enable my Loopback virtual device, there are no changes.

- Next, I launch Audacity.
- I can still hear the stream.

- I open an Audacity project.
- I can still hear the stream.

- I press "Record" in Audacity...
- The music in my headset is shut OFF.
- I can see "signal" being recorded in Audacity, though.

- I go to Loopback, and uncheck "Mute audio sources"
- I can now hear the stream again.


If I had to guess, this is how things work...

When Loopback is out of the equation, then streaming radio from Firefox is passed to macOS and then to your hardware, where you hear it on your defined "Output", e.g. Internal Speakers, Headphones, USB Headset, External Speakers.

When a virtual device is created in Loopback and turned on, Loopback *inserts* itself between any applications (e.g. Firefox) and macOS and your hardware.

As such, signal is NOT going directly from Firefox to macOS and your hardware anymore.

If the application defined in "Audio Sources" is NOT actively pulling the *hijacked* signal from Loopback's virtual device, then Loopback presumably passes along the signal from Firefox to macOS and your hardware.

However, if the application defined in "Audio Sources" is ACTIVELY pulling the *hijacked* signal from Loopback's virtual device, then a few things happen...

1.) Loopback now passes along the *hijacked* signal from the audio source (e.g. Firefox) to the application using the virtual device as an "input" (e.g. Audacity).

2.) Loopback looks at its own settings

3.) If "Mute audio sources" is checked, then Audacity still gets the *hijacked* signal, but the signal is NOT passed along to macOS and your hardware, so you can see things being captured in Audacity, but cannot hear them!

And if "Mute audio sources" is UN-checked, then Audacity still gets the *hijacked* signal, and it it also passed along to macOS and your hardware, so that you can hear what Audacity is capturing!





It should be noted that the moment the application which is requesting the signal from Loopback stops recording, Loopback flips the "switch" back to where it is receiving signal from Firefox, HOWEVER, it is immediately passing it along to macOS and your hardware.

(So, stopping recording in Audacity yields the same effect as unchecking "Mute audio sources"...)

Whether Loopback "interrogates" that incoming signal, or simply passes it along to macO and your hardware is a function of whether Loopback determines if another application is requesting the signal it has "hijacked*.


I believe what I just described is consistent with what you said above...

How does that sound?

However, there is also yet *one more* monitor pathway - Audacity is receiving audio from Loopback, but it itself probably has the system output set as it's output. If Audacity is set to monitor sources, then it will pass incoming audio through to it's output so you can hear it.

Audacity has a "Playback Device" but not a "Monitoring Device".

So, yes, if I have...

System Preferences > Sound > Output > USB Headset

Audacity > Preferences > Playback Device > Built-in Output


Then in Loopback, if "Mute audio sources" is unchecked, I will hear the stream in my USB Headset on real-time.

Later, if I want to go back and listen to the recroded stream in Audacity, then I will hear it on my laptop's speakers - and NOT my USB headset - as that is how Audacity is set up.

This is why your monitoring options are useful, as it's all to easy to, for example, have Loopback passing your audio to the system output, and also have Audacity passing a copy of it to the system output, leading to not so nice results.

I suppose that could happen when you playback your audio in Audacity, yes.

I'd suggest the easiest way to proceed is to leave "Mute Audio Sources" checked in Loopback, and monitor via Audacity (but you can if you prefer do it the other way around.)

As mentioned above, you cannot do that.

Audacity only allows you to define a "Playback Device" which cannot be used to listen as you actually record things.

As such, I would need to use one of these approaches...

a.) Mute audio sources > un-checked
Monitor audio through __________ > un-checked

b.) Mute audio sources > checked
Monitor audio through __________ > checked

c.) Mute audio sources > un-checked
Monitor audio through __________ > checked


I tried all 3 options above, and for some strange reason, they all yield acceptable results?! (Maybe because I split the audio source and put Firefox on two channels and my USB Headset on two separate channels that makes a difference?)

If I had to guess, I would think Option-A above is the "cleanest" approach.

What do you think??

Hopefully I'm clear enough in explaining this - but if at any stage you're not sure what I'm saying, just let me know and I'll try to be clearer.

Much better than Rogue Amoeba's support...

Thank God for experts on the Internet like you who are willing to take time to help out a stranger!!

No worries - that's what makes the internet (and this forum in particular) so cool!. We all benefit from learning from others and I'm sure others reading this thread struggling with similar issues will hopefully find something useful too.

Although frustrating in the beginning, I am finding all of this SUPER INTERESTING, and I am eagerly awaiting the day when I have a successful podcast online. (Understanding that great sound engineering is only part of the equation!)

Thanks!!


Audio Jungle

[desmond]

How exactly did you put meters in between these virtual parts?

I think we've got enough to deal with just sticking to the initial tools, rather than adding in other things into the mix.
I have and use many other tools than just the ones we're dealing with here, but they're outside the scope of helping you achieve your aim and might just confuse you more.

[i]Note: The manual explains both these checkboxes in a straightforward enough manner

On what page of the PDF is that?

Audio Sources -> Additional Settings

- I press "Record" in Audacity...
- The music in my headset is shut OFF.
- I can see "signal" being recorded in Audacity, though.

That sounds simply like Audacity is not monitoring the signal, but is behaving exactly as I described the behaviour above.
I haven't checked, but it sounds like when Audacity goes into Record that's when it starts tapping the audio feed, Loopback becomes active, so the Firefox audio is diverted to Audacity, and Loopback no longer sends it to the system output (as Mute Sources is checked.). As Audacity is currently not monitoring audio (ie passing it from input to Output), you aren't hearing it. I would have thought Audacity would do this by default (it's a very standard feature for any DAW), it might be an option, I'll go look later. (Edit: Preferences -> Recording -> Software Playthrough of Input, or Transport -> Transport Options -> Software Playthrough On/Off to turn monitoring on.)

In any case, everything is working as I described above.

- I go to Loopback, and uncheck "Mute audio sources"
- I can now hear the stream again.

You should understand why, now.

If I had to guess, this is how things work...

There's no need to *guess*, I already described the full behaviour above. If you're still not sure about the behaviour yet, it might be worth going back and re-reading it.

When Loopback is out of the equation, then streaming radio from Firefox is passed to macOS and then to your hardware, where you hear it on your defined "Output", e.g. Internal Speakers, Headphones, USB Headset, External Speakers.

Yes.

When a virtual device is created in Loopback and turned on, Loopback *inserts* itself between any applications (e.g. Firefox) and macOS and your hardware.

By that, If you mean with no sources defined, and nothing routed to it - just a virtual device is created, then No: Loopback just gets added as a new audio device, and appears as an Input and Output option in all audio device choosers. It's the same as plugging in an audio interface, it's just there, if you choose to use it. It's not inserting anything between anything, it's simply a new audio device that gets announced to the system and because available to use should you choose to do something with it.

Or if you mean a virtual device is created *with* eg Firefox as a source, then kind of yes. Again, I described the exact behaviour in detail in the previous post.

As such, signal is NOT going directly from Firefox to macOS and your hardware anymore.

Yes, with a hijacked source, the audio is routed by Loopback according to how you set it up.

If the application defined in "Audio Sources" is NOT actively pulling the *hijacked* signal from Loopback's virtual device, then Loopback presumably passes along the signal from Firefox to macOS and your hardware.

You've lost me. The application defined as a source is not "pulling" any signal from Loopback (ie listening to the audio from Loopback). The application defined as a source (ie, Firefox), is *outputting* audio to Loopback. It's not receiving any audio at all.

I don't want to have to keep retyping the behaviour in multiple posts - again, if you're not sure, re-read the behaviour I described above.

However, if the application defined in "Audio Sources" is ACTIVELY pulling the *hijacked* signal from Loopback's virtual device, then a few things happen...

Either you're confused, or your terminology is wrong here. Remember, hijacking means diverting the *output* of your source application *to* Loopback.

It should be noted that the moment the application which is requesting the signal from Loopback stops recording, Loopback flips the "switch" back to where it is receiving signal from Firefox, HOWEVER, it is immediately passing it along to macOS and your hardware.

That looks like the way Audacity is behaving, from your description, but as yet, I haven't verified it (I personally can't stand Audacity....)

Whether Loopback "interrogates" that incoming signal, or simply passes it along to macO and your hardware is a function of whether Loopback determines if another application is requesting the signal it has "hijacked*.

Yes, pretty much. Again, explained above.

Audacity has a "Playback Device" but not a "Monitoring Device".

The playback device is where Audacity plays audio to.

"Monitoring" simply means when recording, Audacity send audio it's recording back out to it's playback device. This is a standard feature on basically any recording device, and is usually an on/off setting. I'm sure Audacity will have this option somewhere. Edit: Added this info above/below.

Then in Loopback, if "Mute audio sources" is unchecked, I will hear the stream in my USB Headset on real-time.

Yes, as things currently are. Or, like I say above, you can monitor through Audacity and not need to monitor via Loopback. It's your choice.

Later, if I want to go back and listen to the recroded stream in Audacity, then I will hear it on my laptop's speakers - and NOT my USB headset - as that is how Audacity is set up.

All this routing is up to you - if you always want to hear everything on your headset headphones, then set your system output to the headset, and set Audacity to output to your headset. If the headset is your primary monitor choice, then that's where you want to hear stuff.

I'd suggest the easiest way to proceed is to leave "Mute Audio Sources" checked in Loopback, and monitor via Audacity (but you can if you prefer do it the other way around.)

As mentioned above, you cannot do that.

Of course you can. I'm not going to suggest things that don't work
Only because you currently aren't monitoring through Audacity by default (again, I don't know what exact state you various software is on your computer at the time of posting.) I assumed it would monitor by default, but in your case it's not, so like I've said, you can continue to monitor via Loopback, or set Audacity to monitor. One or the other (but not both) is equally fine.

Audacity only allows you to define a "Playback Device" which cannot be used to listen as you actually record things.

Of course it can - don't *guess* based on nothing more than sound engineering inexperience!
I looked - the setting you want is Preferences -> Recording -> Software Playthrough of Input, or Transport -> Transport Options -> Software Playthrough On/Off (it's the same setting). When checked, Audacity should send the recordings to it's output while recording.

Much better than Rogue Amoeba's support...

If you were expecting their support to do this with you, then no wonder you were disappointed - no software support would do this, it's *wayy* beyond software support remit to help you plan and config complex needs across multiple applications and requirements and teach you how to use it. It's like buying a car, then phoning up the dealer expecting them to teach you how to drive!!

Support will help you with installation problems, clarify how a feature works, or suggest some use cases, but they are not obliged to plan your podcast recording setup for you!

So, we have pretty much covered all the behaviour of all components in your system, you now have all the pieces you need, and you know how to config everything so it works for you - anything else is just repeating myself. If you are unsure, go back over what's been written here, and try the behaviour for yourself to verify it if necessary.

Look forward to the first podcast...

[audio_jungle]

Desmond,

Seems I have worn you out!

How exactly did you put meters in between these virtual parts?

I think we've got enough to deal with just sticking to the initial tools, rather than adding in other things into the mix.

I have and use many other tools than just the ones we're dealing with here, but they're outside the scope of helping you achieve your aim and might just confuse you more.

Maybe later on as I advance...

- I press "Record" in Audacity...
- The music in my headset is shut OFF.
- I can see "signal" being recorded in Audacity, though.

That sounds simply like Audacity is not monitoring the signal, but is behaving exactly as I described the behaviour above.

Right.

In any case, everything is working as I described above.

Yes.

If I had to guess, this is how things work...

There's no need to *guess*, I already described the full behaviour above. If you're still not sure about the behaviour yet, it might be worth going back and re-reading it.

You said you weren't sure how Loopback was programmed.

What I was trying to say below, but mangled up was this...

It appears that when you create a virtual Loopback device, define an audio source in Loopback and then another application defines the virtual Loopback device as its "input" and then that application (e.g. Audacity) starts pulling data, then it appears as if Loopback stops routing audio to macOS and your hardware and starts routing it to the application using the virtual Loopback device.

I say "it appears" because Loopback is a "black box".

(In the above scenario, it is also possible that when the virtual Loopback device is not in use, that audio from applications like Firefox is just following its normal path and going directly to macOS and your hardware.)

However, my suspicion, is that once a virtual Loopback device is created with sources, that it reaches up and starts grabbing audio from the applications in its "audio sources" but lets that audio pass-through to macOS and the hardware until some other application starts requesting/pulling audio, and then Loopback flips an internal switch and the audio flows directly to the application (e.g. Audacity).

If you have "Mute audio sources" turned OFF, then Loopback ALSO routes data to macOS and the hardware, but the point I failed to make earlier is that it seems in either scenario that audio is flowing through Loopback and Loopback is the one doing the routing.

Not sure if that makes more sense?

And I am not sure if my suspicions are correct, but just trying to thing outside of the box and figure of how this "black box" works.

Enough on all of that!

Whether Loopback "interrogates" that incoming signal, or simply passes it along to macO and your hardware is a function of whether Loopback determines if another application is requesting the signal it has "hijacked*.

Yes, pretty much. Again, explained above.

Okay.

Of course it can - don't *guess* based on nothing more than sound engineering inexperience!

I looked - the setting you want is Preferences -> Recording -> Software Playthrough of Input, or Transport -> Transport Options -> Software Playthrough On/Off (it's the same setting). When checked, Audacity should send the recordings to it's output while recording.

When I choose "Software Playthrough" it froze up Audacity, and I had to do a "Force Quit"?!

I tried again and checked "Software Playthrough". Then I opened up a new project, started recording with Loopback's "Mute audio sources" checked.

When I hit "Record", I could no longer hear the audio as before. So it appears that option in Audacity doesn't do what you expected.

In addition, when that option was checked, if I spoke into my headset as music played, I got feedback like before you helped me properly set things up.

Looks like that is not a path I want to go down...

If I am recording from Firefox and my USB headset, if there any problem having "Mute audio sources" UNCHECKED so that I can monitor my recording as it happens?

That doesn't seem to cause any issues, although you recommend leaving it checked.

If you were expecting their support to do this with you, then no wonder you were disappointed - no software support would do this, it's *wayy* beyond software support remit to help you plan and config complex needs across multiple applications and requirements and teach you how to use it. It's like buying a car, then phoning up the dealer expecting them to teach you how to drive!!

You weren't in the email exchanges.

I gave an enormous amount of bakground details, and asked very specific questions, and the responses I got implied that the person either didn't know the answers or didn't care.

And, yes, I do expect companies to create documentation that your grandmother could read and understand the first time. (It all comes down to pride in work...)

Guess we can agree to disagree on this point.

Look forward to the first podcast...

If I ever make it there in one piece?! (And if I don't piss off my new audio mentor!!)

Sincerely,


Audio Jungle

[desmond]

You said you weren't sure how Loopback was programmed.

Just in regards to that one behaviour, before Loopback is "in use", but it makes no difference exactly what's going on and is therefore inconsequential to anything, I just mentioned it for completeness.

It appears that when you create a virtual Loopback device, define an audio source in Loopback and then another application defines the virtual Loopback device as its "input" and then that application (e.g. Audacity) starts pulling data, then it appears as if Loopback stops routing audio to macOS and your hardware and starts routing it to the application using the virtual Loopback device.

Yes, as I explained above. This is Loopback "in use" as referenced in the manual.

(In the above scenario, it is also possible that when the virtual Loopback device is not in use, that audio from applications like Firefox is just following its normal path and going directly to macOS and your hardware.)

Yes. Like I say, when not in use, it doesn't matter whether Loopback is doing anything or not, all regular apps are just being output to the system as normal - whether Loopback is doing that or not makes no practical difference.

However, my suspicion, is that once a virtual Loopback device is created with sources, that it reaches up and starts grabbing audio from the applications in its "audio sources" but lets that audio pass-through to macOS and the hardware until some other application starts requesting/pulling audio, and then Loopback flips an internal switch and the audio flows directly to the application (e.g. Audacity).

Yes, that may be exactly how it's programmed. Or not - like I say, it's an implementation detail that makes no practical difference. It's the "in use" bit where the behaviour is important.

When I choose "Software Playthrough" it froze up Audacity, and I had to do a "Force Quit"?!

Difficult to help with Audacity, as I think it's terrible software anyway
It doesn't freeze Audacity here.

When I hit "Record", I could no longer hear the audio as before. So it appears that option in Audacity doesn't do what you expected.

I'll have a look later. I read the docs, it should do what it promises to do, it's the whole point of that feature, and is a standard feature on all DAWs.

In addition, when that option was checked, if I spoke into my headset as music played, I got feedback like before you helped me properly set things up.

If you're getting feedback, this only happen when something from an output is fed back into it's input. Given a correctly configured Loopback system, this is not happening via Loopback, which suggests that maybe your headset is very poor, and audio from the headset headphones is coming back into the headset mic. The only real solution, short of turning the volume down, is to use something else, a better headset, or a proper mic and headphones.

If I am recording from Firefox and my USB headset, if there any problem having "Mute audio sources" UNCHECKED so that I can monitor my recording as it happens?

This is fine. As stated above, how you choose to monitor is up to you. If you don't wish to use (or can't use) Audacity to monitor, then use Loopback in that manner. I thought I had made that point fairly clear. All I said was to be sure not to do *both* at the same time.

That doesn't seem to cause any issues, although you recommend leaving it checked.

Recommended because I would be monitoring through my DAW/recorder, but as this seems to be giving you problems, so do it the other way. It's fine, as already said, do it whichever way makes sense for you. Now you have an understanding of what these features do, you can make informed decisions about how to use them.

And, yes, I do expect companies to create documentation that your grandmother could read and understand the first time. (It all comes down to pride in work...)

I'm not doubting your experience, I just have a hard time associating some of your comments with Rogue Ameoba, who are one of the high end of Mac software utility/app developers who do work really hard and really care, and have been making excellent software for many years, and who I've had some relationship with for a long time.

Their documentation is also really accessible and nicely written, compared to the vast majority of software. There is a four step Quick Start, and a full manual, which is really nicely written, and *should* give you everything you need to make Loopback work, but is not a general tutorial on everything audio and people can often have complex system requirements which require some system design and troubleshooting that is well outside the scope of a tutorial/ reference manual. Obviously it's not working for you for some reason, but everyone is different, and it's hard to please everyone 100%.

Damn, my tea's one cold *again*...

[Hugh Robjohns]

Absolutely epic support going on there Desmond. This is what makes the SOS forums such a special place.

H

[desmond]

Thanks Hugh!

So it appears that option in Audacity doesn't do what you expected.

I just tried here, and that option does *exactly* what I expected.

I sent an audio source with no other monitoring to Audacity. With Software Playthrough off, Audacity does no input monitoring - ie, it doesn't send it's input (what it's recording) to it's output - result: good recording, but no monitoring of the audio while recording.

I then turned Software Playthrough on, and hit record again, and now, Audacity sends it's recording input to it's output, meaning I could hear what I was recording from Audacity's output.

Also: if you click the input monitor where it says "Click to start monitoring", it will respect the Software Playthrough status even when not in record mode - ie, with Audacity stopped, if you "click to start monitoring", with Software Playthrough off, you'll see meters for the Input but hear nothing, and when Software Playthrough is on, and you click to start monitoring", you'll se meters for both input and output and you'll hear Audacity monitoring the input at it's output.

Here's a visual example:
https://www.dropbox.com/s/xy58quik1e2ydy9/monitoring.mp4?dl=0

I have Quicktime hijacked to the Loopback bus. You can see when I play Quicktime, we get audio on the Loopback bus as shown in the top line of Audio Hijack.

In Audacity, with playthrough off, when we click input monitoring, and play in audio from the Loopback device, we see input levels, but we get no output (the output of Audacity is in the bottom line of Audio Hijack).

When I turn on playthrough, now when we click input monitoring, we see both input *and* output levels in Audacity, and you can see Audacity is now outputting audio.

[audio_jungle]

:clap: Absolutely epic support going on there Desmond. This is what makes the SOS forums such a special place.

H

Yes, I am very indebted to Desmond for all of his patience and willingness to share his expertise.

Thank you for helping a newbie has an outside shot at succeeding in this new realm!!

[audio_jungle]

Thanks Hugh!

So it appears that option in Audacity doesn't do what you expected.

I just tried here, and that option does *exactly* what I expected.

But it doesn't work for me...






I am running Audacity v2.2.2 and macOS Sierra...

Sincerely,


Audio Jungle

[desmond]

But it doesn't work for me...

The *feature* is working fine in Audacity, it's the overall behaviour of all the other components that aren't doing what you want yet. You have to break down and isolate things to troubleshoot.

You've already said that if you don't monitor in Audacity, and monitor via Loopback, everything works as you need. So why not stop there? - it's working how you like.

We can go on to troubleshoot this alternative way of using the system (monitoring through Audacity) but if you already have a config that is working, it's just a waste of time.

In this monitoring via Audacity case, the problem seems to be that really you always want to monitor back to your headset, which is a combined mic+headphones device, and one that you have *already captured* in Loopback - so you're outputting back to a device already captured by Loopback.

So, it seems wise to just monitor via Loopback, in the way you already have working.

[desmond]

So I tried again to more closely simulate your config there and observe the behaviour:-

- Loopback, hijacking both Quicktime Player (playing audio), *and* my audio interface (which you can both record from/input and monitor from/output) as simulating your USB headset (which is your audio interface really.) Headphones connected to that. Mute sources On in Loopback as I'm monitoring through Audacity.

- System output set to my audio interface too.

- Audacity, set to record from Loopback (3 channels, 1 stereo, 1 mono, manual channel config in Loopback), and output back to my audio interface. Playthrough On.

- Begin playback from Quicktime. The audio is passed to the system, and I hear it from my headphones via the audio interface.

- Hit record in Audacity. There is a brief audio interruption (maybe 1/10th second) as Loopback enables itself. It mutes the audio being sent from Quicktime to the system (as Mute sources is On), and instead passes it through to Loopback, and hence to Audacity, where it's being recorded.

- Audacity has playthrough on, so is monitoring it's incoming audio and sending it back to it's own output, which is set to go to my audio interface. I hear it fine via Audacity. I'm recording three tracks, the first two the stereo audio, the third the mono input from the audio interface (ie your mic). All recorded fine.

So there is no inherent problem in playing back to a device already hijacked in Audacity, as inputs and outputs are treated separately (which makes sense.) I just wanted to confirm that and rule it out as a possible problem.

Everything about this config is working fine, and should be for you too as it's essentially the same thing, unless you are doing something incorrect or have some settings affecting the behaviour that hasn't been mentioned, or the drivers of your headset mic thing are causing problems or something. Unfortunately I can't sit in front of your computer and see what you are doing, so it's impossible to guess.

*In any case*, you have got to a set up that works for you, as far as I can see, by not monitoring from Audacity and intead using Loopback's monitoring, so as I say, stick to what works...

Things I have learnt from this exercise:

- Loopback is really great, and streamlines some otherwise complicated workflows. If/When I need it I'll get it for sure

- Audio Hijack is still great and covers much of the use case of Loopback for my needs. It's much simpler to use in this case as you can see the visual connections, see audio flowing along them, and has inbuilt recorder functionality so one app does the routing, hijacking, and recording, rather than passing things around between the system and other applications. The only thing Loopback can do that AH can't is pass audio to other applications (but I can do that with Soundflower if required.).

This is the exact same config as above, all done in one app:



Mic being recorded to one mono aiff file, stereo audio being recorded to a separate one. We could also record a third mix file of both, if required, in realtime. And avoids the need to use Audacity.

- I still feel the same way about Audacity as I did when I started.

[audio_jungle]

But it doesn't work for me...

The *feature* is working fine in Audacity, it's the overall behaviour of all the other components that aren't doing what you want yet. You have to break down and isolate things to troubleshoot.

You've already said that if you don't monitor in Audacity, and monitor via Loopback, everything works as you need. So why not stop there? - it's working how you like.

That is fine with me.

SInce you said you were able to get it working, I was just trying to figure out what I was doing wrong.

But I have bigger audio problems to tackle right now, so I can certainly "monitor" using Loopback.

We can go on to troubleshoot this alternative way of using the system (monitoring through Audacity) but if you already have a config that is working, it's just a waste of time.

For now, yes it probably is.

In this monitoring via Audacity case, the problem seems to be that really you always want to monitor back to your headset, which is a combined mic+headphones device, and one that you have *already captured* in Loopback - so you're outputting back to a device already captured by Loopback.

So, it seems wise to just monitor via Loopback, in the way you already have working.

Good point.

Thanks,


Audio Jungle

[audio_jungle]

So I tried again to more closely simulate your config there and observe the behaviour:-

Since your dedication and persistence with sound (and patience with me) impress me, I will try and mimic what you describe below maybe this weekend.

BTW, I hope to pick up a boom arm for my pro gear on Friday, and see if I can set up a semi-pro studio this weekend or when I get to it.

Everything about this config is working fine, and should be for you too as it's essentially the same thing, unless you are doing something incorrect or have some settings affecting the behaviour that hasn't been mentioned, or the drivers of your headset mic thing are causing problems or something. Unfortunately I can't sit in front of your computer and see what you are doing, so it's impossible to guess.

I'll keep tinkering and try to mimic what you can do so easily.

*In any case*, you have got to a set up that works for you, as far as I can see, by not monitoring from Audacity and intead using Loopback's monitoring, so as I say, stick to what works...

I agree.

Things I have learnt from this exercise:

- Loopback is really great, and streamlines some otherwise complicated workflows. If/When I need it I'll get it for sure

- Audio Hijack is still great and covers much of the use case of Loopback for my needs. It's much simpler to use in this case as you can see the visual connections, see audio flowing along them, and has inbuilt recorder functionality so one app does the routing, hijacking, and recording, rather than passing things around between the system and other applications. The only thing Loopback can do that AH can't is pass audio to other applications (but I can do that with Soundflower if required.).

This is the exact same config as above, all done in one app:

The reason I haven't ran to Audio Hijack is I want to understand and master Loopback first.

But I am sure I will buy Audio Hijack soon enough and try to master it as well.

- I still feel the same way about Audacity as I did when I started.

And when the time is right, I will be back here in the SOS forums to learn about switching from Audacity to a true DAW, but one step at a time!

THANK YOU, Desmond, for all of your help so far!!!

Sincerely,


Audio Jungle

[lojeda]

Hi

I've just created an account to see if you guys can help me.

I've read the whole thread and nothing is working for me to capture sound from FireFox (Youtube) and record it on audacity while still listening it.

My settings are as follows

mac output: headphones/internal speakers

loopback: virtual device called "Firefox" with Firefox added as an audio source.
Both, mute audiosources and monitor audio through are unchecked

Audacity: Recording device: Firefox. Playback device: Built in output

I hit the record button and nothing but a flat line. I've made sure nothing was muted, still no luck.

This only happens with Firefox, I have another virtual device with Spotify, same settings and it works like a charm.

The only way it works (which I see it should not be used) is by setting my mac to output to the virtual device "Firefox" If I do this it starts receiving the audio but obviously I can't monitor it even after checking the box "monitor audio through" and select my headphones/speakers.

I'm kind of lost, I don't know any more if I'm missing something, I've tried a lot of combinations with no luck. Any help would be really appreciated.

[desmond]

Is this with Loopback 1 or Loopback 2?

(Loopback has been updated since this thread, the new version has a much more visual flow diagram which should help people visualize the audio flow more easily...)

Edit: Just tried it here, Loopback 2, Audacity, latest Firefox, it works fine for me - set Firefox playing YouTube, created a Loopback device with Firefox as a source, and selected that Firefox loopback device as input into Audacity, turned input monitoring on in Audacity, and it gets audio levels without any problems...