Beamforming Microphone Translator: Four-Mic Array Limits
A four-microphone array is now a standard specification line on most AI translation hardware, and it is also the specification line most often misread during procurement. The array is not a single feature; it is a geometry, a set of filters and a policy about which direction the device listens in. What it buys you is a better ratio between the person speaking and everything else in the room. What it does not buy you is a device that works in every acoustic environment, and no supplier can honestly promise that.
What beamforming actually does
With four microphones at fixed spacing, the device can compare arrival times across the array and favour one direction over others. That is beamforming. The practical effect is that a voice coming from the front is treated differently from traffic, a ventilation grille or a neighbouring table. The array also feeds the noise reduction voice device stage, which decides what to keep and what to suppress. Both stages depend on the housing: port placement, gasket sealing, the gap between microphone and enclosure, and how the device is held. A good array in a poor acoustic body underperforms a modest array in a well-sealed one. This is why the same silicon appears in devices that behave very differently in the field.
Where the improvement is real
Directional pickup helps most in three situations: a single talker with steady background noise, a talker at a consistent distance and angle, and hands-free use where the device sits on a table rather than at the mouth. It helps least when several people speak at similar levels, when the talker moves around the device, or when the noise is impulsive and broadband. Buyers evaluating a pocket translator or a set of translation earbuds should test in the environments the end user will actually occupy, not in a quiet meeting room. Earbuds sidestep part of the problem because the microphone sits at the ear canal and the talker's own voice arrives by bone and tissue conduction, which is a different signal path from a tabletop array.
What the array does not fix
It does not fix overlapping speech, and it does not fix a translation engine that lacks domain vocabulary. A street test with one talker and passing vehicles is a favourable case; a market with three vendors calling at once is not. It also does not fix latency, which is a pipeline decision rather than an acoustic one, and it does not fix the case where the user covers a port with a hand. Finally, the array has nothing to do with whether the translation output is accurate. Output is a reference translation, and the buyer should treat it as such in the user manual and in any marketing claim.
| Decision point | What to ask | Why it matters |
|---|---|---|
| Array geometry | Microphone count, spacing and port placement in the housing | Determines the achievable directivity before any software tuning |
| Firmware revision | Which build was used for the evaluation sample | Array tuning changes between builds; a good sample can regress after an update |
| Test conditions | Room, talker distance, talker angle, background type | Without conditions, a performance claim cannot be compared between suppliers |
| Use case | Tabletop, handheld or ear-level | Each placement favours a different microphone strategy |
| Certification scope | CE RED (EN 300 328, EN 301 489, EN 62368-1) and FCC Part 15 B/C booked per hardware revision | Radio and safety scope is tied to the build, not to the product family |
| Documents | RoHS 3, REACH SVHC screening, battery UN38.3 and SDS | Importer obligations and customs clearance depend on the file being complete |
Procurement and compliance questions
Acoustic claims are not the only place where a specification sheet can mislead. Ask for the document pack per model and hardware revision, and confirm that the radio scope has been booked with an accredited laboratory rather than inherited from an earlier build. For a device with a display, confirm the software licensing position, because Google Play and GMS are not licensed by default. If the device is aimed at children, the toy scope (EN 71-1/-2/-3, EN 62115, Toy Safety Directive 2009/48/EC) follows the age grading printed on the packaging and is booked per build. If a camera or a wellness feature is involved, keep the language clean: health metrics are wellness guidance, never diagnosis.
- Fix the use case and the acoustic environment before choosing an array configuration.
- Request evaluation samples at the firmware revision that will ship, and re-test after any tuning change.
- Confirm the certification and document scope for the exact hardware revision.
- Agree the MOQ tier, packaging and white-label level in writing before tooling.
- Decide who holds importer duties: WEEE, BattG, DEEE/Triman and EORI/VAT sit with the importer.
Commercial terms and where to say no
Published factory policy is straightforward: MOQ is 500 units, logo 500, custom packaging 1,000, firmware or app white-label 2,000, AI glasses 300, ring, education and companion models 1,000, and service robots quoted per project from 50 units. Samples run 3-5 days for stock and 7-15 days configured, with sample cost credited against mass production. Production is 25-35 days, 30-40 for education and 12-20 weeks for ODM tooling, on EXW, FOB Shenzhen or DDP air and sea. Warranty is 12 months with 2 % free replacement parts shipped with the order, and QC gates run IQC, IPQC, FQC and OQC at AQL 2.5 major and 4.0 minor. Say no to a supplier who will not name the firmware build, will not state test conditions, or offers a certificate that is not tied to your hardware revision. The MOQ, sampling and lead times page sets out the tiers, and firmware and app customisation explains what white-label actually covers.
If you are building a category range rather than a single SKU, the same array discussion applies to AI glasses with translation and to a handheld AI guide player, though the ergonomics differ. The AI device line shows how the platforms are grouped, and the factory page describes the build and test flow. Send the use case, the target markets and the firmware revision you intend to ship to our team, and we will return a configuration with the test conditions stated in writing.
Questions buyers ask
Does a four-microphone array make a translator work in a noisy street?
It improves the ratio between the talker and the surrounding noise, and it helps the device decide which direction to listen in. It does not remove the problem of a cafe where several people speak at once, and it does not replace the acoustic design of the housing.
What should a buyer ask for instead of a decibel claim?
Ask for the test conditions, the reference hardware revision and the recording setup used during evaluation. Ask which firmware build was measured and whether the array tuning changes with that build.
Related: more on ai translation · buyer guides · customisation tiers