Fixing the Mango Microphone issue – part 1

Last september, when Windows Phone 7.5 Mango update was released, it broked my Accurate Tuner Beta. I’ve analysed the issue and was able to release the update that fixed it.

The two videos below illustrate the situation. First the trouble (Mango is installed on the phone, while the emulator still uses NoDo and works properly):

Then the solution:

I promised to explain it in detail back then, but I lacked the time to do it. Now, when I have sent Accurate Tuner Pro to the Marketplace certification, I can fulfill my promise and write a short series about this issue.

Perhaps it is not so important now, because new Tango update is behind the corner and may fix it. In the last part of this series (3rd or 4th) I will publish the source code for the Carousel object, which is used by Accurate Tuner for harvesting solid sound data from somewhat broken Mango microphone.

To map the problem I have created a simple tone generator. It produces a 500 Hz wave (B4 + 21 cents) with a specific shape: “Normal” wave has the amplitude of  5.000, while every 10th wave has the amplitude of 15.000. The resulting “hedge clipper” shape makes a growling sound and looks like this:

Source Debug Wave 500 Hz with 50 Hz markers

Source Debug Wave 500 Hz with 50 Hz markers

Click on it for a bigger picture.

Wave parameters:

  • Sampling rate: 16 000 Hz – the default sampling rate of Windows Phone OS 7.0 and 7.1
  • Base frequency: 500 Hz, wave length 32 samples
  • Frequency of the markers: 50 Hz, wave length 320 samples

Tone Generator source code:

/// <summary>
/// Creates the DEBUG Wave with the debug parameters
/// </summary>
public void CreateDebugWave()
{
    // DEBUG PARAMETERS
    _samplingRate = 16000;
    _frequency = 500;
    double _normalAmplitude = _amplitude = 5000;
    double markerWaveAmplitude = 15000;
    int markerWaveStep = 10;

    int waveLength = (int)(_samplingRate / _frequency);
    int markerSampleStep = markerWaveStep * waveLength;

    double doubleSample = 0;
    Int16 intSample = 0;
    byte[] byteSample = new byte[2];
    double b = (Math.PI * 2) * _frequency / _samplingRate;

    int j = 0;

    // The wave buffer is one second long
    //
    // This works for whole number of waves (= integer 
    // frequencies) only. 500 Hz or 440 Hz is OK, while
    // 261.63 Hz will make a snapping sound every second.
    //
    for (int i = 0; i < _samplingRate; i++)
    {
        // Marker wave creation
        //
        // This is simple and clear, but not very efficient.
        // It doesn't matter here.
        //
        if (i % markerSampleStep == 0)
            _amplitude = markerWaveAmplitude;
        else
            if (i % markerSampleStep == waveLength)
                _amplitude = _normalAmplitude;

        doubleSample = Math.Sin(i * b) * _amplitude;
        intSample = (Int16)Math.Round(doubleSample);
        byteSample = BitConverter.GetBytes(intSample);

        _buffer[j] = byteSample[0];
        _buffer[j + 1] = byteSample[1];

        // DEBUG For debug visualization purposes only
        _bufferInt16[i] = intSample;

        j += 2;
    }
}

/// <summary> 
/// Creates and plays the wave.
/// </summary> 
public void Start()
{
     // DEBUG 
    CreateDebugWave();

    SoundEffect sound = new SoundEffect(_buffer,
                        _samplingRate, AudioChannels.Mono);

    if (_isPlaying)
    {
        _soundInstance.Stop();
        _soundInstance.Dispose();
        _soundInstance = null;
    }

    _soundInstance = sound.CreateInstance();
    _soundInstance.IsLooped = true;
    _soundInstance.Volume = _volume;

    _isPlaying = true;
    _soundInstance.Play();
}

/// <summary>
/// Stops playing the wave.
/// </summary>
public void Stop()
{
    if (!_isPlaying)
        return;

    _soundInstance.Stop();
    _isPlaying = false;
}

By the way, the more universal version of this tone generator is included in Accurate Tuner Pro.

Now the interesting part begins: To avoid any mistake in my code I’ve used the standard Silverlight Microphone Sample provided by Microsoft. It uses 500 ms long sound buffer by default. This is the record it produces on NoDo (recorded in the 7.0 Emulator of the 7.1 SDK):

Debug Wave recorded by NoDo 7.0 Emulator in SDK 7.1

Debug Wave recorded by NoDo 7.0 Emulator in SDK 7.1

I’ve carefully reviewed much longer part of the record and found no irregularities. This data is solid and can be safely used by Accurate Tuner for two purposes:

  • Wave vizualization, which is phase-normalized for the stroboscopic efect usable for fine tuning.
  • Fast Fourier Transformation algorithm, which analyses component frequencies for rough tuning.

Next, let’s run it on Mango:

Debug Wave recorded by Mango 7.1 Samsung Omnia 7

Debug Wave recorded by Mango 7.1 Samsung Omnia 7 with 500 ms buffer

The growing amplitude is probably caused by the automatically adjusting microphone sensitivity of the phone and is not interesting for us now, it reaches some maximum amplitude and then stays constant. Another thing is more important – I haven’t found anything wrong with this signal too.

Is this the way Accurate Tuner records sound? Almost. 500 ms sound buffer is good enough for most recording purposes, but it is too long for tuners or sound visualizations, because you need fast response in these cases. The shortest buffer length allowed by WP 7.0 and 7.1 is 100 ms and Accurate Tuner uses this buffer length.

So let’s change the buffer length to 100 ms. The picture is wider now, so click on it to maximize it:

Debug Wave recorded by Mango 7.1 Samsung Omnia 7 with 100 ms buffer

Debug Wave recorded by Mango 7.1 Samsung Omnia 7 with 100 ms buffer

Folks, this is clearly wrong!

Apparently, some sound data is lost!

This explains everything: While common sound visualizations used for estetic purposes only will still look as usual, a stroboscopic animation will be inevitably completely broken. FFT will provide more interesting and confusing results, as there are still big portions of correct waves here, but these portions are phase-shifted. The final results will be unstable and very inaccurate, but not completely wrong.

Which is exactly the behavior of the original Accurate Tuner Beta algorithms.

(I’m skipping the chart of the NoDo 100 ms buffer, but believe me the record is perfect and looks just exactly as the chart with the 500 ms buffer. I would also point out that the described issue is present in the WP 7.1 Emulator too, so it isn’t specific for Samsung phones.)

What to do with it??? FFT will work correctly, if only “safe part” of the buffer is used, for example 50 ms. But it will be extremely inaccurate. In fact, even 100 ms is not enough and several buffers must be joined for the analysis to be meaningful. Or I can change the buffer size to 500 ms, but the FTT results would be very delayed in such case and almost unusable. And the wave visualization delayed by 0.5 s will be just comical.

We will see next time.

To be continued.

3 Comments

Filed under WP developement

3 responses to “Fixing the Mango Microphone issue – part 1

  1. Pingback: Fixing the Mango Microphone Issue – Part 1

  2. Pingback: Fixing the Mango Microphone issue – part 2 | Stubborn Developer

  3. Pingback: Agile Metronome is Back – and Amazingly Accurate | WMPoweruser

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s