GoXLR-on-Linux / goxlr-utility

An unofficial GoXLR App replacement for Linux, Windows and MacOS
MIT License
670 stars 37 forks source link

Changing Fader via API sets levels to 100% in some cases #108

Closed Slychocobo closed 1 year ago

Slychocobo commented 1 year ago

I've been expermenting with the API and think I have stumpled on some unexpected behaviour, (This is my first bug report so hopefully I can explain this clearly)

If you change the fader assignement via the API to the same input again, AND that input is either LineOut, or Headphones the level is set to 100%.

i.e. If you execute: { \"Command\": [\"xxxxxxxx\", { \"SetFader\": [\"D\", \"Mic\"] } ] }" followed by { \"Command\": [\"xxxxxxxx\", { \"SetFader\": [\"D\", \"Mic\"] } ] }" again, the level is set to 100%

If you execute { \"Command\": [\"xxxxxxxx\", { \"SetFader\": [\"D\", \"Mic\"] } ] }", followed by { \"Command\": [\"xxxxxxxx\", { \"SetFader\": [\"D\", \"Chat\"] } ] }" then { \"Command\": [\"xxxxxxxx\", { \"SetFader\": [\"D\", \"Mic\"] } ] }", the levels will be set to their 'correct' values.

From my testing this affects all 4 faders, Only affects the LineOut & Headphone outputs (I was unable to replicate this with any other input)

And as long as you change the output to anything else inbetween, the bug does not occure.

FrostyCoolSlug commented 1 year ago

This is primarily caused by a bug in the submix firmware, whenever you assign LineOut or Headphones to a fader, it sets the volume to 100%, I've got a lot of small mitigations for this, looks like I missed one :)

FrostyCoolSlug commented 1 year ago

This is mitigated in 0.12.5 (now released), so I'm going to close this issue.