goke-osdrv-gk7205v200: ship the VQE engines the microphone path loads by dlopen - #2362
Draft
openipc-ai wants to merge 1 commit into
Draft
goke-osdrv-gk7205v200: ship the VQE engines the microphone path loads by dlopen#2362openipc-ai wants to merge 1 commit into
openipc-ai wants to merge 1 commit into
Conversation
… by dlopen The Goke half of the change that installs the voice quality enhancement engines for OpenIPC/majestic#287. The HiSilicon side landed separately; this is kept apart because it is the only part that adds binaries to the tree and the only part with no hardware here to run it on. Same mechanism as HiSilicon. libupvqe.so is only the framework: it dlopen()s one shared object per DSP stage when HI_MPI_AI_EnableVqe runs, resolving names from a "lib%s_%s.so" template, and it prints dlopen libvqe_common.so/libsecurec.so or %s failed when they are absent. Goke names them libvqe_* where HiSilicon names them libhive_*. Only the stages majestic can switch on are installed: the high-pass filter, noise reduction and automatic gain control of the 8/16 kHz talk engine, libvqe_common.so which is a NEEDED of the last two, and the 48 kHz record engine. Echo cancellation and the equaliser are not exposed, and the resampler is compiled into libupvqe.so itself (RES_ReSampler_* are defined there), so libvqe_res.so is never loaded. They sit in files/vqe/ rather than files/lib/ because this package installs files/lib/* wholesale, and there is no other way to keep 360 KB out of a lite image where majestic has no VQE compiled in to load them. Provenance: the five libraries come from the GK7205V200 vendor SDK drop, the same drop the twenty libraries already in files/lib/ came from. Each of those twenty was checked byte-identical to a file in that drop before these five were copied from it, and libupvqe.so -- the loader that will dlopen them -- is one of the twenty. Not validated on hardware. There is no GK7205V200 on the bench, and matching provenance and an identical dlopen mechanism are not the same as watching the enable call succeed on the part. Holding this until someone can run it.
openipc-ai
force-pushed
the
audio-vqe-engines-goke
branch
from
September 4, 2026 17:35
c4723a4 to
2aa1583
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Goke half of #2361, split out because it is the only part that adds binaries and the only part with no hardware to validate it on.
Do not merge until someone runs it on a GK7205V200. Opened as a draft so the work is not lost and is ready the moment a board is available.
What it does
Identical mechanism to the HiSilicon side.
libupvqe.sois only the framework — itdlopens one shared object per DSP stage whenHI_MPI_AI_EnableVqe()runs, resolving names from alib%s_%s.sotemplate, and printsdlopen libvqe_common.so/libsecurec.so or %s failedwhen they are missing. Goke names themlibvqe_*where HiSilicon names themlibhive_*.Installs only the stages majestic can switch on —
libvqe_hpf,libvqe_anr,libvqe_agc,libvqe_common(aNEEDEDof the last two, not a stage), andlibvqe_recordfor the 48 kHz path. AEC and EQ are not exposed; the resampler is compiled intolibupvqe.soitself (RES_ReSampler_*are defined there), solibvqe_res.sois never loaded.Gated
ifeq ($(OPENIPC_MAJESTIC),ultimate), and placed infiles/vqe/rather thanfiles/lib/because this package installsfiles/lib/*wholesale and there is no other way to keep 360 KB out of a lite image.Provenance
The five libraries come from the GK7205V200 vendor SDK drop — the same drop the twenty libraries already in
files/lib/came from. Before copying these five I verified every one of those twenty is byte-identical to a file in that drop,libupvqe.so(the loader that willdlopenthese) among them.That satisfies the checklist's success criterion as written — "traces to a vendor SDK release or to a source tree the build system compiles" — but provenance is not runtime validation, which is the open question below.
What is missing
No GK7205V200 on the bench. Matching provenance and an identical
dlopenmechanism are not the same as watching the enable call succeed on the part, and I am not willing to claim otherwise.What needs running on a real board, on an ultimate image built from this branch:
audio.enabled: true,audio.srate: "8000",audio.vqe: true.talk VQE on at 8000 Hzwith nodlopen ... failedorcreate vqe failon the console.http://<cam>/audio.pcmwithvqe: falseand again withvqe: true, same room, and compare energy in 20–80 Hz against 300–1000 Hz. The high-pass filter should cut the former by an order of magnitude and leave the latter alone.For reference, that test on the two HiSilicon boards in #2361 gave:
If any engine turns out to be ABI-incompatible with the shipped Goke userspace, the fix is to take the binaries from whichever SDK drop matches
libupvqe.soinfiles/lib/— but that is already the drop these came from.