Re: [PATCH v8 0/2] ALSA: usb-audio: the Topping M62's vendor controls

[Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>]

On Fri, 04 Sep 2026 05:18:18 +0500, I wrote:
>
> **The card cannot be read. Not by this driver, and not by the vendor's
> own application.**

That is wrong, and I would rather correct it before it is answered.
The card does report its state. It reports rather a lot of it. What I
had was two blind spots that happened to hide the same thing.

**What I missed.** In four of the six captures the state restorers on
this machine wrote to the card about 90 ms after the bind, so the
report that arrives at 5.2 s described their write and was
indistinguishable from silence. In the one capture with the restorers
disabled, nothing was plugged into any input -- and the card reports
the gain only of an input whose jack is present, so there was nothing
for it to report. Each blind spot alone would have been enough.

Repeating that capture with a coupler in IN 1 and every restorer
masked: the card sent 0x21/0x04 = 50 at 5.17 s, which is exactly what
I had set by hand on the front panel. Twenty-two outgoing frames in
the whole run, all of them 0x11/0x24 or 0x11/0x26. Nothing was
written; that value came from the card.

Then I turned the knobs by hand, still with nothing writing:

  - Mic-1, 50 up to 53 and back to 50: every step reported, seventeen
    frames of 0x21/0x04;
  - the headphone volume, likewise: five frames of 0x64/0x03, 32, 33,
    33, 32, 31.

So the corrected picture:

                        announced at connect       when a hand moves it
  five input gains      yes, if the jack is        yes
                        present, ~5.2 s after
                        subscribe
  two output volumes    no                         yes
  two selectors         no                         never

The model that fits: **the card reports what a hand does to the
hardware, not what its settings are.** Jack states, mutes, battery and
the gain of a connected input are all physical facts it knows by
itself. An output volume is a setting, so it is not in the connect
report -- but its knob is on the front panel, so turning it is an
event and that is reported. A source selector has no front-panel
control at all, which is why nothing about it ever arrives: there is
no event to report, not a missing command.

That last point is worth stating plainly because it retires a question
I have been asking since v2. The "Unknown" first item on the two
selectors is not a compromise; it is the accurate description of a
control the host can set and can never learn. If another host set it,
this one cannot find out, and no firmware change short of adding a
query would alter that.

**I withdraw the proposal at the end of my last mail.** Writing the
minimum to the gains at bind, after init_cur_mix_raw(), would destroy
a value the card is about to report 5.2 s later. It was the right
shape for a device that cannot be read and the wrong shape for this
one.

What the measurement suggests instead is that the driver's problem is
a race it need not enter. alsactl restores at 90 ms; the truth arrives
at 5.2 s; the driver loses by a factor of fifty and publishes an
invented number in between. But the component road you suggested can
simply not publish yet: hold component_add() until the first report
lands, and the controls appear late, once, with the values the panel
actually has. Nothing restores over them because they do not exist to
be restored. A mixer quirk cannot express that; the component split
can, which is an argument for it I did not have this morning.

The output volumes stay unknown until someone touches them, and the
selectors stay Unknown until someone writes them. That is honest
incompleteness rather than invention, and it is as good as this
hardware allows.

What stands from the last mail: the vendor application still issues
162 frames on connect and not one read; 0x11/0x26 still goes out after
its bulk push rather than before; a value set by hand still does not
survive being plugged into another host, since MCC overwrote my 70
with its stored 50 forty milliseconds after connecting. What does not
stand is the conclusion I drew from those, and the recommendation.

Sorry for the noise. I would rather send this than have you answer the
version I got wrong.

-- 
Mikhail