1
$\begingroup$

I must estimate the direction of arrival of an acoustic source, and I hope to distinguish between a voice input and musical input using a frequency cutoff. In order to do this, I apply the same bandpass elliptic filter on the left and right channels of the stereo microphone. I have applied the filter to white noise and verified using a spectrogram that the filter does indeed retain the frequencies that it is designed to retain. I calculate the power after filtering, and use a power threshold to decide whether the frame of data is noise or not. I then use cross-correlation between the left and right channel, to estimate the time delay between left and right channels, and use that to calculate the angle of arrival.

I had first simulated the situation with two signals in numpy, with random noise added to it, and delayed by a certain number of samples. I then applied the same filter to the 'left' and 'right' channels, where the 'right' channel was simply delayed by a certain number of samples from the 'left', and random noise added. I was then able to compute the correct delay between the signals by giving the filtered 'left' and 'right' channels as input to the cross-correlator.

In real time, however, after applying the filter to the left and right channels, the time delay is neither accurate not consistent. Could it be possible that the process of computing and applying the filter (in python) is interfering with the acquisition of signals, thereby adding some random time delays and making my time delay measurements entirely inaccurate? If so, how would I go about resolving the issue?

$\endgroup$
5
  • $\begingroup$ By real time you mean you are filtering the data frame by frame for both channels as they are captured by microphone(s) on the fly ? usually such process is done frame by frame so you can check if any processing related delay is there by checking output for each input frame and it should not vary frame to frame. one more thing to to remember is that due to room impulse response, one might not get the theoretical results for delays using basic methods(cross correlation). $\endgroup$
    – Arpit Jain
    Commented Nov 7, 2016 at 11:47
  • $\begingroup$ Yes, that is what I mean by real-time processing. In pyaudio, I capture a block of 4096 samples, separate into left and right channels, apply the filter to each channel and apply cross-correlation to find the time difference. It is worth mentioning that this method works reasonably accurately without the filters on each channel. So I was wondering why applying the same filter should affect the time delay between left and right channels. $\endgroup$ Commented Nov 7, 2016 at 12:00
  • $\begingroup$ did you check output frame by frame for each channel(of stereo). if filtered output channels have varying delays with respect to the respective inputs then there is issue, either in implementation or CPU usage(filters unable to run in parallel, or device). I have no experience with pyaudio, are you using PC or some embedded platform? $\endgroup$
    – Arpit Jain
    Commented Nov 7, 2016 at 13:10
  • $\begingroup$ In the simulation, I checked the delay between the left and right channels, delay between the filtered left and left channel, delay between filtered right and right ch, and delay between filtered left and filtered right. The delay between left and right ch was accurate (giving the correct angle of source), the delay between filtered left and left ch was constant no matter the location of the source, the delay between filtered right and right ch was also constant no matter the location of the source, and the delay between filtered left and filtered right channels was randomly varying. $\endgroup$ Commented Nov 7, 2016 at 15:30
  • $\begingroup$ On real time data (on the fly), if delay of left with filtered left and right with filtered right is constant then there should not be issue with filter implementation. $\endgroup$
    – Arpit Jain
    Commented Nov 7, 2016 at 15:50

2 Answers 2

1
$\begingroup$

I hope to distinguish between a voice input and musical input using a frequency cutoff.

The use case scenario is not exactly clear here. Are you trying to get the vacuum cleaner to be called to a location by responding to a command, or are you trying to get the vacuum cleaner to follow a person that is talking in general. (A specific person perhaps?).

The second use case scenario ("follow me as I am talking to you") is probably a "voice" recognition application and localisation could be added in two stages. In stage 1, a classifier that is trained to the voice of a specific person is fed frames from the sound card. Once the classifier detects that a frame contains a "voicing", then stage 2 is activated. In stage 2, you run a frequency analysis and try to locate the fundamental tone of the person's voice. Once you locate that, you then base your direction finding on the phase difference of that particular harmonic (or band). Obviously here, because the voice is processed in frames, the vacuum cleaner's reaction time depends on the length of the frame and their overlap. Very briefly, if you are processing 1 second long frames (with zero overlaps), then the robot makes 1 direction decision every 1 second.

The first use case scenario ("come towards me when I call you") is probably a pattern recognition problem. If the vacuum cleaner is to respond to a voice command, like "Robot, clean up", then, at the very least, you could use a matched filter approach. You can then rectify and integrate the output of the matched filter and pass it through a threshold. The combined output of this will be a pulse whose duration will be, approximately, equivalent to the duration of the voice command. Running this process on two microphones with some separation between them will give you two pulses (one on each channel) with a slight time difference from which you can then estimate direction.

A variation of this technique would be to call the robot via a whistle pattern (sounding a bit like R2D2 but obviously, at human speeds). The whistle pattern is attractive because:

  1. You can filter your input to the expected range of the whistle (and it's very hard to whistle at 20kHz)
  2. A whistle is very near to a sinusoid, therefore you can use very simple means of detection
  3. Being a whistle and very close to a sinusoid, allows you to use the established techniques of phase difference to detect direction. In fact, for a given whistle pattern, you could choose to focus on the high frequency parts of it to get more accuracy out of the direction estimation.

So, given an audio stream which can even be processed on a sample-by-sample basis, establish a filter bank of filters that are atuned to a given frequency. Rectify and integrate their output (so that you essentially measure power at that band) and run that through a threshold. Once the user hits the right notes, you get a sequence of pulses and the times at which the outputs crossed the threhsold. Analysing the timings within one channel you can infer if the user just whistled the "secret pattern" and then analysing the timings across channels (or simply using a phase detector) you can infer direction.

Hope this helps.

$\endgroup$
0
$\begingroup$

Delay information is contained across the entire frequency band. Filtering, by removing some frequency information, also removes phase information, and thus delay information. Some of the removed frequency dependent delay information might have been needed to dismbuguate (phase unwrap, etc.) delay information in the remainder.

$\endgroup$
2
  • $\begingroup$ This might be the case when the target signal has considerable contribution in the bands that are filtered, other wise It should not be the case. do you agree ? $\endgroup$
    – Arpit Jain
    Commented Nov 8, 2016 at 8:29
  • $\begingroup$ @hotpaw2 , but wouldn't the delay then be equal in both channels, anyway, and the delay between right and left then be the same as for the unfiltered right and left channels? $\endgroup$ Commented Nov 8, 2016 at 10:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.