C++ integration (fork of meetingsdk-headless-linux-sample)
Auth: SDK JWT (own account). Regular meeting (not a webinar).
What works
Raw screen-share video: IZoomSDKShareSource::onStartSend → sendShareFrame (I420) → SDKERR_SUCCESS, visible to all participants.
Virtual mic audio: GetAudioRawdataHelper()->setExternalAudioSource() → onMicStartSend → IZoomSDKAudioRawDataSender::send(data, len, 48000, Mono) → SDKERR_SUCCESS, audible. (But this is voice-codec/mono — we need music-quality, hence share audio.)
The problem — share audio Following the header (rawdata_share_source_helper_interface.h) exactly:
Implemented IZoomSDKShareAudioSource; register the video + audio sources together: GetRawdataShareSourceHelper()->setExternalShareSource(m_videoSource, m_audioSource); → returns SDKERR_SUCCESS(0).
The SDK fires onStartSendAudio(IZoomSDKShareAudioSender* sender) — so a valid sender IS delivered.
On that sender, every sendShareAudio(...) call returns SDKERR_INVALID_PARAMETER(3).
We exhaustively ruled out the arguments (16-bit LE PCM, even data_length, silence buffers, from the capture thread):
sample_rate
channel
data_length
result
48000
Mono
960 bytes (10ms)
3
48000
Mono
480 (samples, not bytes)
3
44100
Mono
882 bytes
3
32000
Mono
640 bytes
3
16000
Mono
320 bytes
3
48000
Stereo
1920 bytes
3
All six are formats the header documents as supported. We also tried, with no change:
with and without IMeetingShareController::EnableShareComputerSound(true) (+ SetAudioShareMode(AudioShareMode_Stereo)) before the share started;
with and without JoinVoip();
10 ms and 20 ms frames.
The sibling IZoomSDKAudioRawDataSender::send() (identical signature, data,len,rate,channel) returns SUCCESS at mono/48000 in the same build — so the buffer, thread, and length semantics are correct. Only sendShareAudio rejects them.
Questions
Is sendShareAudio / custom share-audio (IZoomSDKShareAudioSource) supported on the Linux Meeting SDK 7.1.0, or is it Windows-only despite the header listing it? Every sendShareAudio success we can find publicly is on Windows; your Linux raw-data demos only show mic-send and video-share-send.
If supported, what exactdata_length / sample_rate / channel / preconditions make it return SDKERR_SUCCESS on Linux? A minimal working Linux snippet would settle it.
If it’s a known limitation, is it fixed in a later 7.x Linux build? (We can test 7.0.5 / newer.)
Impact: we can only send voice-codec mono audio on Linux today; hi-fi/stereo music into meetings is blocked purely by this.
Alright thanks ! I will be waiting anxiously, also I’ve opened an issue in github.
We tried implementing on a windows machine and in a windows machine it works,
the only problem is: we cannot go for the windows machines because it would be crazy expensive!
This is why we need the solution working on linux so we can afford it, we are working on a solution for our church so that it can stream its hymns online on certain days, and only in Portugal we are 24 churches, in the whole world it’s almost 5k. With a linux solution we would need way less machines and money to do the same thing, with windows we wouldn’t be able to afford it at all!
Solved — thanks @chunsiong.zoom! For anyone trying to send music (not just voice) into a normal Zoom Meeting from a headless Linux Meeting SDK app. Tested on Meeting SDK for Linux v7.1.0.
1. The share-audio path is a dead end on Linux IZoomSDKShareAudioSender::sendShareAudio() returned INVALID_PARAMETER (3) for every rate/channel combination I tried. Couldn't get it to work at all.
2. Use the regular audio channel — the virtual mic (exactly what you said) IZoomSDKAudioRawDataHelper::setExternalAudioSource() + IZoomSDKVirtualAudioMicEvent + IZoomSDKAudioRawDataSender::send().
Send mono, 16-bit, 48 kHz. Stereo is rejected with INVALID_PARAMETER (3) on this path.
data_length is in bytes and must be even.
Don't send from onMicInitialize — cache the sender and only start sending on onMicStartSend.
3. Fire onMicStartSend: start muted, then unmute
EnableAutoJoinAudio(true);
EnableAlwaysMuteMicWhenJoinVoip(true); // start muted
// once in-meeting:
JoinVoip();
UnMuteAudio(mySelf->GetUserID()); // the muted->unmuted transition fires onMicStartSend
4. The real fix: turn off Zoom's speech processing — but AFTER JoinVoip
By default the mic channel gets voice DSP (noise suppression / echo cancel / auto-gain) and music sounds squashed, like a phone held to a speaker. You turn it off via IAudioSettingContext — but the calls only take effect once you're actually in VoIP audio. Called before joining they return WRONG_USAGE (2) and silently do nothing.
auto* a = settingService->GetAudioSettings();
a->EnableMicOriginalInput(true); // "Original Sound" — enable FIRST; this is the one that fixes it
a->DisableEchoCancellation(true); // header: valid only if original input is on
a->EnableAutoAdjustMic(false); // no auto-gain
Call that after JoinVoip() + UnMuteAudio(). EnableMicOriginalInput(true) (Original Sound) is what makes music come through full and clean instead of squashed.
Notes
EnableHighFidelityMusicMode() and EnableStereoAudio() exist in the header but are under #if defined(WIN32) — not available on the Linux SDK, which is why this is Original Sound + mono.
SetAudioSignalProcessType(SDK_AUDIO_DEVICE_RAW_MODE_OFF) returns SUCCESS but its doc scopes it to Windows, so the effect on Linux is unverified — Original Sound is what did the work. (Careful: ..._OFF is the value that gives the unprocessed/raw signal; it reads backwards.)
SetSuppressBackgroundNoiseLevel(None) always failed for me (INVALID_PARAMETER 3), but it seems redundant once Original Sound is on.
Result: music now comes through clean and full. Hope it helps someone!
