prevent mic sound from going to speakers

F

free-and-bsd

Hello! When I use the mic it is heard in the speakers. And it is even much louder than multimedia playback.
But my question is: how can I prevent microphone signal from going to speakers?
Here is dmesg for my onboard sound that I'm using:
Code: 
hdaa4: <Realtek ALC887 Audio Function Group> at nid 1 on hdacc4
hdaa4: Subsystem ID: 0x10ec0887
hdaa4: NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1
hdaa4:  GPIO0: disabled
hdaa4:  GPIO1: disabled
hdaa4: Original pins configuration:
hdaa4: nid   0x    as seq device       conn  jack    loc        color   misc
hdaa4: 17 40130000 0  0  Speaker       None  ATAPI   0x00       Unknown 0
hdaa4: 18 411111f0 15 0  Speaker       None  1/8     Rear       Black   1
hdaa4: 20 01014010 1  0  Line-out      Jack  1/8     Rear       Green   0
hdaa4: 21 01011012 1  2  Line-out      Jack  1/8     Rear       Black   0
hdaa4: 22 01016011 1  1  Line-out      Jack  1/8     Rear       Orange  0
hdaa4: 23 0101e014 1  4  Line-out      Jack  1/8     Rear       White   0
hdaa4: 24 01a19030 3  0  Mic           Jack  1/8     Rear       Pink    0
hdaa4: 25 02a19040 4  0  Mic           Jack  1/8     Front      Pink    0
hdaa4: 26 0181303f 3  15 Line-in       Jack  1/8     Rear       Blue    0
hdaa4: 27 02214020 2  0  Headphones    Jack  1/8     Front      Green   0
hdaa4: 28 411111f0 15 0  Speaker       None  1/8     Rear       Black   1
hdaa4: 29 4025e601 0  1  Headphones    None  Optical 0x00       White   6
hdaa4: 30 411111f0 15 0  Speaker       None  1/8     Rear       Black   1
hdaa4: 31 411111f0 15 0  Speaker       None  1/8     Rear       Black   1
hdaa4: Patching widget caps nid=29 0x00400400 -> 0x00700400
hdaa4: Patched pins configuration:
hdaa4: nid   0x    as seq device       conn  jack    loc        color   misc
hdaa4: 17 40130000 0  0  Speaker       None  ATAPI   0x00       Unknown 0 DISA
hdaa4: 18 411111f0 15 0  Speaker       None  1/8     Rear       Black   1 DISA
hdaa4: 20 01014010 1  0  Line-out      Jack  1/8     Rear       Green   0
hdaa4: 21 01011012 1  2  Line-out      Jack  1/8     Rear       Black   0
hdaa4: 22 01016011 1  1  Line-out      Jack  1/8     Rear       Orange  0
hdaa4: 23 0101e014 1  4  Line-out      Jack  1/8     Rear       White   0
hdaa4: 24 01a19030 3  0  Mic           Jack  1/8     Rear       Pink    0
hdaa4: 25 02a19040 4  0  Mic           Jack  1/8     Front      Pink    0
hdaa4: 26 0181303f 3  15 Line-in       Jack  1/8     Rear       Blue    0
hdaa4: 27 02214020 2  0  Headphones    Jack  1/8     Front      Green   0
hdaa4: 28 411111f0 15 0  Speaker       None  1/8     Rear       Black   1 DISA
hdaa4: 30 411111f0 15 0  Speaker       None  1/8     Rear       Black   1 DISA
hdaa4: 31 411111f0 15 0  Speaker       None  1/8     Rear       Black   1 DISA
hdaa4: 4 associations found:
hdaa4: Association 0 (1) out:
hdaa4:  Pin nid=20 seq=0
hdaa4:  Pin nid=22 seq=1
hdaa4:  Pin nid=21 seq=2
hdaa4:  Pin nid=23 seq=4
hdaa4: Association 1 (2) out:
hdaa4:  Pin nid=27 seq=0
hdaa4: Association 2 (3) in:
hdaa4:  Pin nid=24 seq=0
hdaa4:  Pin nid=26 seq=15
hdaa4: Association 3 (4) in:
hdaa4:  Pin nid=25 seq=0
hdaa4: Tracing association 0 (1)
hdaa4:  Pin 20 traced to DAC 2
hdaa4:  Pin 22 traced to DAC 4
hdaa4:  Pin 21 traced to DAC 3
hdaa4:  Pin 23 traced to DAC 5
hdaa4: Association 0 (1) trace succeeded
hdaa4: Tracing association 1 (2)
hdaa4:  Pin 27 traced to DAC 37
hdaa4: Association 1 (2) trace succeeded
hdaa4: Tracing association 2 (3)
hdaa4:  Pin 24 traced to ADC 8
hdaa4:  Pin 26 traced to ADC 8
hdaa4: Association 2 (3) trace succeeded
hdaa4: Tracing association 3 (4)
hdaa4:  Pin 25 traced to ADC 9
hdaa4: Association 3 (4) trace succeeded
hdaa4: Looking for additional DAC for association 0 (1)
hdaa4: Looking for additional DAC for association 1 (2)
hdaa4: Looking for additional ADC for association 2 (3)
hdaa4: Looking for additional ADC for association 3 (4)
hdaa4: Tracing input monitor
hdaa4:  Tracing nid 11 to out
hdaa4:  nid 11 is input monitor
hdaa4:  Tracing nid 34 to out
hdaa4:  Tracing nid 35 to out
hdaa4: Tracing other input monitors
hdaa4:  Tracing nid 24 to out
hdaa4:  Tracing nid 25 to out
hdaa4:  Tracing nid 26 to out
hdaa4: Tracing beeper
hdaa4: Pin sense: nid=20 sense=0x80000000 (connected)
hdaa4: Pin sense: nid=24 sense=0x80000000 (connected)
hdaa4: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref
pcm4: <Realtek ALC887 (Rear Analog 7.1/2.0)> at nid 20,22,21,23 and 24,26 on hdaa4
pcm5: <Realtek ALC887 (Front Analog)> at nid 27 and 25 on hdaa4
hdaa4: Pin sense: nid=24 sense=0x00000000 (disconnected)
hdaa4: Pin sense: nid=26 sense=0x80000000 (connected)
hdaa4: Pin sense: nid=26 sense=0x00000000 (disconnected)
hdaa4: Pin sense: nid=24 sense=0x80000000 (connected)
So, nid=20 there is Green jack, speaker, and nid=24 is Red, microphone. Now how is is generally handled, when signal from the microphone is heard in the speakers?
 
