CO Renaming (Pt. 5): Latency Control

[Holzhaus]

Part of #11931.

Moves the latency control into the [App] group.

[JoergAtGithub]

It would be future proof to call it output_latency instead of just latency. We currently do not use the input-latency value that portaudio reports, but for more complex multi device sync scenarios it might be needed too.

[Holzhaus]

It would be future proof to call it output_latency instead of just latency. We currently do not use the input-latency value that portaudio reports, but for more complex multi device sync scenarios it might be needed too.

@daschuer @Swiftb0y opinions?

[Swiftb0y]

very much in favor.

[daschuer]

Yes, you hit a sore point. Potaudio the output latency is the
"Internal buffering + Host API reported latency" the buffer size of one cycle also often regerenced as latency is not included.

Therfore it looks like the use in the Akai script is wrong.
I guess the want to compensate the buffer size (frames per buffer)
Do we even have a control for that?
Do other scripts compensate a buffer sycle?

I am in favor for the remaining. Do you want to fix the Akai script as well?

[Holzhaus]

I opted for output_latency_ms.

[daschuer]

I think the Akai mapping is still broken. The reported output_latency can be long and is unrelated to the internal processing.
I have found out where the "audio_buffer_size" CO is gone that is probably the correct use here:
https://github.com/mixxxdj/mixxx/pull/11121/files

But does the script really need that compensation? Why do we not see the use case in other mappings?

Did you consider how to continue?

[daschuer]

My dump button is broken. Does yours work? I will file a bug.

[Holzhaus]

My dump button is broken. Does yours work? I will file a bug.

Last time it check it did. It creates a file in ~/.mixxx. It does not create a save file dialog.

[daschuer]

Oh, right it is working. I just needed to look in my testing .mixxx folder 🤦

[Holzhaus]

I think the Akai mapping is still broken. The reported output_latency can be long and is unrelated to the internal processing.
I have found out where the "audio_buffer_size" CO is gone that is probably the correct use here:
https://github.com/mixxxdj/mixxx/pull/11121/files

But does the script really need that compensation? Why do we not see the use case in other mappings?

Did you consider how to continue?

Yes, I considered it and decided that I won't mess with the mapping in this PR. I updated the control, but I don't plan other changes. The bug was not caused by this PR and I don't own this controller, so I cannot properly test changes.

[daschuer]

OK, what puzzles me is the question if we need to revive the "audio_buffer_size" for such use cases. The bug in the Akai mapping itself is there or not, probably hardly notable. Do you have there a good idea for a bug report regarding the that?

[Holzhaus]

OK, what puzzles me is the question if we need to revive the "audio_buffer_size" for such use cases.

The use case is "implementing beatjumps in JavaScript instead of using the proper Mixxx COs" ?

[daschuer]

The use case is "implementing beatjumps in JavaScript instead of using the proper Mixxx COs" ?

Ok, that is clearly not a valid use case. So there is nothing else to do.
Thank you for this PR.

[daschuer]

We can also ignore the Lint issues. Someone really needs to put some love on this mapping.