@sdetweil I finally managed to make it work:

On client side (old Android Lollipop box) I am using RtpMic app: it is good, simple and effective. It can start at boot and start streaming mic input via RTP.
I configured it with remote MagicMirror IP, 47474 port (just picked one) and g722 codec (good balance between quality and bandwidth, it just uses 0,09 Mbps)

On server side (MM running on Debian cloud-hosted VM), at first, I would like to only rely on PulseAudio default RTP capabilities.
Unfortunately, I still couldn’t get my PA to receive the RTP stream from RtpMic (though I’m quite sure it is possible, but I keep getting “Unsupported SAP” error) so ATM I workaround this using ffplay:

sudo apt install ffmpeg
ffplay rtp://[local IP]:47474 -acodec g722 -nodisp

(note that local MM IP goes here, not client IP)
You can check the stream flowing in pavucontrol.

Now that RTP stream is correctly flowing, I configure ALSA layer to use Pulseaudio by default (this is needed because GA module relays on ALSA, and Alexa module relays on Sox). This is achieved by creating the file “.asoundrc” under MM user home, and writing the following configuration in it:

pcm.!default pulse
ctl.!default pulse

As a last step, I install and configure GA like that:
micConfig: { // put there configuration generated by auto-installer
recorder: “arecord”,
},
When started, GA module (and virtually any other module) is able to receive voice commands from remote client.

Please note that this solution only cover one way (MM input), from client (running browser) to server (running MM in serveronly mode), the other way (MM output) is already covered by MM playing its audio output inside the browser by default.
This way you can have MM running on any machine in any remote place, and have your mirror displayed by any browser capable client (even an Android one).
Also, I had to use RtpMic/ffplay because my client is Android (so no PulseAudio), but I’m quite confident the same schema can be applied natively on any other PulseAudio capable device.

@sdetweil I finally managed to make it work:

On client side (old Android Lollipop box) I am using RtpMic app: it is good, simple and effective. It can start at boot and start streaming mic input via RTP.
I configured it with remote MagicMirror IP, 47474 port (just picked one) and g722 codec (good balance between quality and bandwidth, it just uses 0,09 Mbps)

On server side (MM running on Debian cloud-hosted VM), at first, I would like to only rely on PulseAudio default RTP capabilities.
Unfortunately, I still couldn’t get my PA to receive the RTP stream from RtpMic (though I’m quite sure it is possible, but I keep getting “Unsupported SAP” error) so ATM I workaround this using ffplay:

sudo apt install ffmpeg
ffplay rtp://[local IP]:47474 -acodec g722 -nodisp

(note that local MM IP goes here, not client IP)
You can check the stream flowing in pavucontrol.

Now that RTP stream is correctly flowing, I configure ALSA layer to use Pulseaudio by default (this is needed because GA module relays on ALSA, and Alexa module relays on Sox). This is achieved by creating the file “.asoundrc” under MM user home, and writing the following configuration in it:

pcm.!default pulse
ctl.!default pulse

As a last step, I install and configure GA like that:
micConfig: { // put there configuration generated by auto-installer
recorder: “arecord”,
},
When started, GA module (and virtually any other module) is able to receive voice commands from remote client.

Please note that this solution only cover one way (MM input), from client (running browser) to server (running MM in serveronly mode), the other way (MM output) is already covered by MM playing its audio output inside the browser by default.
This way you can have MM running on any machine in any remote place, and have your mirror displayed by any browser capable client (even an Android one).
Also, I had to use RtpMic/ffplay because my client is Android (so no PulseAudio), but I’m quite confident the same schema can be applied natively on any other PulseAudio capable device.

yeah :) I’ll let you know in case the dream would turn true :)

I understand the standard deploy for a Magic Mirror is a all-in-one device, but since a “server mode” exists… should be reasonable to think about a 2-tier setup.
In my specific case I have an old Android Lollipop box I would like to repurpose as a Magic Mirror frontend (it is small and can run a browser, no way to put another OS on it), and I’ve got plenty of horsepower on a remote hypervisor (on which I deployed a Debian VM with MM on it)

@sdetweil that’s a pity :) Thank you

Thanks for your feedback.
So, if I understand this correctly, there’s no way to make any snowboy-based module work with remote audio, at the moment. Right?

Hello,
I’m wondering how Google Assistant module (and other voice activated modules also) are supposed to work with a server only setup.
Is it possible to have audio input and output on the client, and let them communicate with the module in the backend?
I see there are modules that can stream audio to the client (browser) using HTML5, can this be done for MMM-GoogleAssistant Module?
My goal is to have a MagicMirror istance running on a remote server in the cloud (no phisical audio), and a browser running on android box at client side (home).

Thank you in advance

I did literally nothing but remove any value from “micConfig:” section in MMM-GoogleAssistant.

But now that you make me double check, I saw that this does not defaults the recorder to “sox”. It actually defaults to “arecord” again.

Then actually, the working step is removing directive
device: “plughw:0”

It somehow prevents GA to try going directly “under” PulseAudio, and makes it use the PulseAusio ALSA plugin instead.
Once both goes through PulseAudio, they can work together, as PulseAudio cam make multiple wave recorders work by default

I finally managed to make it work. Actually it was easier than I thought.
The problem was in my initial MMM-GoogleAssistant configuration.
I try to give some details.

Background: As far as I understood there are multiple layers in Linux audio. Put very raw: PulseAudio is frontend, sitting on ALSA that controls underlying hardware (so PA -> ALSA -> OS -> HW).
PulseAudio’s job is exactly to take care and manage multpiple audio flows at a higher locigal level, so it IS capable of managing multiple applications accessing same in/out channels

MMM-awesome-alexa uses SOX by default, and there is no (easy) way to configure it. SOX uses PulseAudio by default (which is OK)

MMM-Google Assistant can be configured to use SOX (so PulseAudio) OR ALSA directly.

I initially had my GA configured to use ALSA, like that:
micConfig: { // put there configuration generated by auto-installer
recorder: “arecord”,
device: “plughw:0”,
},

This is OK for standalone, but binding directly to ALSA makes PulseAudio unable to manage multiple access to the mic (by Alexa, for example)

It was enough to configure GA to use SOX (which is actually the default, for a reason):
micConfig: { // put there configuration generated by auto-installer
},
This way both GA and Alexa go through PulseAudio, which is capable to make them work together.

I hope my poor English was enough to make it clear.

PS: I am unaware if PulseAudio layer is available on Raspberry OS, I am using Debian Buster on x86 VM where it is installed and available by default

I’ll try and let you know. Thank you!

Thanks for your feedback.
That actually does make sense.
What about “virtualizing” mic layer with ALSA? (I read something about “aliasing” hd devices, if I’m not wrong).
Otherwise, could adding a second hw mic solve the problem in your opinion?

Thank you,
Daniele