So, does anybody know the answer? I didn't think this was such a tricky question :(((
I can add that in Linux it works perfectly well, only FreeBSD seems to be affected this way.
And now, for some obscure reason, microphone forwarded via [PMAN=]net/xfreerdp[/PMAN] doesn't work any more. Multiple ports were updated, now microphone is forwarded, but it's mute.

This being the case, as doesn't work "out of the box" any more, some tweaking options must be available...
Would be very unfortunate to have to resort to Linux because of this little problem... Because in Linux it all works fine, just as it used to.
 
Oh, the question is: what config options can I try to prevent the sound from my microphone from going into the speakers?
Thank you :)
 
There are no options to do anything like that in the driver. We need details. Which software you have tried? Was it working before? How many issues are actually there? I mean, freerdp problem looks completely different. I'm not sure it's even possible to have both these issues at the same time.
 
What you're looking for is called "echo cancellation" and it's one of those difficult problems in audio processing. It's usually handled at the application layer, like shkhln says.
 
Jose said:
What you're looking for is called "echo cancellation" and it's one of those difficult problems in audio processing. It's usually handled at the application layer, like shkhln says.
Click to expand...
Well it's not echo, in fact. Even when I RUB the microphone I hear it in the speakers. So it's no mistake the signal goes directly to the speakers.
 
shkhln said:
There are no options to do anything like that in the driver. We need details. Which software you have tried? Was it working before? How many issues are actually there? I mean, freerdp problem looks completely different. I'm not sure it's even possible to have both these issues at the same time.
Click to expand...
Yes it is a different issue, just I'm as clueless about the one as I am about the other. Which software? Only multimedia/ffmpeg and multimedia/vlc with OSS driver, that's all. No pulseaudio even.
With net/freerdp it just worked. Then again, the forwarded speakers still work , it's only the mic that does not.
 
What you describe is called "sidetone" or "mic monitoring" and appears to only be a feature on gaming headsets. Strange...
 
Jose said:
What you describe is called "sidetone" or "mic monitoring" and appears to only be a feature on gaming headsets. Strange...
Click to expand...
Yes, I also thought about the term "monitoring" :). The funny thing is it's only here in FreeBSD. For the purity of experiment I'm going to check with my alt 13.0-RELEASE install and a different user account.
 
When I use my "professional" headphones sound from mic is not a problem (separate jack for mic) but sometimes is hard to carry those big headphones so instead I use one pair from my phone and the mic sound can be heard. All I have to do is to "mute" mic from mixer ( mixer mic 0) and problem solved. Maybe this solution works for you too.
 
  • Thanks
Reactions: a6h
Minbari said:
When I use my "professional" headphones sound from mic is not a problem (separate jack for mic) but sometimes is hard to carry those big headphones so instead I use one pair from my phone and the mic sound can be heard. All I have to do is to "mute" mic from mixer ( mixer mic 0) and problem solved. Maybe this solution works for you too.
Click to expand...
Well, I actually turn the mic down a bit, yes. But that's a workaround kind of. Pure scientific satisfaction comes from subduing it and making it serve mankind for good, you know :).
 
Alain De Vos said:
When the mix channels are put to zero it looks like a hardware problem to me.
Click to expand...
It would -- if it behaved the same way in other OSs. But as I described, it only happens when forwarding my (otherwise working) microphone to bhyve hostguest (Win 10) works normally under Linux. So then, it's NOT a hardware problem.
And it's a very specific problem, hard to pin down. And net/freerdp has nothing to do with that, nor has bhyve -- because bhyve is the same and with the updated version of net/freerdp it works fine for other people just as it did for me.
 
Last edited:
Ok, the disappearance of microphone sound in net/freerdp was due to the option "SoXR reasampling via libsoxr". Have no idea how it works, but with conjunction with my other options this command line xfreerdp ... /sound:sys:oss,dev:4 /microphone:sys:oss,dev:4,format:1 forwards microphone and playback device to the Win 10 guest, but microphone gives no sound. Here are my build options with which everything works fine:
Code: 
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           : off
SSE            : on
WAYLAND        : off
X11            : on
 
Updates! Whatever was the problem, it's gone in CURRENT (installed that from available snapshots): (1) no unwanted microphone "monitoring" in speakers and (2) snd_hda working fine in bhyve Win10 guest.
So, it's solved.

CONCLUSION: as my present system is a result of continuous update since 9.0-RELEASE, it has inherited some settings from the setup that was mentioned in the HOWTOs at that time. Namely, my /etc/devfs.conf file contained certain rules to create dsp* devices. But the present version of Handbook doesn't encourage that as OSS sound subsystem creates the needed devices automatically on the fly. I wonder it is needed at all to put anything into the files /etc/devfs.conf and /etc/devfs.rules. Looks like most stuff happens automatically these days?
 
You must log in or register to reply here.
Back
Top