I have. ;-)
Important subject...about dac level etc etc
- Thread starter canard
- Start date
(I took the opportunity to run the " vumeters"...and it seems that in my use a 94% (6*0.6db) should be enough margin for everyday use.."margin")
It would be really interesting for each other to observe in true peak...
the flows of the different streaming radio etc providers to observe their traffic policies....even seems more interesting at first than the stories of resolutions etc.
(And....impact directly the presence of limiter in wiim machine)
and the fact of being able to tinker with DSP, Pandora box, at the level of our Wiim etc brings needs for monitoring the flow level more important, and "limiter" just a not so happy precaution...(otherwise, integrating a simple headroom at 2.5/3db like the rme would certainly be enough...)
(Remind me at what level of the process the proposed output levels are achieved? 2v 1v 800mv etc?
)
It would be really interesting for each other to observe in true peak...
the flows of the different streaming radio etc providers to observe their traffic policies....even seems more interesting at first than the stories of resolutions etc.
(And....impact directly the presence of limiter in wiim machine)
and the fact of being able to tinker with DSP, Pandora box, at the level of our Wiim etc brings needs for monitoring the flow level more important, and "limiter" just a not so happy precaution...(otherwise, integrating a simple headroom at 2.5/3db like the rme would certainly be enough...)
(Remind me at what level of the process the proposed output levels are achieved? 2v 1v 800mv etc?
)
Last edited:
@canard I can't really follow what you are saying but it would be great if Wiim implemented a True Peak meter so that any problems with clipping (whatever the reason) can be seen and also the headroom indication like REW can display whilst changing PEQ parameters would be great, then we can see the impact of what our filters do level wise and adjust the (digital) gain accordingly.
Sorry...
useful... becomes necessary in the case of possible modifications offered by the Wiim... the difficulty being the lack of a vumeter on somes, many, machines wiim..
and if we want to consider that a (true peak) vumeter is useful on an ultra...it is just as useful on other machines
(just perhaps "overload " indications..)
;-)
I'll stop my "loopy" blah blah there.
Last edited:
Totally agree and all Wiim devices that don't have a screen, make it visible in the Wiim app maybe just clip indicators indeed. But again the headroom indication/calculation like REW is most welcome I think when a user is adjusting EQ's Roomfit, pre-gain or whatever.
processing corrections in rew requires some skills and the temp etc...
but also if the idea is to observe (easy) in a relevant manner in output num, captured on "can" etc for example, it is necessary to ensure that the "limiter 0dbfs" is not engaged....which is not the case currently it seems....
Last edited:
Not sure if I understood correctly what you meant, but note that the overload indication could also be implemented to sense the level just before the signal hits the output limiter, or alternatively it could detect the amount of attenuation the limiter introduced.
So it is not strictly necessary to disable the limiter to have usable and actionable overload indication.
E.g. if you added +3dB boost to a 0dBFS peak signal, the overload indication could tell you that the level is +3dB in overload, and then still have the limiter dynamically turn the level down to avoid hard clipping.
As mentioned, another way to achieve the same would be if the WiiM Home App simply reported by how much the built-in output limiter attenuated the signal peaks. So if the signal level was reduced by 3dB by the limiter WHA could report something like "Overload detected! Attenuation: 3 dB"
I'll sometimes do the equivalent in my DAW when processing audio tracks: having peak metering before a limiter on the master bus allows me to adjust the various levels to avoid output overload; but should some peak still manage to somehow hit >0dBFS (for any reason) the limiter will catch it as a kind of last resort line of defense. That way I avoid hard clipping under any condition.
Note that in this case the pre-limiter peak meter will record the same overload peak level that the limiter detected as attenuation.
That's what I've thought since the beginning, and the last VU meter discussion on the Ultra is moving towards this position... (and I insist so much on an overload feedback)
But for example... without an overload indication like on most Wiim machines currently... if a digital capture... the limiter currently doesn't allow us to make accurate observations... it does a too good job...
That's why "as is" and being forced to observe downstream of the limiter, I say it's clumsy, not in its function, but because it prevents us from making accurate observations for the moment...
But if we can ensure appropriate levels without true peak saturation, its presence can of course be reassuring... but for now... not really....reassuring...but quite stupid ;-)
a return "on his commitment" ( limiter) would be...a return of overload!
Simply...
;-)
How many people know about this limiter (Wiim has never been very explicit about it)...its principle and its impact?
Last edited:
slartibartfast
Major Contributor
- Joined
- Apr 18, 2024
- Messages
- 4,888
Not sure what you mean here. It was stated this morning that the VU meter is upstream of the limiter.
Yes...with Ultra...
In another situation- machine no vumetre...in analogique or num output...you can observe only .....after. ( i dont now with usb)
Last edited:
I guess I simply don't agree with this assessment.
Both limiting and clipping should be quite easy to detect with measurements at the analog output (i.e. downstream from the WiiM device).
The main difference is that hard clipping will add significantly more distortion to the signal, so it might be more audible in acute cases. Occasional low-level clipping can also be difficult to hear, unless you know exactly what to listen for.
But you are right that severe (e.g. +10dB overload) would be very easy to hear if the output clips, while it might not be as easy to hear if the limiter is active. Still, I'm not really convinced that makes clipping desirable - people who might overload the output so severely might not know anyway what they did wrong or how to fix it.
Have a look at this post (and also this one). The functionality is not documented well, unfortunately.
Well, I'm not really concerned... I'll let it go... (and also makes me look like an idiot )
That Wiim already really explains the presence, its position, and its impact... will already help everyone much better understand the precautions to take to avoid engaging it "at every turn"...
That Wiim already really explains the presence, its position, and its impact... will already help everyone much better understand the precautions to take to avoid engaging it "at every turn"...
On test signals, yes... on music, it's more delicate...I guess I simply don't agree with this assessment.
Both limiting and clipping should be quite easy to detect with measurements at the analog output (i.e. downstream from the WiiM device).
The main difference is that hard clipping will add significantly more distortion to the signal, so it might be more audible in acute cases. Occasional low-level clipping can also be difficult to hear, unless you know exactly what to listen for.
But you are right that severe (e.g. +10dB overload) would be very easy to hear if the output clips, while it might not be as easy to hear if the limiter is active. Still, I'm not really convinced that makes clipping desirable - people who might overload the output so severely might not know anyway what they did wrong or how to fix it.
Have a look at this post (and also this one). The functionality is not documented well, unfortunately.
( But using a few streamed test signals or in yours phones ( rew generator) could be very useful for many on these topics... easy...i use often here)
Last edited:
Of course I fully I agree with this. Any functionality that is implemented should be adequately documented.
It does not make you look bad - we're all free to have and share our opinions and reasoning.
If you read my posts you will see that I agree with you on many points. Just not on all of them - and that is perfectly fine.
By engaging in a civilized discussion we provide different viewpoints for people reading to consider.
I guess it depends, some signals definitely make it easier to detect one vs the other.
My point is that people who aren't technical will have a problem detecting and diagnosing both clipping and limiting. People who are more technical should be able to detect and diagnose either.
But it is absolutely true that as a first step it is important to know the expected behavior - and improving documentation would be a great way to start. Overload or attenuation level indication in WHA would be another way to improve.
in fact it is very simple to observe in a few clicks ( "can" with num input, rew ,mt virtins etc) on the num output for example....and the situation, result,here, behavior is very very "simple" in the end
Last edited:
