Yes, but for most of the users it absolutely makes sense to have EQ disabled before performing room correction. Your proposed use case is really a special one.
It wouldn't be recognised as that special if more users were educated about why doing it this way around (EQ for the speaker in its anechoic listening window first, limited bandwidth room correction second) is actually better.
I agree with
@harkpabst here, this approach is really well supported by existing research on sound reproduction.
However, there might be one problem with it in the current WiiM implementation - loudspeaker correction EQ should also be associated to a specific
output (i.e. where the loudspeaker is connected), not to the
input (as it is now)!
Obviously running RoomFit with EQ enabled on an input might make the RoomFit profile incorrect when a different input is selected - which is why it makes a lot of sense to me that
@WiiM Team decided to disable EQ when running RoomFit. It is IMHO a reasonable approach.
So if we want to use loudspeaker correction together with RoomFit, for any
output we'd ideally want to have two layers of EQ:
- Optional 2x10-band EQ used by RoomFit, available as an option only on outputs where loudspeakers are connected - this we already have.
- Optional 10-band PEQ used for loudspeaker or headphone response correction - this is currently missing!
If I was the one designing it I'd probably do it so that the end-user can tag each output as a "loudspeaker" or "headphone" output, depending on what they have connected to it.
For outputs tagged as "headphone" we'd only have the first EQ type available, which would allow either directly loading a pre-existing profile from a list of headphones models (e.g. from
AutoEQ), or allow you to configure/import a manual PEQ profile. RoomFit would
not be available on these outputs.
For outputs tagged as "loudspeaker" we'd have both EQ types available. Similar to above, the first EQ type would allow either loading a pre-existing EQ profile from a list of loudspeaker models (e.g. from
spinorama.org), or allow you to configure/import a manual PEQ profile. RoomFit would be available on these outputs.
Of course, having EQ per-input makes sense as well in some cases (see
here for some ideas), so ideally that would be a third layer of EQ (i.e. this is basically the same as the existing GEQ/PEQ function).
Finally, another thing I believe is missing is just a simple tone control (something I already mentioned a few times, e.g.
here). This could either be a fourth layer of EQ, or just an extra user interface for the existing per-input EQ (third view in parallel with GEQ and PEQ views).
Of course, there's always a question on whether there's enough HW capacity on the devices for all this functionality, and how many user's would actually use it if it was there.
My feeling is that much more people might consider at least trying loudspeaker/headphone correction if it was as simple as choosing a corresponding profile from a list. I might be wrong, of course!