Problem with Sound Input Read.vi -- it reads missing channel

[2014spring]

Hello there,

I'm using the Continuous Sound Input.vi in Labview 2014 as below (Device ID =0; Number of Samples/ch = 5000):

 

When I have both Left and Right channels plugged into mic input on my PC, I can read both channels with full scale (-1 to 1) which is correct. The problem I have is that when I unplug one channel,  the output from Sound Input Read.vi still shows centain level of signal for this missing channel (Left ch in this case) (see below). However, if I attentuate the mic input signals, the problem is gone -- the missing channel shows no reading from Sound Input Read.vi. Can someone tell me why the Sound Input Read.vi behaves this way? Is there any fix to this problem?

[RahRahMirez]

Hey 2014spring,

Can you explain what you mean by using a two channel mic input?  Also, could you please explain your display?

At first glance, it sounds like there might be noise inherent to your system and that the channel you've mentioned is picking up noise.  Or perhaps there's some kind of grounding that needs to be happening?

Let me know in a little more detail your system set up and maybe that will help lend some clarity.

[2014spring]

Hi Chris,

My test setup is very simple: a stereo audio cable with two RCA connectors (for left and right channels) at one end and a 3.5mm plug at the other end is connected between DUT and PC (stereo mic port 3.5mm Jack). The display shows the audio waveforms (left and right channel) from the Sound Input Read.vi. In the block diagram, it's the "Audio" indicator.

First I thought it was a problem with Labview sound input vis. But then I found actually there was very weak sound from the missing channel when I plugged in my earphone into PC (earphone port) and listened very carefully to it. The test signal is just a 1KHz tone and that's what I hear and that's what shows in the waveforms (if expanded the window). The measured frequency is also correct. So I know it's not noise related. The rough conclusion we can make here is that the audio signals from DUT are too strong for the mic circuit and sound card on the PC. The channel signals got screwed up somewhere. If you have more insights about this, please kindly share.

Thank you very much!

Regards,

Spring 

[RahRahMirez]

It could be crosstalk in the cable.  If you are trying to do this with great isolation, you will need a high quality cable.

There's a possibility the audio jack is a mono jack--verify that the jack is stereo, and that the audio processing on the system is sufficient to avoid crosstalk (shielding). 

Because this isn't LabVIEW I'm not really sure how much help I can be beside what I just mentioned above, just to give fair warning.

[2014spring]

Hi Chris,

With the same cable and same test setup, the "crosswalk" scenario on my other PC is very minimum. So I think it was a problem with my original PC. To deal with the worst case, I've added an In-Line volume control device to the test setup to reduce the signal level going into the mic input...I'm also looking for an ActiveX control called WaveExCtrl.dll to be able to programmatically control mic input level of windows.

Thank you very much for your responses and effort trying to help! I really appreciate it.

Best regards,

Spring

[ben64]

If you disconnect one of the RCA connector the disconnected part of the cable will act as an antenna and can pickup signals. The disconnected part should be properly terminated (usually 600 ohms for audio).  On another PC the environnement is different and so can be the picked up signal.

Ben64

[2014spring]

Hi Ben,

Thanks for looking into my problem. When I switched from one PC to another, I didn't have to move the test setup because the PCs are sitting side by side at my desk. The only thing got moved is the cable going into PC mic. So the environment is about the same. I tried to move that cables around and didn't see anything changed (i.e. the signal readings). But when I terminated the disconnected RCA connector as you suggested, the signal reading on the disconnected channel dropped! So I think you have a good point there -- the disconnected connector should be terminated (not floating). At this point, we still don't know where exactly the crosstalk occurred. Do we? Terminating the connector is just adding a signal path to it. It helps even if the crosstalk happened after the RCA cable, or inside the PC. Correct me if I'm wrong.

Thank you very much for your good thoughts and suggestion!

Spring