Yes it seems you may have a production defect. It is still important to compare systems as they may share for example Usb controllers. It is possible in some desktop and even Laptops may have shared usb controllers and/or power systems.
For example if I don’t have the 1.7k whine/beep issue. Why? Is it my headset doesn’t have say a defective component or is it related to some form of emi due to setup?
Comparing system and environmental conditions serves to eliminate factors to help determine a root cause.
For example if we were local to each other we could perform a cross test if using your headset on my rig and vice versa. If my headset had no sound issue on your rig and yours had issues still hooked up to mine then we’d know with higher certainty that a mfgring QA issue is more definite.
This is part of a model used in 8D (8 disciplines of problem solving in a manufacturing environment).
You have already did a lot of troubleshooting methods which strongly suggests a mfgring qa problem being potentially identified.
No this is simply utilizing Fishbone. At present we have several hypothetical causes. If you were developing hardware for a closed system like a console with very minor variance in components it is much easier to “get it right the first time”.
Using Fishbone you list potential causes (many as reasonable) and work through each until you have what is likely the root cause.
Possible Causes
Hmd Mfgring issue bad component or assembly issue(missing sheilding for example)
Mobo Usb chipset issue
5v Rail Noise (psu &or mob8 issue)
Environmental issue
There maybe other factors to consider.
@Timo.H1 has already performed a lot of diligence in testing on multiple systems, trying chokes. He has unfortunately not been successful with finding a usb ground/noise isolator that is compatible.
He or someone had tested a usb soundblaster and has had mixed results. Iirc he mentioned the noise issue is present but reduced.
Imho it is likely an hmd defect that is affecting some users. As it is not affecting all. If it affected all then this would be conclusive as a design flaw.
Now.I will say it doesn’t help these situations when some ppl jump to conclusions dismissing an issue using ridiculous words like “hyperbolic”, “Trolling” etc… As these often are boundless presumptions of pride. Nor it is not helpful to presume a cause as absolute.
We had a member long ago with the p4k had a connectivity issue. We tried suggesting many different things to try. The op ended up discovering the root cause was his usb keyboard had an odd failing that he had a hunch on and it paid off.
Finding the actual root cause can be quite difficult. @Timo.H1 has already laid a lot of ground work that yes it reasonable to believe he might have an hmd with a defect. A defect that some others may have. Continuing to explore to reaffirm things is still something to evaluate.
Yes there are many possible causes and we’re listing out Pimax serial numbers to understand if it was a bad batch or if we are on a different build revision. Was the issue fixed? I’m not making any conclusions. Just hypotheticals. Maybe it is a chipset issue or a bad component. So far Timo.H1 has tested several computers and laptops with the same result so that is starting to rule that out.
I’m saying that if it were a power supply issue, that could be addressed in the design. One should assume there will be many computers with very noisy 5V rails. If it were an EMI issue, that could be addressed in the design as well. Better layout, better cabling, better shielding, etc. These issues can and should be discovered during development. That is what I’m saying. The more product that is shipped of course there will be corner cases but so far this whining issue doesn’t look to be a corner case. This should have been discovered early in development or during beta testing. Maybe it wasn’t discovered with the SMAS because the whining was so low. However any audio testing using a Audio Precision tester would have discovered the issue.
It’s still too early to make any conclusions, you are right. I just don’t like the blame it on a bad 5V rail since I have my RME Babyface which runs great.
The beta testing is interesting as they did do a beta involving pimax owners prior to release.
As for serial number/batch tracking is also good to explore. However even that may not yield anticipated results as I believe we have some early 8kX receivers with also some in latet batches. So if it is a component it is possible tge supplier of said component may have a low fall out.
Howevet I am sure pimax has likely implented testing on the Vision models for this identified issue.
A friend of mine happened to noticed in a place we worked where the robot had an issue hitting a fixture creating a set of bad parts. They had been trying to figure out this random occurrence for over a month. When he happened by chance to be watching at a time to witness it. By the g code this random smacking tge fixture should not be happening. Iirc they were later able to discover the robot had a failing component.
Ideally with the testing you both have performed. A best test would be someone local to compare with that is not having this issue to test on each other’s system.
One of your usb audio devices used in the hmd’s usb-c port would also be a good test to see if your device experiences issues.
This would suggest an hmd defect if there are folks not experiencing this. Maybe a defect component or assembly error(ie routing a wire in wrong spot.)
I created a cable of my own like so (same as not fully inserting):
3.5 mm (TRS) male plug going into the left socket on the headset (wired as usual) and 3.5 mm (TRS) sockets wired with only the tip as positive (left or right depending on which side it is) and the ring as negative and no connection on the sleeve.
The TRRS plugs on the DMAS are wired in a weird way and that seems to be the cause.
Mine measure about 6.8 ohm between the tip and ring on the plugs so they’re very low impedance which could explain the noise that people are experiencing when not using a splitter inserted to the left socket on the headset.
I think what happens when only having one side connected and restarting the headset is that the DAC/Amp inside probably switches gain (lower gain).
Seems to me that the output impedance of the headset DAC/Amp doesn’t match the input impedance of the DMAS very well (maybe there are different revisions causing different experiences?).
Same thing often happens when trying to drive low impedance IEMs of of a desktop amp.
Disclaimer: My tests have been conducted on a very early version of the DMAS…
