WiiM Home App v3.2.2 Update – May 23, 2025

Please review the app update release notes below. If you encounter any issues, feel free to reach out to us.

App Release Version
v3.2.2

What's New:

1. Center Channel for Dolby 5.1 Setup: Assign a device as the Center Speaker (requires upcoming beta firmware update).
2. Improved Qobuz Browsing: A redesigned layout that enhances navigation, bringing it closer to the native Qobuz app experience.
3. Thumb Up/Down for Pandora: Support for thumbs up and thumbs down functionality on Pandora (requires upcoming firmware update).
4. NAS Indexing:
- Support for Minim Media Server indexing to enhance browsing.
- Folder category browsing for Windows Media Player Share in "Advanced Mode."
5. Local Music Improvements:
- Organize music by Composers and Genres for easier browsing.
- Enhanced Genre page layout, organizing tracks, albums, and artists all in one view.
- Add "Date Added" sorting option for tracks.
6. HotMix Update:
- Add "Rap US" and "Rap Francais" radio stations.
- Support for adding to Presets (requires upcoming firmware update).
7. [Android] Track Title Display: Show full track titles for KKBox, NAS, USB, Samba, Local Music, and Qobuz.
8. [Android] MMM for Stereo Room Correction (Beta): Support for Moving Microphone Measurement in Stereo Room Correction. Enable this feature in Room Correction settings. The Moving Microphone Measurement (MMM) for Left/Right Room Correction is coming soon. Stay tuned!
9. Input Rename: Option to restore default input names.
10. Lock Screen Controls for Various Inputs: Support for controlling playback directly from the Lock Screen, except for Bluetooth input.

Bug Fixes:

1. USB Media Library Fix: Fixed incorrect album artist names (requires upcoming firmware update).
2. [Android] Playback Failure Fix: Resolve playback issues caused by special characters.
3. General Enhancements: Improved overall stability, performance, and bug fixes.

 

[Skull]

Where is that option?

Been using WiiM app all morning and battery is back to single figure usage now lock screen widget is turned off

Oh and I don’t miss it

 

[iruKa]

Favorite albums in Qobuz don't stay cached and app load them every time. Never happen before. Very annoying

View attachment RPReplay_Final1748780232.mp4

 

[harkpabst]

It shuts off everything attached to the 12V trigger, which is pretty important because some things could be drawing quite a bit of power when on.

That question wasn't meant literally, but as a reply to the question why one would want an "off" button in the WiiM Home app.

 

[Lomax_hjs]

That question wasn't meant literally, but as a reply to the question why one would want an "off" button in the WiiM Home app.

In my view, it makes more sense to turn something off that pause it if you want to stop listening to the radio.

 

[dominikz]

MMM is very repeatable. You can see the RTA stabilising while performing the measurement.

Exactly - that is one of the reasons why I believe it is very suitable for RC.

I think if I left the mic in exactly the same location multiple sweeps would also be repeatable, I always got very similar results when trying the multiple measurement option compared to a single sweep.

That is absolutely true, if you don't move the mic at all, each sweep will result in identical measured response.

However, most users will not be able to put the mic in the same exact spot between different RC runs - many I'm sure just hold the mic in hand (e.g. phone built-in mic) so the mic location will always vary a bit, and with it also the measured response.

With regard to your similar measurements when comparing sweep to MMM in REW it makes you wonder why WiiM feel the need to first perform a sweep followed by MMM.

I'm wondering the same thing, to be honest.
Perhaps it is to be able to detect potential ambient noise induced deviations in MMM?

We do know that WiiM currently perform the swept sine measurement in the MLP and the MMM measurement. What we do not know is how they are using both measurements to come up with the correction filters.

Different weighting? Maybe depending on frequency range? Possibly even depending on the current RC settings? Could be I'm overthinking this and they are just averaging both results, but we don't know for sure.

To try and figure out how the sine sweep measurement and MMM are utilized I did three more tests today.

All three tests were done with the same RC settings (full-range correction, all variables maxed out, MMM with external calibrated mic):

1. First RC test I did was standard MMM, utilizing both static single-point sine sweep measurement and periodic pink noise MMM. I.e. in this case both static and MMM part of RC resulted in valid measurement responses.
   This is our baseline measurement.
   
   
2. Second test was again with MMM enabled in WHA RC, but I muted the playback during the static measurement (right after the sync tone but before the main sine sweep). I unmuted the playback before the MMM part. I.e. in this case only the MMM part of RC results in a valid response.
   In this case we see that the total measured response is severely mangled.
   
   
3. Third test was again with MMM enabled in WHA RC, this time I allowed the static single-point sweep measurement to play normally, but I muted playback before the MMM part. I.e. in this case only the static measurement part of RC results in a valid response.
   
   This measurement looks very similar to the baseline test; most differences seem relatively minor.

So it seems that the static single-point sweep measurement step is a critical part of the WHA RC MMM algorithm implementation, while the MMM step seems to be almost optional.

Based on the above I'd guess that WiiM are using some king of weighing when averaging sweep and MMM responses, where they give significantly higher weight to the sweep. It may be that weighing is frequency-dependent - which might explain the strange discontinuity in the response in test #2 (i.e. when only the MMM part produces a usable response).

 

[dominikz]

I'm wondering the same thing, to be honest.
Perhaps it is to be able to detect potential ambient noise induced deviations in MMM?


To try and figure out how the sine sweep measurement and MMM are utilized I did three more tests today.

All three tests were done with the same RC settings (full-range correction, all variables maxed out, MMM with external calibrated mic):
View attachment 21901

1. First RC test I did was standard MMM, utilizing both static single-point sine sweep measurement and periodic pink noise MMM. I.e. in this case both static and MMM part of RC resulted in valid measurement responses.View attachment 21903
   This is our baseline measurement.
   
   
2. Second test was again with MMM enabled in WHA RC, but I muted the playback during the static measurement (right after the sync tone but before the main sine sweep). I unmuted the playback before the MMM part. I.e. in this case only the MMM part of RC results in a valid response.View attachment 21905
   In this case we see that the total measured response is severely mangled.
   
   
3. Third test was again with MMM enabled in WHA RC, this time I allowed the static single-point sweep measurement to play normally, but I muted playback before the MMM part. I.e. in this case only the static measurement part of RC results in a valid response.
   View attachment 21906
   This measurement looks very similar to the baseline test; most differences seem relatively minor.

So it seems that the static single-point sweep measurement step is a critical part of the WHA RC MMM algorithm implementation, while the MMM step seems to be almost optional.

Based on the above I'd guess that WiiM are using some king of weighing when averaging sweep and MMM responses, where they give significantly higher weight to the sweep. It may be that weighing is frequency-dependent - which might explain the strange discontinuity in the response in test #2 (i.e. when only the MMM part produces a usable response).

@WiiM Team @WiiM Support @RyanWithWiiM Is the above described behaviour intentional?
It seems quite strange to me and I don't really see the benefit.
Also, notice how the RC calculates filters very differently in test #1 and test #3 (especially between 50-100Hz), although the measured responses are very similar.
Lastly, I believe the forced screen rotation is not a good idea - it is especially frustrating if using an external wired measurement microphone (like e.g. UMIK-1). Perhaps this screed rotation could be made optional if an external microphone is connected?

 

[Vladetz]

Received 3.2.3 update

 

[WiiM Support]

@WiiM Team @WiiM Support @RyanWithWiiM Is the above described behaviour intentional?
It seems quite strange to me and I don't really see the benefit.
Also, notice how the RC calculates filters very differently in test #1 and test #3 (especially between 50-100Hz), although the measured responses are very similar.
Lastly, I believe the forced screen rotation is not a good idea - it is especially frustrating if using an external wired measurement microphone (like e.g. UMIK-1). Perhaps this screed rotation could be made optional if an external microphone is connected?

Hi dominikz, team

