QML settings sound hardware

[acolombier]

Partially closes #14542

Current limitation:

• Mono output assignation
• (Likely) Mac Audio API (Core Audio?)

[acolombier]

I have pushed couple of updates, which should behave as shown bellow. I consider this the final version for now, but should like revisit it to add a tutorial/guided screen on first open. The legacy view is also TODO but I'd like to move this on a subsequent PR.

Note that there is some fix-ups to be moved inside #14568 before this can go

Screencast.From.2025-04-06.21-13-22-10MB.mp4

(Windows demo starting at 1:22)

[JoergAtGithub]

Now it's drawn correct. But I noticed, that it's possible to make direct connections from Input to Output, which Mixxx does not support:

[JoergAtGithub]

The Mixer has only the Left Bus, but not Center and Right Bus.

[JoergAtGithub]

The Record/Broadcast has only one Input. This is by default connected to Main output of the Mixer, but can be assigned to an external soundhardware input instead. But the QML GUI allows visually double connections.

[acolombier]

it's possible to make direct connections from Input to Output

I will had further constraints on this

The Mixer has only the Left Bus, but not Center and Right Bus.

Yep, I will add those too

The Record/Broadcast has only one Input

Right, am I understanding correctly that Additional input should actually be Alternative input?

[JoergAtGithub]

The Record/Broadcast has only one Input

Right, am I understanding correctly that Additional input should actually be Alternative input?

There may only be one input for record/broadcast and the input must always be connected to exactly one source. No more and no less. By default a conection from the Main Output of the Mixer to this input shall be established.

[acolombier]

