right ear (master channel mono) gain controlled by master gain rather than headphone gain in split cue mode

Bug #1458213 reported by Be
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
Low
Be

Bug Description

In split cue mode, the gain of the master channel in the right ear is controlled by the master gain control. To reduce the volume of the right ear to a reasonable level for my headphones, I'd have to turn the master output way down. Instead, both the left ear (PFL channel in mono) and right ear (master channel in mono) should be controlled by the headphone gain in split cue mode (with the master output independently controlled by the master gain control).

Tags: easy
Revision history for this message
Daniel Schürmann (daschuer) wrote :

This issue is somehow complicated, because strictly spoken you misuse the gain knobs as volume knob.

However you use case is valid and it is a common problem that user do it like that and than complaining about the bad sound of Mixxx.

It looks like there is an issue in our singnal path. How should the ideal case look like? Do we actually need a independent headphone gain?

The master gain should be used to make most of the sound card resolution and / or level the output stream for recording and broadcasting to a desired loudness of recommended -16 LUFS.

The sound system volume should be levelled by the hardware faders inside the sound card, by an external hardware fader or by the volume knob of the amp itself. Using the gain knobs works, but they act like a bit crusher effect.

Changed in mixxx:
status: New → Confirmed
importance: Undecided → Low
Revision history for this message
Daniel Schürmann (daschuer) wrote :

The issue might be solved for you, if we could access the soundcards microphone slider from Mixxx.
However there are 4 channel soundcards out there with only a single volume control for all four channels.

Related:
https://bugs.launchpad.net/mixxx/+bug/1079896
https://bugs.launchpad.net/mixxx/+bug/1440443
https://bugs.launchpad.net/mixxx/+bug/1440675
https://bugs.launchpad.net/mixxx/+bug/1306253

Revision history for this message
Be (be.ing) wrote :

I use a two output sound card for master output and my onboard sound card for my headphones. So, it is plausible that for this kind of set up, when following the proper method of adjusting the hardware volume controls first, different levels of gain on the master and headphone outputs could be appropriate. In that case, for split cue mode, I would want the right ear at the same gain level as the left ear, so the master channel to the headphones should be under the gain control of the headphones. Also, as you noted in bug 1440443, some 4-output sound cards only have one volume control for all outputs, so an independent headphone gain control is the only way to control headphone output separately from master output.

My proposal for the signal path remains the same as the original description. When in split cue mode, the master channel should be duplicated, with the one going to the actual master output controlled by the master gain and the one going to the headphones controlled together with the PFL channel by the headphone gain.

If many users end up adjusting levels the wrong way, that's a problem with Mixxx's UI and/or documentation. I filed a new bug report for that: bug 1458677.

Revision history for this message
Be (be.ing) wrote :

With split cue mode off, adjusting the headphone gain control adjusts both the PFL and master channels in the headphones. However, adjusting the master gain also affects the headphones. Only the headphone gain should affect the headphone output, regardless of whether split cue mode is on or off.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

currently it looks like that:

channel1 -----\
               --------X -------------X------------------------ Master / Recording / Broadcasting
channel2 -----/ master Gain balance \ \
                                               \ \------ R
                  plf --------------------------X---------X---------- L Headphone
                                              Head Mix Head Split
                                                        Gain

Revision history for this message
Daniel Schürmann (daschuer) wrote :
Revision history for this message
Daniel Schürmann (daschuer) wrote :

I think we can do it better.

* Is balance at the right place, or should it effect the master output only?
* head Gain should be applied after split.

Any other ideas?

Revision history for this message
Be (be.ing) wrote :

I don't think including balance for the right ear in split cue mode makes sense because it's being downmixed to mono.

Revision history for this message
Be (be.ing) wrote :

I don't think it makes sense to adjust headphones for balance in split cue mode because the right ear is being downmixed to mono.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

Yes! Do we need balance for recording and broadcasting.
IMHO the current situation is more a bug than a feature.

See a combined proposal attached.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

Filed an extra bug for the balance issue Bug #1458762

Revision history for this message
Daniel Schürmann (daschuer) wrote :

Since the split cue feature is broken, if you use the master Gain as volume slider we can consider this as a 1.12 bug.

Changed in mixxx:
milestone: none → 1.12.0
tags: added: easy
Revision history for this message
Be (be.ing) wrote :

Fixed in https://github.com/mixxxdj/mixxx/pull/1254 , specifically commit 3be271c.

Changed in mixxx:
status: Confirmed → In Progress
assignee: nobody → Be (be.ing)
Be (be.ing)
Changed in mixxx:
milestone: 2.0.0 → 2.1.0
Be (be.ing)
Changed in mixxx:
status: In Progress → Fix Committed
Changed in mixxx:
status: Fix Committed → Fix Released
Revision history for this message
Swiftb0y (swiftb0y) wrote :

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/8058

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.