#[SOLVED] (Linux) Mic not working in game

287 messages · Page 1 of 1 (latest)

sacred girder
#

I tried to connect each device individually to my profile and not any of them work for microphone, it works in the web browser and pavucontrol shows it registers and input, how do I solve this? also which device should I connect speciffically to the profile

#

I tried in the nightly and it doesnt let me choose any device except for my mouse and keyboard, Idk if that's relevant

rough field
#

mic input is pretty busted on Linux currently, we haven't gotten around to investigating yet unfortunately

sacred girder
#

okay, thanks

sacred girder
#

[SOLVED] (Linux) Mic not working in game

rough field
sacred girder
#

wait

#

there was a message here saying I should use it on wine

#

that was what worked

#

I think I replied to your message by mistake

#

lmao

rough field
#

ah right, yeah that works for now lol

minor sparrow
woven basin
#

not really solved though, is it? is there something I can do to help solve this for real?

little rampart
#

reworked some of the mic recording stuff today to get around some of the linux limitations

#

try adding your microphone to your profile and seeing if you can hear yourself from the mic monitoring

#

if not send me your log files

steep spearBOT
#

Log files contain debug information that can be helpful for developers when diagnosing problems or bugs.
Each log in the folder is listed with a date. Please send the relevant log, which in many cases will be the most recent one.

Accessing Logs From In-Game

  • Go to YARG's settings menu
  • Click on "All Settings" on the top
  • Scroll down to "File Management" and click it
  • Click on "Open Persistent Data Path"
  • Navigate into the logs folder

Accessing Logs Without the Game

