Bug 246728 - net/freerdp : microphone forwarding not working
Summary: net/freerdp : microphone forwarding not working
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Kyle Evans
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-25 20:53 UTC by bergerkos
Modified: 2020-05-31 02:47 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (kevans)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bergerkos 2020-05-25 20:53:39 UTC
Microphone stopped working after the ports upgrade. It's now version 2.0.0.r4_8 and microphone forwarded to bhyve Win 10 host gives no sound. Speakers work fine just as they used to, it's only the microphone.

I'm using my old command line:
xfreerdp -grab-keyboard /bpp:24 /w:1600 /h:960 /v:$myIP /u:$user /p:"$pass" /network:auto /gfx /gfx-h264:avc444 /dvc:video,sys:oss /clipboard /fonts /sound:sys:oss,dev:4 /microphone:sys:oss,format:1

I tried the /microphone... option with and without the addition of dev:4, just as in /sound, but that affects nothing.

Build options include:
	ALSA           : off
	CUPS           : off
	FAAC           : off
	FAAD           : on
	FFMPEG         : on
	GSM            : off
	GSTREAMER      : off
	ICU            : on
	KERBEROS       : on
	LAME           : on
	MANPAGES       : on
	OPENH264       : on
	PCSC           : off
	PULSEAUDIO     : off
	SOXR           : on
	SSE            : on
	WAYLAND        : off
	X11            : on
Comment 1 Steve Wills freebsd_committer 2020-05-26 00:20:21 UTC
(In reply to bergerkos from comment #0)
Hi,

I didn't even know this was possible! But it's an interesting feature and I am going to find useful.

I rebuilt with these options:

[00:00:01] ===> The following configuration options are available for freerdp-2.0.0.r4_8:
[00:00:01]      ALSA=on: ALSA audio architecture support
[00:00:01]      CUPS=on: CUPS printing system support
[00:00:01]      FAAC=off: FAAC AAC encoder support
[00:00:01]      FAAD=off: FAAD AAC decoder support
[00:00:01]      FFMPEG=on: FFmpeg support (WMA, AIFF, AC3, APE...)
[00:00:01]      GSM=off: GSM codec support
[00:00:01]      GSTREAMER=on: Multimedia support via GStreamer
[00:00:01]      ICU=on: Unicode support via ICU
[00:00:01]      KERBEROS=on: Kerberos support
[00:00:01]      LAME=off: LAME MP3 audio encoder support
[00:00:01]      MANPAGES=on: Build and/or install manual pages
[00:00:01]      OPENH264=on: H.264 video codec support via OpenH264
[00:00:01]      PCSC=off: Smart card support (smart card device redirection)
[00:00:01]      PULSEAUDIO=on: PulseAudio sound server support
[00:00:01]      SOXR=off: SoX resampler support via libsoxr
[00:00:01]      SSE=on: Use SSE optimized routines
[00:00:01]      WAYLAND=on: Build FreeRDP Wayland client
[00:00:01]      X11=on: Build FreeRDP X11 client

After I looked up some of the command line options for xfreerdp:

https://github.com/FreeRDP/FreeRDP/wiki/CommandLineInterface

I tried xfreerdp with these options:

xfreerdp -grab-keyboard -decorations /bpp:24 /w:1920 /h:1080 /v:$myIP /port:3389 /u:$myuser /p:$mypass /network:auto /cert-ignore /clipboard /fonts /gfx /gfx-h264:avc444 /dvc:video,sys:oss /sound:sys:oss,dev:6 /microphone:sys:oss,dev:10,format:1

(my mic is a USB camera which shows up on a different oss device from my speakers)

and it worked for me! So I think this issue may not be a net/freerdp issue.

Side note, I had to enable a separate setting in the remote firefox, see:

https://support.mozilla.org/en-US/kb/i-cant-play-audio-remote-desktop-connection

I tested the mic via this site in the remote browser:

https://www.podcastinsights.com/online-mic-test/

The microphone name is simply "Remote Audio" in Firefox. When it works, I see this in the output of xfreerdp:

[20:01:27:747] [59265:0826b000] [INFO][com.freerdp.channels.audin.client] - open: /dev/dsp10
[20:01:43:110] [59265:0826b000] [INFO][com.freerdp.channels.audin.client] - close: /dev/dsp10
[20:02:55:951] [59265:08a14400] [INFO][com.freerdp.channels.audin.client] - open: /dev/dsp10
[20:10:35:476] [59265:08a14400] [INFO][com.freerdp.channels.audin.client] - close: /dev/dsp10
[20:10:49:123] [59265:082a1700] [INFO][com.freerdp.channels.audin.client] - open: /dev/dsp10

I also found that if I do use the pulse backend for output, I can still successfully use oss backend for input. Didn't test alsa. Confirmed I'm using freerdp-2.0.0.r4_8. Also using Win 10 in a bhyve VM.
Comment 2 bergerkos 2020-05-26 06:20:11 UTC
Yes, it IS possible, and I've been using this feature for about 1 year now to connect to bhyve Win 10 host with sound. That worked perfectly well and I was even able to stop using VMPlayer for Win 10 virtualization and switch over to bhyve. So at least this report achieved this: now you can use this feature :) 

But suddenly it stopped working for me. According to your post (as I partly suspected), the problem is NOT in the freerdp update but in some particulars of my sound system.


Perhaps I'll have to contact the snd_hda devs to put things straight. One problem I'm experiencing is that mic is heard in speakers. The second one is this. But since normally it all works out of the box, there is little documentation as to what could be done to handle this...
Comment 3 bergerkos 2020-05-31 02:47:20 UTC
Ok, the microphone sound disappearance was due to the option SOXR = on.
I don't know how this works and how my other options, perhaps, coincide with this one so that the mic forwarding doesn't give sound. But the fact is, with the following configuration no sound:
        ALSA           : off
	CUPS           : off
	FAAC           : off
	FAAD           : on
	FFMPEG         : on
	GSM            : off
	GSTREAMER      : off
	ICU            : on
	KERBEROS       : on
	LAME           : on
	MANPAGES       : on
	OPENH264       : on
	PCSC           : off
	PULSEAUDIO     : off
	SOXR           : on
	SSE            : on
	WAYLAND        : off
	X11            : on

When I turn SOXR off, it works. Another thing worth mentioning, al least on my hardware. With the configuration above, when OPENH264 = off, the sound is horrible. 

This far, it works fine again.