Thank you all for your tests. Our engineers will look at these and reply to you shortly. Please stay tuned!

 

[EddNog]

That question wasn't meant literally, but as a reply to the question why one would want an "off" button in the WiiM Home app.

I guess some people don’t like having a(nother) remote around. ¯\_(ツ)_/¯

-Ed

 

[slartibartfast]

I guess some people don’t like having a(nother) remote around. ¯\_(ツ)_/¯

-Ed

True but they could wait 30 seconds for it to enter standby or use a smart plug to turn it off completely to minimise energy use. Automatic standby works very well compared to automatic switching between inputs

 

[harkpabst]

All true. And still there's a discrepancy in functionality between the physical remote (which otherwise supports less features, of course) and the app for no obvious reason.

 

[s3igell]

In my view, it makes more sense to turn something off that pause it if you want to stop listening to the radio.

But, is your view taking into account all the other background functionality and connectivity which are still enabled whilst the WiiM is in "sleep" mode: being an automatic endpoint for the various Cast services as well as auto-detect for Optical In (and HDMI-ARC for the Ultra et al) as well as being ready to respond to the WiiM Home App??

 

[jiaxin.li (WiiM)]

@WiiM Team @WiiM Support @RyanWithWiiM Is the above described behaviour intentional?
It seems quite strange to me and I don't really see the benefit.
Also, notice how the RC calculates filters very differently in test #1 and test #3 (especially between 50-100Hz), although the measured responses are very similar.
Lastly, I believe the forced screen rotation is not a good idea - it is especially frustrating if using an external wired measurement microphone (like e.g. UMIK-1). Perhaps this screed rotation could be made optional if an external microphone is connected?

Thank you very much for your feedback!
We highly value the points you raised.
In the current implementation of the MMM (Moving Mic Measurement) algorithm, sweep-based measurements are indeed given more weight than pink noise. This is because sweep signals typically provide more accurate time-domain and phase information, while pink noise measurements are used more to supplement the overall spectral trend. That said, we will re-evaluate and further optimize the final implementation of MMM.
Your comparison between test #1 and test #3 is also very insightful. Although the measured frequency responses appear similar, the filters generated in test #1 do show an unusually large difference in the 50–100 Hz range. We will investigate this further, and would appreciate it if you could submit a feedback report to help us collect the relevant data and diagnose the issue more effectively.

 

[canard]

the mmm part just seems to be out of place in terms of algorithms...

Exactly - that is one of the reasons why I believe it is very suitable for RC.

That is absolutely true, if you don't move the mic at all, each sweep will result in identical measured response.

However, most users will not be able to put the mic in the same exact spot between different RC runs - many I'm sure just hold the mic in hand (e.g. phone built-in mic) so the mic location will always vary a bit, and with it also the measured response.


I'm wondering the same thing, to be honest.
Perhaps it is to be able to detect potential ambient noise induced deviations in MMM?


To try and figure out how the sine sweep measurement and MMM are utilized I did three more tests today.

All three tests were done with the same RC settings (full-range correction, all variables maxed out, MMM with external calibrated mic):
View attachment 21901

1. First RC test I did was standard MMM, utilizing both static single-point sine sweep measurement and periodic pink noise MMM. I.e. in this case both static and MMM part of RC resulted in valid measurement responses.View attachment 21903
   This is our baseline measurement.
   
   
2. Second test was again with MMM enabled in WHA RC, but I muted the playback during the static measurement (right after the sync tone but before the main sine sweep). I unmuted the playback before the MMM part. I.e. in this case only the MMM part of RC results in a valid response.View attachment 21905
   In this case we see that the total measured response is severely mangled.
   
   
3. Third test was again with MMM enabled in WHA RC, this time I allowed the static single-point sweep measurement to play normally, but I muted playback before the MMM part. I.e. in this case only the static measurement part of RC results in a valid response.
   View attachment 21906
   This measurement looks very similar to the baseline test; most differences seem relatively minor.

So it seems that the static single-point sweep measurement step is a critical part of the WHA RC MMM algorithm implementation, while the MMM step seems to be almost optional.