If for whatever reason you cannot open the game, here's how you can access the log folder:

  • Windows: C:\Users\<you>\AppData\LocalLow\YARC\YARG\release\logs
    • You can get here quickly by pressing Windows Key + R then typing in exactly: %userprofile%\AppData\LocalLow\YARC\YARG\release\logs
  • Mac: ~/Library/Application Support/YARC/YARG/release/logs
  • Linux: ~/.config/unity3d/YARC/YARG/release/logs
    (if you're playing on a dev build, it may be in the dev folder instead of the release one)
unreal fog
unreal fog
#

Singstar mics (one through usb and other through 3.5mm jack) also work fine. Using them together is still quite iffy (in general I think, talkies get automatically registered correctly? Might just be me) but for all other intentions they're being picked up and work.
My Focusrite Solo (electric guitar) also works just fine: is being picked up and registers pitches.

#

I did have a pretty high crash rate (about 1/3 chance the game would crash whenever I loaded up a song).
To use a mic through the 3.5mm line in, I had to select the H-D Audio Generic Analogue device. All the other sound devices (Pipewire, H-D Audio Generic Alt Analogue...) couldn't be selected for a profile so should eventually be hidden from the device list, but as far as testing mics in general goes, looking good!

little rampart
# unreal fog I did have a pretty high crash rate (about 1/3 chance the game would crash whene...

Yeah I don't think something is being disposed correctly and its causing crashes. Could you by chance send me your Player.log file the next time it happens?

As for the other audio devices not being selectable, could you send me your regular log files? They're in the logs folder (in the dev folder for this build). It'll be one of them depending on how many times you had to relaunch the game

#

Could you also turn monitoring back on and test to see if you hear any crackling when entering a song?

#

Want to know if that's affecting all Linux users as I didn't experience that on windows

#

Also unfortunately we probably won't be able to hide any unselectable devices from the list because Linux does not report device type information correctly

#

And that's likely the reason they can't be selected, they're a different type of audio device that BASS can't record from or something

#

But there's no way of telling that on Linux because BASS doesn't get type information on Linux unfortunately.

It's the reason why in old YARG builds microphones wouldn't even show up. We had device type filtering enabled (because it works fine on Windows) but on Linux all the device types were one of the filtered out types so it would be empty

#

We had to disable that filtering for devices to show up, and that's why on Linux there's usually a ton of audio devices to choose from

unreal fog
#

This should be my regular Player.log (/home/(...)/.config/unity3d/YARC/YARG/)

📎 Player.log
#

This is the log file where I opened the game, tried 3 songs and on the 3rd song the game crashed at the "Loading song" screen.

📎 2024-05-18.log
unreal fog
unreal fog
little rampart
little rampart
#

Ok I think I know why the game is crashing. Made a Windows standalone build to get the crash myself so I could read the stack trace. Quite a dumb mistake I made lol

unreal fog
#

Yeah, I rechecked and there was indeed no crash indicated in the definitely freshly dumped log, so I was about to report that, lol. Good thing you already found the problem.

little rampart
#

still not sure about the crackling issue. It does not happen on Windows so this will be quite hard to debug

#

It's probably a sample format thing

#

but its weird it only happens when entering a song

#

the crash was caused by me (probably) copy pasting the same code which clears the buffer for the mic recording stream. And you can't clear them in the same way, so it was trying to fill a buffer pointing at an invalid memory address (zero), which causes an access violation and then a crash.

image.png
#

Now it's a bit more involved to clear the buffer used to calculate pitch from but oh well lol

#

and it seems to be working

image.png
unreal fog
# little rampart but its weird it only happens when entering a song

It's not just entering a song though, it persists during the entire song.
It seems to subside a bit if you hold a loud note (there's no room for the crackle to come through I suppose).
I made sure to test with headphones and not through speakers regarding feedback.
Quick test to see if it's different for single track songs.

little rampart
#

yeah what I meant is the crackling only begins once you enter a song

#

I know it persists

unreal fog
#

Doesn't matter whether it's multitrack or single track apparently. The crackling goes away while you're actually holding a note though, so it has to be tied to the actual microphone input (or lack thereof). Sadly I don't have anything else to contribute. I'll check back in whenever there's more Linux testing to be done. Thanks for working on this!

little rampart
#

@unreal fog New build to try. Should fix the crashing. Tried to experiment with disabling effects on the monitoring to see if that can help the crackling but I have no idea because it just doesn't happen on Windows. #yarg-dev message

unreal fog
#

I don't have access to that link.

little rampart
unreal fog
#

Cheers.
Most excellent news: I tried 10 songs and no crashes, but even more excellent is the fact that audio crackle is completely gone. It's outta here.

#

Amazing timing for fixing this btw because I'm having my bros over tomorrow for some Yargin'.

#

I didn't think to mention this earlier, but I remember vocal monitoring in RB3Deluxe (through RPCS3) also would crackle the very same way, so I always had to turn off monitoring completely. I never played with monitoring on before.

little rampart
#

Can I send you another build to test with just the reverb enabled on the monitoring?

#

I think it could be the gain effect

unreal fog
#

Sure, send away

little rampart
#

give me like 5 minutes to build it

#

still confused on why the crackle only happens on linux

#

if this has no crackling, I may just make another build WITH the gain effect as a sanity check to ensure it comes back when I re-enable it

#

because I changed quite a few things in between the original build that fixed the mics and the 2nd one that fixes the crashes

unreal fog
#

Reverb is the one that makes the crackle happen.

#

Or perhaps Gain also does too, but Reverb is now confirmed.

little rampart
#

alright I'll make another one with only gain

#

also just to double check, the crackling only starts to happen once you're playing a song right? In the menus it sounds normal? And the crackling only happens when you're not speaking (someone else encountered this). Speaking/singing into the mic makes it sound normal?

unreal fog
little rampart
#

thats so strange

unreal fog
#

Gain version works fine, very strange.

#

If I had to take a pick, I would've said Gain would've been the likely culprit.

little rampart
#

so just the reverb, which is a BASS effect that we have no control over

#

yeah same

#

why does it not happen on windows

#

😭

#

and why does it only happen when you enter a song!?!?!?!?

#

if it happened all the time then I'd be able to pin it down on just the effect

#

but it only happens in a song

#

and the only difference in what the code is doing when you're in a song is it's placing the mic data into a 2nd stream for the pitch processing

#

and then it does the pitch calculations every 40ms

#

do you mind testing more stuff for me

unreal fog
little rampart
#

ok, I'm going to completely disable pitch processing (so vocals gameplay is not going to function at all)

#

but what I am going to do is keep the data stream for the pitch processing going

#

so its feeding data through that stream and then "fetching" it all every 40ms

#

this will tell me if simply placing this data in the pitch processing stream is affecting something

unreal fog
#

Sidenote: whenever I used to start up RB3Deluxe on RPCS3, there'd always a weird audio crackle over the Milohax and RB3DX intros, I think that may also be a Linux only audio thing.

little rampart
#

probably

#

but this is weirder because its only happening when data is getting placed into the pitch processing channel

#

i.e when you're in a song

unreal fog
little rampart
#

No the pitch processing stream is what BASS calls a "decoding" stream. Data placed into it is never actually heard unless piped through a channel that is a standard stream

#

All that happens in a decoding stream is the data is decoded into audio samples and if you have any FX/volume settings applied then the channel will transform the samples

#

2 streams, the monitoring stream and the "processing" stream

image.png
#

and the only difference between being in the menu vs being in a song is the IsRecordingOutput flag

#

that becomes true in a song, which allows the rest of the code below to run

#

the commented out code at the bottom is the change I'm making and building right now

#

that just disables the pitch algorithm

#

but all the microphone data is still getting placed and then fetched from that processing stream

#

so this will test if simply the act of placing that data in is causing a problem

#

it shouldnt because it should be making a copy

#

but I also have a feeling this could be a timing related thing

#

i.e the pitch processing is too slow and causes crackling because then the monitoring cant keep up or something

#

you obviously wont be able to hit any notes lol

unreal fog
#

Let's see what we might learn here

little rampart
#

its gonna be one of two things: placing the data in the processing stream causes it or the pitch algorithm is slow enough to cause a slowdown and mess up the audio

#

but why only on linux

unreal fog
#

Still crackles

little rampart
#

It's crackling without pitch processing...

#

what the fuck

#

So just placing the data in that stream is causing it (for some reason??)

unreal fog
#

Well, it's still a mystery but at least it's narrowing down a bit.

little rampart
#

I'm out for a bit now so it'll be around an hour and a half before I can make any more builds but yeah we're narrowing down the cause now

unreal fog
#

Yeah, I might get back to ya on it in about 5 hours. Just send whatever to test with instructions included any time and I'll get back to ya whenever I can.

little rampart
#

@unreal fog Hey if you're around, I've made a standalone console application to test the microphone stuff. Copied majority of the code from YARG so it should be the same as YARG. Just easier to send a 5MB console app that takes 10 seconds to build vs a 90MB game that takes 2 minutes to build

📎 MicTest.zip
#

Easy to use, just run it in a terminal. It'll ask what device you want to use, just enter the ID of the device you'd normally pick in YARG and then you should immediately be able to hear yourself

#

Pressing Y will enable the "processing", i.e toggle the flag which starts to place the mic data into the processing buffer. This should start the crackling

#

Press N to disable it

#

Press Enter to exit

paper abyss
#

i just tested it and yes that is what happens

#

as soon as you press y the crackling starts

little rampart
#

@paper abyss able to try this one for me? Change I made in this is I made a copy of the data when pushing it to the pitch processing, just to see if that will do anything...

📎 MicTest_data_copy.zip
paper abyss
#

sorry was away its still does it with the new built

little rampart
#

ok this time I disabled fetching the data from the processing stream, still places data in so we'll know if just placing it in is the cause

📎 MicTest_no_data_fetch.zip
paper abyss
#

that works

little rampart
#

...wha

paper abyss
#

does the nightly have the linux fix now?

alpine grotto
#

Not yet, no

paper abyss
#

ok thanks

unreal fog
little rampart
little rampart
#

But why that causes the monitoring (which is a completely separate stream by the way) to start crackling is beyond me

#

I think I'm going to have to post on the bass forums about this because I don't have a clue lol. It works perfectly on windows but Linux has issues

little rampart
#

@paper abyss @unreal fog can you try this build for me? It contains newer BASS builds from the guy who develops it. He's asked for me to try these in case it has any different results

📎 MicTest_update.zip
#

Also another question, when you aren't speaking, is your microphone completely silent? Or is there some minimal ambient background noise? I won't ask you to try to listen for it with the static stuff, maybe record something brief in OBS or audacity and see if theres just any amount of noise (like computer fans etc)

unreal fog
#

The crackling doesn't start if I'm already holding a note before engaging the processing though.

little rampart
#

does it fade out?

#

then when you stop speaking, does it come back

#

I'm going to quickly send another build where if you press the 'A' key, it will print out the CPU usage by BASS. Can you spam that key when you're silent (so there's lots of static sound) and when you're speaking/holding a note and tell me what the average usage is and if it maybe spikes when you're silent or speaking?

unreal fog
#

The amount of crackling is inversely related to the amount of noise I input into the microphone.
If I sing loudly/my volume setting is set loud, the crackling will instantly disappear, being overtaken by my input.
If I sing quietly/my volume setting is set more quietly, the crackling will still be there, but less so than if I wasn't singing at all.

little rampart
#

alright

unreal fog
little rampart
#

Press the A key after the recording begins to print the cpu usage

#

Y/N does the processing stuff like normal

#

Let me know what the number hovers around if you spam the key, both when singing and when quiet

unreal fog
#

0.081 - 0.083 quiet
0.083 - 0.085 singing

little rampart
#

yeah so no measurable difference really

#

that's pretty much all the info I need for now

little rampart
#

@unreal fog @paper abyss new build to test here. This time it will record all 3 streams to .wav files.

recording.wav is the raw microphone recording.
monitor.wav is the monitoring channel you normally hear in YARG/when testing this application.
processed.wav is the channel used for pitch processing. Will sound lower in quality as there's low and high EQ applied to this channel.

In order for sample data to be written to processed.wav, you'll need to enable the processing by pressing Y (which also normally starts the crackling)

📎 MicTest_write_to_file.zip
#

This isn't intended to fix anything, its just gathering more information

unreal fog
#

Aight, let's go

#

This is quiet (except for a few clicks and a bird squeek). As soon as the recording began (start of monitor.wav) there were already a few crackles, without having started processing. Once processing is initiated, you can hear much more crackling in monitor.wav.
Processed and recording are both entirely clean.

#

Oh yeah, and computer fans in the background I guess.

#

I'll also include this because it's relevant: this is a second test using my Focusrite Solo as recording device playing my guitar through the XLR in and there's NO CRACKLE AT ALL.

little rampart
#

per chance what is the frequency of your focusrite solo?

#

is it 44100 Hz or something else?

#

and whats the frequency of the microphone you were using for these tests?

unreal fog
#

Gotta look into that

little rampart
#

for example on windows I can check like this

image.png
unreal fog
#

117 alsa_output.usb-Focusrite_Scarlett_Solo_USB-00.3.HiFi__hw_USB__sink PipeWire s32le 2ch 48000Hz SUSPENDED
513 alsa_output.usb-RODE_Microphones_RODE_NT-USB-00.analog-stereo PipeWire s16le 2ch 48000HzSUSPENDED

#

Both 48k

little rampart
#

hmm

#

both stereo channel too

unreal fog
#

These latest tests were with my Rode mic, I did do some earlier testing with a Singstar mic as well, but the results were the same.

little rampart
#

and see what that does

unreal fog
#

I'll check it out.

unreal fog
#

I was able to change my default frame rate to 44.1 but there were no real differences. Not sure about being able to do mono.

#

Someone with a bit more knowledge of these things could take a try. For a moment I thought we had a lead because Pipewire (Linux audio system) had 48k as a default and you could add 44.1k as an additional accepted sample rate. To me, this would imply it would always bump it to 48k on the fly if it had to handle 44.1k, but it didn't go anywhere.

gleaming field
unreal fog
little rampart
#

so the PCM sample data from the Focusrite is 32 bit, while the RODE is 16 bit

#

but that makes this more confusing because 16 bit is more common

unreal fog
#

Worth a shot to look into at least.

little rampart
#

@unreal fog @paper abyss Been a bit busy today but I got another reply on the bass forums asking to try some more stuff. This build is pretty much no different except all the channels are using floating point data and I've added the reverb effect to the processed.wav output. Let me know if this changes anything (I'm also not certain if floating point will work on Linux as I think I've had issues with that before, so I added some more error checks)

📎 MicTest_floating_point_processed_reverb.zip
#

Instructions for use are same as last time. Run the program, do some speaking as well as some quiet parts, take a listen (or send if you want, that will help) to the outputted wav files

#

Mostly looking to see if the floating point data makes any difference and if any crackling sounds are present in the processed output since adding the reverb (as we found out that was one of the sources to the problem)

lethal aspen
#

hi Riley, I'm luis-mejia1. glad to be able to help again
I'm using a wii u singparty mic and I don't see/hear any noise in the latest build!
here are my recordings:

little rampart
lethal aspen
#

yes and even when not processing

image.png
paper abyss
unreal fog
little rampart
#

alright thanks for testing that. We're getting close to fixing it but I just want to work out why it was a Linux only problem to begin with, so I'm gonna discuss on the BASS forums a bit more until I get that figured out

unreal fog
#

In general, the Linux platform is still changing up the rudimentaries regarding audio and video.
We're seeing shifts away from X11 and towards Wayland graphically and a consolidation for audio with Pipewire.
I use my Linux rig for music recording and producing and it works well with very low latency, but something as simple as changing the sample rate requires you to look into the right .conf file and change values as opposed to that dropdown menu under sound settings on Windows.
I think it's generally because the Linux platform is only just really coming together on a fundamental level that there hasn't been much time and room to focus working out the many smaller issues that bring unforeseen side effects like this one.
It's the efforts like the one you're making right now that will lead to true parity with Windows.

little rampart
#

@unreal fog @paper abyss if you're still online, could you quickly try this one for me? I took the float stuff off so it should start crackling again, but the reverb is still on the processed.wav channel so I'm checking to see if its the crackling is present there now

📎 MicTest_no_float_reverb_on_pitch.zip
paper abyss
unreal fog
#

Processed is completely clean but monitor has crackling. Same for binarygeek119's samples.
I think these were the test results you were hoping for since it shows reverb isn't the problem itself.

little rampart
#

Hey a little bit late with this one but I was asked to take off all FX on the processing.wav channel (so it should sound exactly the same as recording.wav) for some more testing. Same instructions as the past 20 times by this point! lol. Lets see if the static sounds persist on monitoring

📎 MicTest_no_fx_on_pitch_channel.zip
#

@unreal fog @paper abyss

unreal fog
little rampart
#

Just mentioning that I haven't forgotten about this. Just waiting for a reply on the bass forums and as its a weekend I have to wait

#

and I likely wont get one on monday either as its a bank holiday in the UK and most businesses usually close on those

#

(and the guy who makes bass is from the UK)

#

so I'd expect tuesday to be the next time I get a response, monday if I'm lucky

paper abyss
#

K I won't be round for testing with Linux this week hopefully the other guy will be able to help.

unreal fog
#

Yeah, no prob. I check in from time to time but due to being in Western Europe, my online time hardly ever alligns with Americans.
You can send me a ping any time and I look at it first chance I get.

little rampart
#

@unreal fog @lethal aspen new build to try. This one is the same as the last one except its going to create 2 wav files for the monitoring. One gets the sample data before the reverb is applied, and the other gets it after the reverb is applied.

Check if there's static sounds in monitor-before.wav or monitor-after.wav. If they're in before then we have big issues lol. It will most likely only be in after but lets see

📎 MicTest_2_monitor_files.zip
lethal aspen
#

I get static only in the after file

image.png
unreal fog
#

Can confirm, only monitor-after.wav has crackling. Monitor-before is clean.

gloomy plume
#

Hey, came across the same issue. Has mic functionality been fixed? Or it there a way to fix it? Kinda confused by all the files XD

lethal aspen
#

it's not fixed yet, but Riley is working on it 🥹

#

the workaround is running the windows version through wine/proton

little rampart
#

@lethal aspen @unreal fog 2 new builds to try here. Let me know what happens with each (still focusing on what occurs with the monitoring channel).

In the first one, no data will be in the processed.wav file because I've intentionally broken it to see if it "fixes" the monitoring.

In the second one, the monitoring will sound weird because I put a chorus effect on it instead of reverb. Looking to see if that eliminates the static and it potentially being the reverb effect itself

#

forgot to do this yesterday so missed out on 1 extra reply on the bass forums so its delayed things a little more but I think we're getting close to the root cause of all this (at least in terms of BASS, I'm thinking it may be looking like a bug in the library at this point)

lethal aspen
little rampart
#

hmm the first result is very weird

unreal fog
#

Get Invalid Handle - Static before and after processing in monitor-after. It feels to me like the rate of crackling is lower than average though, probably unrelated.
Chorus On Monitor - monitor-after is indeed clean, like Luca said.

paper abyss
#

hey heads up i will be back home tomorrow so i can test again.

little rampart
#

i did it wrong

paper abyss
unreal fog
#

MicTest Float DSP - monitor-after has some reverb applied I think, but after I initiate the Processing (around 0:07) it sounds pretty bad, but it's not crackling, it's something else

#

MicTest Null Buffer - monitor-after has some slight crackling (below average amount)

#

MicTest Default Reverb Rebuild - monitor-after has the usual results: audio crackling before processing and some pretty intense crackling after processing is engaged.
Also, I don't know what's up with the loud bang when I start my recordings, maybe it's some leftover from the pipewire stuff I tried, but everything else seems normal.

#

Also, whenever I try to exit the MicTest by hitting the Enter key, it gives me this error

Freeing BASS resources...
Error pushing data to monitor stream: Handle

Don't know if that's just me. Might point to data being pushed to monitor stream is handled differently between Windows and Linux? I'm assuming Enter to exit does just work for Riley.

#

It always gave that error but I didn't pay it much mind, I just closed the terminal instead.

little rampart
#

means nothing

unreal fog
#

Thought so.

little rampart
#

another build here @unreal fog @paper abyss. Don't need the audio files just let me know if the problem occurs on monitor-after and under what conditions if applicable

📎 MicTest_no_data_call.zip
paper abyss
#

there like a pop every 1 second with any mode

unreal fog
#

MicTest No Data Call - only monitor-after has crackling both before and after engaging processing, at the same below average rate both before and after engaging processing.

#

Also, I got rid of the explosion sound at the start of my recordings by removing the 44100 rate from my pipewire.conf configuration file.
It's supposed to allow for both 44100 and 48000 sample rates when necessary, but I noticed a lot of that explosion kind popping in audio matters.
This isn't directly relevant but it shows the delicate nature of the audio system in my opinion, we're a long way from robust and time-tested.

little rampart
#

@unreal fog @paper abyss can you try this one for me. I made a new project and stripped everything that wasnt necessary out to try and narrow things down more

📎 mintest.zip
paper abyss
#

This is no longer a issue for me my SSD crapped out so had to get a new one and I went with windows this time I just ponyed up for the license key so I'm not longer able to test, sorry.

unreal fog
#

No prob, I'll be testing shortly.

unreal fog
#

MinTest has no popping at all.

little rampart
unreal fog
#

MicTest is completely squeaky clean

#

So is MinTest 2

#

No crackling whatsoever anywhere.

#

This was with my Rode mic though, the Singstar mic is still lightly crackling. Testing some more.

#

MicTest - Singstar mic through line input at the front of pc has 1 slight crackle every few seconds or so without processing turned off, and 1 crackle every second or so with processing turned on.
Singstar mic through the usb connector (that comes with the mics) has the same results as through line input.

MinTest 2 - Singstar mic through line input is clean, Singstar mic through usb connector is also clean

#

So, to generally recap:
The crackling used to be unbearable in the first MicTest game builds with monitor on.
We're now down to a new MicTest which I found to be 10/10 clean with my Rode mic, but with my Singstar mic, I'd rate it about 7-8/10: mildly annoying crackle of low-medium volume, but way better than it was before.

little rampart
little rampart
#

So its down to mic differences now

unreal fog
#

MicTest clean across the board with Rode and Singstar USB, MinimalTest too.

#

Singstar through line input also completely clean!

little rampart
#

hang fire I am cooking a new build

unreal fog
#

MicTest with no processing is fine, with processing has very intense crackling (like in the very beginning of testing).
MinimalTest also has very intense crackling.

little rampart
#

good

#

basically confirms which part is the problem then

#

off to the bass forums i go donkRun

little rampart
#

Looks like it was a bug in bass_fx and this should fix it

#

replace it for both programs and observe the result

unreal fog
#

Tested in the last versions you had sent me:
MicTest (x86_64 libbas_fx.so fix) - the monitoring at the moment of recording and monitor-after have a little bit of audio crackling, but only when I'm speaking into the mic, no crackling when I'm not. I'd rate this signal 9/10, extremely minor annoyance crackle.
MinimalTest (x86_64 libbas_fx.so fix) - very loud electrical signal, unlike any I've heard in testing up til this point, solid 1/10 signal, headache-inducing and can barely hear myself

little rampart
unreal fog
#

Only did the very last set (3rd set of that day). I still have the others labeled as "16-06 1st" and "16-06 2nd".
I'll do those too.

little rampart
#

only interested in the latest build

unreal fog
#

Throwing the libbass_fx at those latest versions (3rd builds from the 16th) improved them, but not up to par with the penultimate versions (the 2nd builds from the 16th). I assume the 2nd builds were made without the component we're currently troubleshooting.
The libbass_fx replacement was a definite improvement but still not completely right.
Added the monitor-after from the latest iteration with the libbass_fx replaced for context.

#

Also be careful with volume in regards to that file, opens with a loud pop, as all monitor-after's of mine do (for some reason).

little rampart
unreal fog
#

Still has that very harsh electrical crackle. I made a recording of the monitoring for you to hear (volume warning due to popping).

little rampart
unreal fog
#

As you can hear, the monitoring.wav is completely fine (it even lacks that exploding pop that used to be present in my monitor-after) and has no crackling at all.
The direct monitoring while recording still has that same electrical crackle I mentioned in the previous test.

#

What the hell?
I play the monitoring.wav using MPV, it's good.
I play the monitoring.wav using VLC, it's good.
I play the monitoring.wav I just upped to Discord, in Discord and there's the electrical crackle.

#

Now I downloaded the monitoring.wav I had upped to Discord, and it plays fine locally??? What in tarnation.

unreal fog
#

Is there some kind of parallel we can draw between the way Discord plays sound files and the way Yarg monitoring works?

#

Reading up on some audio stuff related to audio crackling in Discord.

image.png
little rampart
unreal fog
little rampart
#

@unreal fog

unreal fog
#

Not at home right now but will try ASAP in an hour or so.

unreal fog
#

Seems to work perfectly.
-I tried it in a random song with vocal monitoring turned up high with headphones on and it was perfectly fine
-I tried it with all tracks turned down to 0.10 and vocal monitoring full blast, could hear myself perfectly fine with no crackling or whatever
-I also tried it with everything turned down on my loudspeakers, which also worked perfectly fine (kind of surprising to me), only got feedback when I pointed the SingStar mic directly at the loudspeakers (which obviously causes feedback loop)

Big W

little rampart
#

very awesome

#

just going to wait to see if a couple more people report back before merging this in to nightly

#

if everythings good then this year long issue is finally solved