Speaker/Headphone Output Mixed with Mic Input Stream

If I try to read the audio stream from microphone using sd.InputStream when another audio is being played in the machine, it records input from both mic and speaker. Therefore, the recorded audio includes the noise of background audio along with mic input. However, I have assumed that it would record only the input from the mic which is required in my use case. Is there any workaround? My code is given below:

stream_in = sd.InputStream(
    device=device_in,
    samplerate=args.sample_rate,
    channels=1)
stream_in.start()
frame, overflow = stream_in.read(length)

Here, I have passed the default pulse input device (from the list below) as device_in and sample_rate is set to 16000.

$ python -m sounddevice
  0 HDA Intel PCH: ALC3234 Alt Analog (hw:0,2), ALSA (2 in, 0 out)
  1 HDA Intel PCH: HDMI 0 (hw:0,3), ALSA (0 in, 8 out)
  2 HDA Intel PCH: HDMI 1 (hw:0,7), ALSA (0 in, 8 out)
  3 HDA Intel PCH: HDMI 2 (hw:0,8), ALSA (0 in, 8 out)
  4 HDA Intel PCH: HDMI 3 (hw:0,9), ALSA (0 in, 8 out)
  5 HDA Intel PCH: HDMI 4 (hw:0,10), ALSA (0 in, 8 out)
  6 hdmi, ALSA (0 in, 8 out)
  7 pulse, ALSA (32 in, 32 out)
* 8 default, ALSA (32 in, 32 out)

[malfatti]

I had a similar problem ~3 years ago. I tried everything to fix it, without success… until I noticed that, under alsamixer controls, there was a Loopback option enabled. After disabling it, I never had this problem again. To double check:

1. Open a terminal and enter alsamixer;
2. Press F6 and select your sound card ;
3. Press F5 to show all controls;
4. If there is a Loopback option, make sure it is disabled.

If, as @HaHeho suggested, the issue happens independently of the software used for recording, then this could be the cause of it.

Cheers 😃

[HaHeho]

Thanks for the audio examples. 😃

You indeed described accurately what you were encountering. However, it sounded very unlikely, so I wanted to make sure that we are not talking about acoustic feedback.

The behavior is of course unintended … and I have no idea why it happens. Although, I would say it is very unlikely caused by sounddevice. It is rather due to your code … most likely what is happening within the torch. I have no experience with that at all, but I could imagine it overrides the data inside frame during the processing? So maybe also the data in input_frames gets altered, since it is was given a reference and not a deep-copy.

But then again, I have no idea what exactly is happening in frame = torch.from_numpy(frame).to(args.device) (in particular the last part). Maybe an explicit deep-copy with frame = torch.from_numpy(frame.copy()).to(args.device) already does the trick?

In any case, what you should check first is that the behavior is still encountered without any torch processing. If not, then you know that you will have to look there. 😉