Based on the above I'd guess that WiiM are using some king of weighing when averaging sweep and MMM responses, where they give significantly higher weight to the sweep. It may be that weighing is frequency-dependent - which might explain the strange discontinuity in the response in test #2 (i.e. when only the MMM part produces a usable response).

the mmm part just seems not ok in terms of algorithms...
;-)

 

[dominikz]

Thank you very much for your feedback!
We highly value the points you raised.

I'm really glad if some of it is useful!

In the current implementation of the MMM (Moving Mic Measurement) algorithm, sweep-based measurements are indeed given more weight than pink noise

Thanks for confirming my conjecture!

This is because sweep signals typically provide more accurate time-domain and phase information, while pink noise measurements are used more to supplement the overall spectral trend.

While I agree with this statement, in the context of the current RC algorithm (which only uses simple IIR EQ filters and doesn't seem to discriminate between minimum-phase and non-minimum phase phenomena in the measured response) I can't see much reason why a sweep measurement would be required at all if the MMM option is enabled.

IMHO the benefit of single-point sine sweep measurement over MMM are:

• It is quick and simple
• It is resistant to ambient noise
• It can measure both magnitude and phase (and therefore can be used to calculate excess phase, group delays, impulse response, step response...)

Points one and two are absolutely valid in the context of current WiiM RC, but I don't see that point three is currently utilized in any way.

On the other hand the benefits of MMM over single-point sine sweep measurement are:

• Measured responses are very repeatable between attempts
• Spatial averaging removes audibly benign room reflections, so the measured response resembles anechoic PIR very closely above approx. 1kHz
• The measured response is progressively more smoothed with frequency, making it a better baseline for EQ. In simple words, there's less change of severely degrading the sound if using MMM response as baseline for EQ.

All that being said, I could see a few use-cases where it might make sense to supplement MMM periodic-pink noise measurement with a single point sweep measurement:

• To find areas which shouldn't be EQ-ed:
  • To detect non-minimum-phase areas where minimum-phase EQ is not efficient for correction (by deriving smoothed excess phase group delay from the sweep measurement and looking for GD jumps)
  • As a baseline for detection of ambient-noise-induced peaks in the MMM response (which shouldn't be EQ-ed)
• To calculate FIR-based phase corrections (which I don't believe are really needed in many cases)

That said, we will re-evaluate and further optimize the final implementation of MMM.

Thanks, that is really great to hear!

Your comparison between test #1 and test #3 is also very insightful. Although the measured frequency responses appear similar, the filters generated in test #1 do show an unusually large difference in the 50–100 Hz range. We will investigate this further, and would appreciate it if you could submit a feedback report to help us collect the relevant data and diagnose the issue more effectively.

I've already opened ticket #534103, let me know if anything else is needed. I also wonder if this might be a similar issue as the one I reported a few months ago in another ticket #526948 (unfortunately I never got any response on that one).

While I have your attention, a while ago I reported two more RC-related tickets I never got any feedback on: #530842, and #521668, perhaps those could be helpful too?

In general I'd say that WiiM RC development is progressing nicely, but I do have a few suggestions; main ones being:

• Support individual L/R correction with MMM
• Support setting RC max gain to 0, and avoid stacking of positive gain filters (related to ticket #530842)
• Introduce variable smoothing option in RC (e.g. see REW help reference)
• Introduce EQ config import/export function, with REW-compatible format support
• Improve the default RC configuration, my proposal for least-destructive basic correction would be:
  • range: 20-500Hz,
  • max gain = 0,
  • min gain = -12,
  • max Q= 10
  • B&K target curve,
  • variable smoothing,
  • MMM enabled,
  • use individual channel correction by default
• Enhanced clipping avoidance by automatic pre-gain/volume limit enhancement (e.g. like I suggested in ticket #527994)

Anyway, sorry for the long-winded post! Hopefully at least some of it might be interesting/useful.

 

[canard]

well synthesized... ;-)