About software, technology and random things


Fixing Low Stereo Out Sound Volume For the Yamaha MG12XU / MG16XU / MG20XU Audio Mixer


I recently got my hands on a Yamaha MG12XU audio mixer and dove right into the world of amateur analog audio mixing.

Everything went fine until it came to the USB interface. When trying to record the sound that was output via USB to my computer (basically STEREO OUT without the master stereo fader), it did arrive, but the volume was really, really low. Audacity barely showed any change in the graphs displaying the signal volume (went from a one pixel thick line to an occasionally 2-3 pixel thick line).

Additionally, the audio that went into the mixer via USB (channel 11/12 on the MG12XU) was considerably louder than all my other channels. In fact, if I used the USB attenuator function (press the PROGRAM dial/button 5x, turn the dial to adjust between -24 to 0 dB and confirm by pressing it once more) to set it to -24 dB, the lowest setting, only then was it as loud as all my other channels. That should have been the first indication as to what was wrong.

This was after installing the YAMAHA Steinberg USB driver from the official Yamaha Professional Audio website, which I strongly recommend. The default one that Windows 10 installed when it first detected the mixer somehow resulted in CPU usage skyrocketting due to svchost.exe. Not sure what that was about.

I tried installing the ASIO4ALL driver, but it didn't appear to make any difference, so I called the technical support hotline.

The very friendly and competent person on the other end explained to me that the signal strength the mixer was working with from the input all the way to STEREO OUT was simply too low. I had intentionally kept everything just as low as I could with the channel sliders on the 0 positions because I didn't want the gain settings to distort my signals. Turns out that mixers work best with the highest volume levels possible without distortion or constant peaking which does make sense - if you have more data for the signals, you can do more with them in terms of EQ, FX or anything really. Another clue was the monitor level display on the right side. For normal signals it only went up to a strength of about -25 to -30, which is basically the two bottom indicators of a total of twelve. They should be around the 0 level (5th from the top).

Once I realized that, it was only a matter of increasing the gain levels for the different input channels and lowering the master stereo slider as well as the phones level knob (and the AUX1 level knob in the SEND MASTER section) accordingly because the signal was now very strong. The monitor level now usually filled up to the 4-6 bottom-most lights (-15 to -6).

One test recording confirmed that the STEREO OUT USB signal was now as loud as what I heard on my headphones.

This was loud enough for me (the phones dial being set to 1 / the first "notch"), and translated to a gain level at 8 out of 10 "notches" (3 o'clock position) for all my sound cards (which were set to 100% volume in Windows for input as well as output) as well as my XLR microphone. Luckily, at this point there was no noticeable distortion yet.

Oh, and the volume in the USB input (channel 11/12) was now as loud as the other ones even without any attenuation set.

That's it!

I hope that helps you.

PS: Sorry if that is a bit of an obvious "hint", but as a beginner in the audio space myself, the advice from the Yamaha customer service representative made a light bulb switch on in my head. I thought I would share it in case you are having the same experience.

PPS: Even though I can only speak of the MG12XU, I am pretty certain that this applies to the sister models MG16XU and MG20XU, too, and maybe even the entire range of Yamaha audio mixers.


Memory Leaks / Problems with Long-Running Symfony / Doctrine Console Applications


I recently built several console applications that have to keep running as daemons as part of a more complex website. As soon as I added Doctrine for its highly comfortable ORM functionality, I noticed a significant increase in the applications' memory usage, which made sense because it would load Doctrine's code in order to use it. The worst part of it, however, was that the processes kept eating up more and more memory the longer they ran and with each Doctrine query they executed. Finally the processes ended up being killed by Linux's OOM Killer due to the high amount of memory that they wanted allocated for them.

Clearing the Doctrine Entity Manager ($entityManager->clear()) and triggering PHP's garbage collection manually did not help at all. So I assumed it had something to do with the data that Doctrine accumulates in the background.

During my research I finally stumbled upon this Stack Overflow question: Memory leaks Symfony2 Doctrine2 / exceed memory limit

Apparently, Doctrine uses an SQL Logger to log each and every query it uses when running in debug mode.

Due to the nature of Symfony console applications starting up in the dev environment by default when launching them from the command line, it also kept enabling the debug mode. That in turn enabled the SQL Logger which gathered more and more data and kept it in memory.

I decided to launch the processes by simply manually disabling the debug flag. Using the dev environment is not a problem for me, so I just did the following:

$ php app/console custom:command --no-debug

You could also set the environment variable SYMFONY_DEBUG to 0 before launching the command without the --no-debug flag, as it also respects its value - refer to app/console's source code.

Alternatively, you could start it in a non-dev environment:

$ php app/console custom:command --env=prod


$ php app/console custom:command -e prod

or just set the environment variable SYMFONY_ENV before launching it.

This way, the SQL Logger is not enabled.

My processes have been running at stable memory usage size ever since.

Another way would be to deactivate the SQL Logger in the code by principle, but that would be defeating the purpose of the nice built-in features of enabling/disabling the debugging mode, so I rather chose the first path. It might come in handy sooner or later after all, and reverting those changes just to re-enable the SQL Logger would be an unnecessary pain.

I hope this was helpful to you. It certainly took me some time to get behind it.

%d bloggers like this: