Tag Archives: Samsung Omnia 7

Fixing the Mango Microphone issue – part 2

In the first part of this short series I have demonstrated that Mango has somewhat broken XNA Microphone object, at least when it is used in Silverlight. Even the standard Microsoft’s own Silverlight Microphone Sample generates a broken sound record with some data missing, if you change the buffer length from default 500 ms to 100 ms.

Look at the sound sample recorded with 500 ms buffer on Mango, or with 100 ms buffer on NoDo:

Debug Wave recorded by NoDo 7.0 Emulator in SDK 7.1

Joined 100 ms NoDo or 500 ms Mango Debug Wave records on both phone and emulator look similar to this graph (click on it for a bigger picture).

The same sound sample recorded with 100 ms buffer on Mango:

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

Joined 100 ms Mango Debug Wave records on both phone and emulator look similar to this one. The wider (louder) marker waves are unevenly spaced, so some data is missing.

My next step was to measure the real rhytm of the buffers generated by the Microphone. Note that you cannot use System.DateTime.Now property, because of its ca 50 ms resolution. Instead, we will use System.Diagnostics.Stopwatch object, which provides better than 1 ms accuracy.

In theory, the Microphone should fire the BufferReady event every 100 ms. But the reality is quite different.

This is the list of the intervals – measured in milliseconds – between the subsequent 100 ms BufferReady events in the (emulated) NoDo:


As you can see, there is a regular pattern of the three 100+, 50+ and 150+ ms intervals, with some swaps. Ten intervals usually make ca 1011 ms. The length of the buffer is always 3200 B and the buffer contains 1600 x 16bit samples, which make 100 ms of sound. Buffers are perfectly connected to each other and no sample is missing or superfluous. (I haven’t yet cracked the interesting question where are going these surplus 11 milliseconds.)

Let’s switch to Mango:


This is recorded on Samsung Omnia 7. The emulator produces different values, but with a similar pattern: This time there are four, not three typical lengths – ca 100, ca 140, ca 70, ca 35. The sum of ten intervals is usually ca 1005 ms now, so it’s better, but the output data is incomplete. It seems that the intervals longer than 100 ms overflow the buffer.

The Microphone object is part of Microsoft.Xna.Framework.Audio namespace. It is dependent on the XNA Framework game loop. You can use it in the Silverlight Windows Phone project, but you have to simulate the game loop with a code like this:

DispatcherTimer dt = new DispatcherTimer();
dt.Interval = TimeSpan.FromMilliseconds(33);
dt.Tick += new EventHandler(dt_Tick);

void dt_Tick(object sender, EventArgs e)
     try { FrameworkDispatcher.Update(); }
     catch { }

33 milliseconds is a timer interval used in the Microsoft’s Silverlight Microphone Sample. I have used the same value, but my next step was to experiment with different timer intervals. Indeed, the resulting Microphone tick lengths were somewhat different, but there was always some data missing, overflowing the buffer – the fundamental issue hasn’t disappeared.

Perhaps you already suspect the solution: We just need a bigger buffer! So, let’s record it with a 6400 B buffer.

Debug Wave recorded with a 6.400 B buffer

Folks, this looks promising! At first look, when we erase the gaps, and join the signal segments, the resulting record may be perfect… Let’s try it in Excel…

6400 B buffer segments compacted in Excel

Oops! 😦 What could have gone wrong???

Why are some segments too long, but no segment is too short? These 35 ms segments should have been short, I guess? Wait! Do I clear the buffer every time? No, it wasn’t necessary in NoDo, because the buffer was always filled up to its fullness in every Microphone tick. In Mango, the Microphone buffer must be cleared before every BufferReady event. 😦 Let’s go on!

Cleared, recorded and compacted 6400 B buffers.


So the winning process is:

  1. Allocate bigger than nominal buffers.
  2. Clear them.
  3. Fill them.
  4. Join only the filled parts of them.

This seems weird. The Microphone object has GetSampleSizeInBytes method. So we should just invoke this method after (or before) every tick and it should return the actual buffer size… but no, it doesn’t work this way. I have played with it for some time, but it always returns just the BufferDuration x 3200 value. It doesn’t reflect the real tick record size, just its ideal size, which is always matched in NoDo, but never in Mango…

The issue with the XNA Microphone object in Mango with 100 ms buffer is that the real buffer length is variable and there is no working API to get its length!

The good news is that no data is really lost. We just don’t know we actual size of the one tick record, so we have to figure it with some workaround. The way to go is to count zeros from the end of the buffer backwards. It may be slightly wrong in some cases, when the sound samples are actually zero at the end of the partial records, for example when the wave crosses the X axis and has exactly zero value at the end of the record. But these cases are quite rare and we can neglect them – at least if we are building a tuner.

In the next and the last part of this mini-series I will publish the source code of the Carousel object, which uses the above described methods to deliver solid data from the capricious Mango Microphone. The living proof of its reliability is my app Accurate Tuner Pro, probably the best pitch tuner for Windows Phone.


What should Microsoft do now? Change GetSampleSizeInBytes of the Microphone object to return the actual size of the just recorded buffer.

Let’s hope it’s fixed in Tango. But still, Tango rollout is going to take some time, so the Carousel object may help you.

To be continued.


Filed under WP developement

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()
    _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;
            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 

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

    if (_isPlaying)
        _soundInstance = null;

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

    _isPlaying = true;

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

    _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.


Filed under WP developement

Accurate Tuner finally works on Mango

I’ve docummented the issues my Accurate Tuner Beta 1.0.0. has with Mango. Put simply, it does not work at all. After quite a lot of hours, I’ve finally managed to repair it!

Yes, it was more demanding than I expected, but all’s well that ends well. After some final testing I will publish the update, so it will be available in the marketplace in a few days. Also, I will publish my findings about the changed Microphone object behaviour in Mango on this blog.

Let’s comment on the video:

  • Notice the Middle C on the Yamaha keyboard is marked as C3, while the tuner shows C4. It is correct – it really is C4 in the scientific notation, used by the Accurate Tuner (261.64 Hz).
  • My left thumb is shaking… no, I’m not that old or terrified, just a little cold. 🙂
  • The fundamental frequency detection is not perfect. Different tone letters or octaves are flashing at times – this is typical for this hard-to-tune guitar with nylon strings I used for this video. Fortunatelly, it’s better with other instruments, including steel-string guitars. In fact, all these tones are harmonics of the base frequency, so do not really matter. All harmonics are in tune at the same time, so you can safely ignore letters and concentrate just on the needle and/or the wave.
  • When you get accustomed to it (and use steel strings 😉 ), you can tune your instrument extremely fast using the wave only.
  • Accurate Tuner design is not Metro and not even beautiful, I know. But it works! Don’t take it for granted, smartphone tuners in general rather do not work well. 😉

1 Comment

Filed under My Apps

VIDEO: Mango vs. NoDo – A Developer’s Trouble (update)

This is my Accurate Tuner Beta for Windows Phone.

Top: NoDo OS version (WP 7.0 – emulator from SDK 7.0, spring 2011 update)

Bottom: Mango (WP 7.1/7.5 RTM, Samsung Omnia 7)

Select 720p.

When in tune, the Wave above the Needle must stand still.

This beta has better than 0.1 Hz accuracy on NoDo, but doesn’t work at all on Mango. Microsoft has changed the Microphone XNA object behavior. The FFT part (Needle) of the Tuner is less accurate and unstable now, results are completely wrong for lower frequencies. The strobo part doesn’t work at all. And the sound wave has very different shape, it seems to be flipped on both axes…

The app had average rating of 4.88 in the Marketplace before Mango. It will go down fast now, of course. It will take at last a week before the update will be published. I should have test it on Mango before the Mango public release, I know. 😉 But I honestly hadn’t expected this kind of change… I’m trying to figure these changes in the XNA sound processing and to fix it ASAP, but it doesn’t seem to be trivial at first. Does anybody know what has exactly changed with Microphone, XNA events dispatching in Silverlight etc. in Mango?



Status update

I hope I’ve already localized the issue – and yes, there is a real change of the Microphone behavior, although it probably still is in accordance with the documentation.

Unfortunately, it’ll take some work to adapt my tuner to that change, but it should be possible. I plan to describe it in my blog later this week.


Filed under My Apps

Český návod: Aktualizujte svůj Windows Phone na Mango ihned!

Note for English speaking readers: If you want to force your Windows Phone to Mango right now, you can! The English instructions are here.

Včera začal Microsoft distribuovat dlouho očekávanou zásadní aktualizaci Windows Phone – verzi 7.1/7.5 s kódovým jménem Mango. Update je však rozloženo do několika týdnů a jen asi 10% uživatelů bylo nabídnuto hned první den. Naštěstí existuje jednoduchý způsob, jak váš telefon k update přinutit.


  1. Protože je součástí update zálohování obsahu paměti telefonu, které může trvat desítky minut, doporučuji před aktualizací odstranit z mobilu hudbu a odinstalovat nepoužívané aplikace.
  2. Připojte telefon k počítači. Spustí se program Zune.
  3. Vyberte Telefon -> Nastavení -> Aktualizace. Pokud je zde k dispozici update, už na vás došla řada a prostě je potvrďte. Pokud vám Zune stále tvrdí, že je váš telefon aktuální, pokračujte dalším bodem.
  4. Zvolte z levého menu Zune jinou volbu, např. Bezdrátová synchronizace. V této chvíli musí být váš počítač připojen k internetu. Připravte se na jeho rychlé odpojení, například vytažením ethernetového kabelu nebo vypnutím WiFi hardwarovým tlačítkem.
  5. Klikněte opět na položku Aktualizace a asi sekundu poté odpojte počítač od internetu. Pokud budete mít štěstí, Zune vám nabídne aktualizaci.
  6. Počítač opět připojte k internetu a aktualizujte.
  7. Při neúspěchu bodu 5 opakujte body 4 až 5 stále dokola. Chce to trpělivost, mně se to podařilo až asi na dvacátý pokus, jiným napoprvé.
  8. Protože se před Mangem (build 7720) musí nainstalovat aktualizace 7392 a 7403, je možné, že budete muset celý proces několikrát opakovat, jak se to stalo některým lidem v zahraničí. Já jsem už měl nainstalován build 7392, nabídlo se mi update na 7403 a po něm se automaticky nainstalovalo Mango RTM 7720.

A užívejte si Mango, které je opravdu chutné! Všechno ve vašem telefonu bude najednou fungovat lépe a první dlouhý stisk tlačítka Zpět (multitasking) je opravdu zážitek.

Jediné zklamání, které mi update připravilo, bylo uzamčení mého zcela legálně, avšak nestandardně, odemčeného telefonu. Nové odemčení je pro mne poněkud komplikovanější, neboť ještě nejsem registrován jako český vývojář. Ale to jsem stejně v nejbližších dnech plánoval udělat.

Naopak velmi příjemným překvapením je česká klávesnice. Domníval jsem se, že bude k dispozici jen na nových telefonech, ale update ji přineslo i na ten můj.


Váš build 7392 je OK, Mango není k dostání

Váš build 7392 je aktuální, Mango pro vás nemáme!

Wireless on

Jsem připojen k síti. Vyberu v menu aktualizaci a...

Wireless off

...rychle odpojit od sítě! Myslím, že jsem uspěl, když jsem to udělal asi po půl sekundě.

7403 je k dispozici

No vida, Mango leželo pod pultem. Tedy přesně řečeno je to přípravná aktualizace 7403. V této chvíli nezapomeňte znovu zapnout internet, já osel jsem to poprvé neudělal a vše bylo třeba opakovat. 🙂

7403 under construction


2nd update

Po nainstalování 7403 se automaticky začala instalovat aktualizace 7720, tedy vlastní Mango. Záloha telefonu znovu neproběhla.



7720 nainstalováno

Mango je Windows Phone 7.1, Microsoft je nicméně marketuje jako 7.5. Nenechte se tím zmást.

Tublatanka, Dnes:

Leave a comment

Filed under Windows Phone Experience

Wow! An update is available for my Omnia 7 :-)

After a long, long long time, finally…

NoDo and May update

Let’s go, darling…

10 – 9 – 8 – 7 – 6 – 5 – 4 – 3 – 2 – 1 …

NoDo and May update - SUCCESS


Leave a comment

Filed under Windows Phone Experience

NoDo update is not available to me anymore

Microsoft has been offering me a NoDo update for a couple of weeks. Until yesterday. Today, something has changed:

NoDo unavailable again

No, I have not installed NoDo yet. 🙂 Is this a new chapter in the WP7 update soap opera?

Let’s try to be positive: Perhaps a new – post-NoDo – update is prepared for the MIX time?


Filed under Windows Phone Experience

NoDo update is available – so let’s wait for a while

My Zune welcomed me by this wonderful screen today:

Zune: NoDo Available

Yes, this is the famous NoDo update! In fact, it’s available for all unbranded phones since yesterday. But I’m going to wait for a while – for two reasons:

  1. My unpleasant experience with the Pre-NoDo update. I guess it would be better not to hurry up and let others to be early adopters.
  2. NoDo blocks ChevronWP7 phone unlocker, which I use for my spare time development, as I live outside of the official developer countries walled garden. After NoDo, I will go to Yalla Apps as they are able to officially unlock phones in the outside world. It will cost something (no problem) and probably take a while (which is a small problem).

You can read interesting Rafael Rivera’s notes about the update proces.

George Harrison: Got my mind set on you:

1 Comment

Filed under Uncategorized

How I survived the DoNo Windows Phone update

“An update is available.” Great! It’s my turn, finally.

This is the so-called pre-NoDo update, or update 0.9, which improves the update process itself, but brings no new features. I nickname it DoNo (do nothing) update. This is the 2nd corrected version of this corrective pre-update, which should work with Samsung phones too. Microsoft nevertheless noted that some 100 people experienced some issues with this 0.9.1 version too and even offered an advice to them. You should basically free as many memory as possible on your phone, so let’s go.

Phone: Samsung Omnia 7, not locked to any carrier, 8 GB memory, not dev or Chevron unlocked, no modified firmware or any homebrew app installed.

PC: Windows 7 Home Premium 64bit, SP1, Core i5, 4 GB RAM, 355 GB free on disk C, 126 GB on disk D.

Attempt 1

I deleted majority of media and some apps before the update, so I had 4,01 GB free. The update took some 10 minutes. One unexpected thing occured during the process – a new Samsung driver was automatically installed in Windows 7. The outcome:


There was an error while trying to update your device with the latest software.Please try again.

The timer ran out on what we were trying to do.

To see if there’s more information about this error, click Web Help.


WP7 pre NoDo update Fail

Attempt 2

Content syncing set to manual, all multimedia content erased, phone restarted. 4.38 GB free. After some 9 minutes…


Attempt 3

I have uninstalled almost everything and lowered the reserved space (Zune Phone -> Settings -> Reserved Space) to 2 %. Now I have 5,19 GB free.


Attempt 4

Somebody has suggested that Samsung native apps could do some harm to the update process, so I removed the Samsung Network Profile app. 5,20 GB free.


Attempt 5

Reserved space 0 %, all the apps uninstalled. 5,35 GB free.


Attempt 6

All five accounts removed, except for the primary Live account (Outlook/Exchange, Gmail, secondary Hotmail, Facebook, Centrum.cz). 5,39 GB free.


Attempt 7

Let’s try it without the SIM card. After 8 minutes…


Attempt 8

Reset to the factory settings.


Windows Phone pre NoDo update - success

6.11 GB free.

So the update process is updated now. And both phone and its user are still (somewhat) alive. I should especially commend the backup part of the process – indeed, I was forced to backup everything very, very well! A pen and paper were particularly useful for writing down all the paswords etc.

Good work, dear Microsoft and Samsung!

Queen, We Are The Champions, live:


Filed under Windows Phone Experience