With the latest push, I should have addressed the three point you mentioned (alternative recorder input, no direct input to output mapping missing bus outputs). Please note that the QML pre-commit hooks have yet again screwed up the code base as I was about to push so it might have broken some bits (see #14604) so I have gone ahead and disable it for now.

[JoergAtGithub]

This does not look correct, the Z2 has 8 stereo inputs, but it shows ony 3:

[JoergAtGithub]

The connection after loading Mixxx with the correct setup done in Legacy dialog, looks like this

• Floating connection
• Two outputs with the sam name (Default)

[JoergAtGithub]

There appears no scroll bar, that shows the user, that there are further inputs below:

[JoergAtGithub]

There appears no visual indication of which control is selected, which makes navigation with the keyboard nearly impossible.

[acolombier]

This does not look correct, the Z2 has 8 stereo inputs, but it shows ony 3

There appears no scroll bar, that shows the user, that there are further inputs below:

Not sure, but looks like there may be a a scrolling bar on both components. It currently only renders when activated. Could you confirm this is only related to the scrolling bar display issue? If yes, I'd like to fix that later, in a follow up PR, as this is an issue with Flickable (ListView/ComboBox). Overall, ComboBox and Flicker/scroll indicator design will still need effort and I would like to address it separately.

• Floating connection

Ah, seems like there is still connections missing. Not sure which one would be missing now, so this might need debugging

Two outputs with the sam name (Default)

Default is used if the input has no name. From the legacy view, I suspect the issue is that the channel combobox is not displayed, bug this is the same input

Please note that from a functional perspective, inputs and outputs will duplicate itself upon binding if there is more channel that could be assigned, so in the case of your device, it could be duplicated up to 4 time (4 x 2 channels). This is part of the bits to be covered in the the tutorial/onboarding view, when implemented later, although the visual could be changed slightly? Here is a potential alternative

There appears no visual indication of which control is selected, which makes navigation with the keyboard nearly impossible.

There is no focuscope setup yet, but I also would like to address this in a follow up as keyboard navigation could be addressed as a complete chapter IMO.

[Eve00000]

Test Pt1 : Clean Win 10 x64 VM (4cpus 16Gb , build installed. (1920*1080)

overal 1st impression: font is too small
Simple configuration & advacced (link deck directly to sounddevice) work fine.
Maybe an OK/Close button would be nice to close the preferences?
Maybe the buffer in the same look as Sample Rate? (it's quiet dark now)

QML takes +/- 30 of CPU, legacy +/- 15% while just playing a track (same track ALAC, no stem), even without playing decks (legacy: 8%) (overall performance is not good, spinnies stutter, waveforms stutter, music stutters

QML: Audio Buffer on 85 and still not enough buffer to listen clear to the track, (SampleRate 48k)

Crash on exit

[acolombier]

Thanks for the overall review on QML @Eve00000 !

Let's keep the focus at hand tho, and keep track of the other issues separately.

overal 1st impression: font is too small
...
Maybe the buffer in the same look as Sample Rate? (it's quiet dark now)

The font in general will need further work, but this will come in a later stage. Same with the combobox (not sure if you remember, but I mentioned having already 5 versions of it across the five branches, so I just need to consolidate that once merged). Overall, colours and size will need further adjustment when we get to polishing.

Maybe an OK/Close button would be nice to close the preferences?

There is supposed to be a close button on top, but I haven't yet implemented it on the global setting dialog, SOmething to come in a future PR, alongside the "detach" mode which allow you to pop the dialog out (useful when testing thing, but also still going live)

Test Pt1 : Clean Win 10 x64 VM (4cpus 16Gb , build installed. (1920*1080)
...
QML takes +/- 30 of CPU, legacy +/- 15% while just playing a track (same track ALAC, no stem), even without playing decks (legacy: 8%) (overall performance is not good, spinnies stutter, waveforms stutter, music stutters
QML: Audio Buffer on 85 and still not enough buffer to listen clear to the track, (SampleRate 48k)

Yes, there is still global issues with performance. Most of it likely come from the fact that I would assume you don't have any graphical acceleration in the VM (which QML heavily rely on). There is no doubt there will be some work to do on that front later!

Simple configuration & advacced (link deck directly to sounddevice) work fine.

Great!

[ywwg]

overal 1st impression: font is too small

I really think we should not be focusing on design issues with this first pass. Let's focus on functionality -- does it work correctly? Does it cause crashes? Is the code well structured? If the foundation is ok, then we can iterate on design.

[ywwg]

Some code structure comments

[JoergAtGithub]

I really think we should not be focusing on design issues with this first pass.

I fully aggree, lets get the technology merged, UI can be revised later.
At least on Windows this is approach is barely usable and additionality it breaks keyboard navigation and accessibilty on any platform. But we can switch back to the proven dialog design at any time. I'm in favor to merge this PR therefore.

[acolombier]

Thanks @ywwg and @JoergAtGithub for looking into this.

At least on Windows this is approach is barely usable

It would be really appreciated if you could elaborate a bit more what are the current issue on Windows (besides the keyboard, which is likely a "skill issue" as mentioned here - still need to wrap my head around it!) as raised there, so we can later on address this. I am mostly testing on a VM and I appreciate the the setup is likely too minimal to be realistic.

it breaks [...] accessibilty on any platform

Could also clarify this? Is this only related to keyboard or do you have other accessibility issues?

[JoergAtGithub]

It would be really appreciated if you could elaborate a bit more what are the current issue on Windows is

I did above. On my simple setup I need three time the dialog height to display the sounddevice inputs/outputs. Not an issue for me as expert, but a normal user would never get an overview with wires always leaving the visible screen area.

Regarding accesibility: Luckily I'm not affected personal, but we have several visual impaired users. I can't imagine how our blind users can connect the wires correctly. This was never an issue with the current UI, where you can select every string individually and the braile reader reads each this selected string.

[acolombier]

I did above. On my simple setup I need three time the dialog height to display the sounddevice inputs/outputs.

Right - I guess there is some effort to be done on compactness for the sound boxes. Am I right in thinking this is however better that what you raised here, with same device input/output showing on the same device box instead of having these duplicates?
If you wouldn't mind sharing a screenshot to where we are today, that would be useful to see how much work is there needed for supporting your setup in an optimal way.

This was never an issue with the current UI, where you can select every string individually and the braile reader reads each this selected string.

I'd be curious to hear feedback from impacted user. Is the current view really working this well with screen reader? Also worth to say that the legacy view with this matrix of combobox will still be available in the Legacy tab.

[ywwg]

I like this logical split a lot more, thank you. One big question about that qml_owned_ptr code :)

[ywwg]

QML to the future!!!

[Swiftb0y]

couple thoughts, not a thorough review. Overall in decent shape I think.

[acolombier]

@Swiftb0y I have included all changes suggested in #14514 (hopefully?). If there is any folow up, could you please post them there so we merge this one first?

[acolombier]

Apologies @Swiftb0y I realised there was two comments from you I had forgotten to address. Hopefully everything is addressed now and it does build 🤞

[Swiftb0y]

thanks. I don't have the muse to take another look at this. @ywwg please merge if you're comfortable with your LGTM.

[ywwg]

@acolombier please squash the fixups and I'll merge

[acolombier]

Done @ywwg!

[acolombier]

If you merge this PR, it might be worth merging #15214

[JoergAtGithub]

I don't consider the graphic setup as good user experience on Windows, due to the huge number of inputs and outputs, which do not fit in the preferences window. But lets merge this first step. We can polish the UI later, as QML is not enabled for end users yet.