Monday 28 April 2014

NoDriver calling acmFormatSuggest playing MP3s with NAudio

One question that commonly gets asked with NAudio is, “Why do I get a NoDriver calling acmFormatSuggest error when playing MP3s?” The answer is that you don’t have the ACM MP3 decoder installed. If you’re running a regular desktop version of windows from XP all the way up to 8.1, then the Fraunhofer MP3 ACM decoder is installed as standard and everything should just work.

But if you’re running a server version of Windows (or maybe one of the “N” versions of Windows sold in Europe), then you might be missing the codecs you need. There are various workarounds to this:

Option 1: Install Desktop Experience

If you are running Windows Server, make sure you install the “Desktop Experience” component of Windows. This will install all the standard codecs, for audio playback (including Media Foundation support as well). To install on Azure, this script may be helpful.

Option 2: Use the DMO MP3 Frame Decompressor

The NAudio Mp3FileReader class allows you to inject an alternative MP3 frame decompressor, so you don’t need to use ACM if you don’t want to. To use the DMO MP3 frame decompressor for example, use the following code:

new Mp3FileReader(stream,wave=> new DmoMp3FrameDecompressor(wave));

Option 3: Use MediaFoundationReader Instead

With NAudio 1.7, the MediaFoundationReader class was introduced, which can not only play MP3 files, but lots of other formats too. In many ways, this should now be the preferred way of playing MP3s with NAudio. You will still need the Desktop Experience installed if you’re on Windows Server though.

Option 4: Use a fully managed MP3 Decoder

Another option is to switch to fully managed MP3 decoder such as NLayer. This has the benefit of working on all platforms and requiring no codecs.

Option 5: Find and install another ACM MP3 Codec

Finally, you may be here not because you’re playing MP3, but because you tried to play a WAV file containing some codec that your system cannot find an ACM driver for. This also results in the “NoDriver calling acmFormatSuggest error”. What you need to do is search the web for an ACM codec that can decode the format you are using. Unfortunately this is not always a simple process, but unless you have a codec installed that matches the compression type of the file you’re trying to play, you won’t be able to play it.

Thursday 24 April 2014

Reactive Extensions Observables Versus Regular .NET Events Part 2

In my last post, I compared the code to raise and subscribe to regular .NET events with the Reactive Extensions equivalent. In this post, I want to look at a few reasons you might want to make the transition to Rx Observables.

Idiomatic unsubscribe

Unsubscribing from regular .NET events is straightforward, so long as you don’t use the lambda syntax:

// subscribe:
raiser.Progress += OnProgress;
// unsubscribe:
raiser.Progress -= OnProgress;

// subscribe with lambda:
raiser.Progress += (sender, args) => Console.WriteLine("Progress");
// ... but how do we unsubscribe?

Rx is much nicer. Calling Subscribe returns a disposable subscription object, which you can use to unsubscribe when you’re no longer interested in receiving any more events. This makes it easier to write code that avoids some of the memory leak gotchas that you occasionally can run into with events.

var subscription = raiser.Progress.Subscribe(
 p => Console.WriteLine("Progress {0}", p.Value);
// later if required:
subscription.Dispose()

Also, as Dennis Daume kindly pointed out on Twitter, Rx things even safer by automatically unsubscribing all subscribers once a sequence has completed or errored. So in most cases, you won’t need to unsubscribe at all.

Built-in Errors and Complete

IObservables also have built-in capability to report that the sequence has ended, either successfully (Complete) or with an error. This saves having to create additional events to report problems, or add exception properties to event args that developers need to remember to check.

Filter and Transform

This is where things get really interesting. Observable sequences can be filtered and transformed in a very similar way to enumerable sequences with LINQ. In fact, many of the same operators are available. So I can filter out every other progress event from our last example like this:

eventDemo.Progress
    .Where(p => p.Value % 2 == 0)
    .Subscribe(p => Console.WriteLine("Progress {0}", p.Value));

and I can even move the string formatting into a select statement like this, so I get an observable sequence of strings instead of a sequence of Progress events:

eventDemo.Progress
    .Where(p => p.Value%2 == 0)
    .Select(p => String.Format("Progress {0}", p.Value))
    .Subscribe(Console.WriteLine);

As you can see, IObservable events are composable, and the operators can be chained together. This opens up lots of really cool and interesting possibilities. For example you can throttle events if there are too many and you are only interested in receiving periodic updates:

eventDemo.Progress
    .Throttle(TimeSpan.FromSeconds(3))
    .Select(p => String.Format("Progress {0}", p.Value))
    .Subscribe(Console.WriteLine);

Threading Helpers

One issue you regularly face with events in .NET is that the can be raised on a different thread to the one you need to handle them on. This is an issue when the handler needs to make GUI changes. Rx solves this problem by letting you specify a synchronization context for the events to be handled on:

eventDemo.Progress
    .Select(p => String.Format("Progress {0}", p.Value))
    .ObserveOn(SynchronizationContext.Current)
    .Subscribe(Console.WriteLine);

Observable Timers

Observable also provides a convenient Timer function, which allows you to receive a single event in a specified timespan, or a repeated sequence of events. If can even be given a DateTimeOffset to alert you at a specific time.

var period = TimeSpan.FromMilliseconds(500);
Observable.Timer(period).Subscribe(t => Console.WriteLine("One-off: {0}", t));
Observable.Timer(period, period).Subscribe(t => Console.WriteLine("Repeating: {0}", t));

Observe Regular .NET Events

Obviously regular .NET events aren’t going to go away overnight, but if you like you can convert them into IObservables, allowing you to make use of all the cool stuff that Rx provides. It does require a rather strange syntax, but that’s due to the way .NET events work:

Observable.FromEventPattern<ProgressEventArgs>
    (h => eventDemo.Progress += h, 
     h => eventDemo.Progress -= h)
   .Subscribe(p => Console.WriteLine("Progress {0}",p);

Summary

I’ve barely scratched the surface of what’s possible with Rx and Observables, but as you can see, it’s much more powerful than regular .NET events. It would be nice if everyone using .NET would migrate over to using Observables, but I suspect that won’t happen since although the IObservable interface is now part of the .NET framework, to get the most out of it, you also need the Reactive Extensions libraries. But certainly my experimentations with Rx have made me want to make use of it more frequently rather than just defaulting to plain old .NET events for everything.

Wednesday 23 April 2014

Reactive Extensions Observables Versus Regular .NET Events Part 1

Since it’s original release, .NET has provided it’s own support for raising events and subscribing to them. This is essentially an implementation of the “Observer pattern”, and for the most part works well, although the way it was implemented was less than ideal.

The shortcomings include the need to copy the event handler to a temporary variable before raising it to avoid a nasty (but rare) race condition, not being able to pass events as objects (resulting in hacky workarounds in mocking and unit testing frameworks to deal with them), and the rather cumbersome standard event handler function signature, which has the “sender” object as the first parameter (requiring you to cast it to the concrete type you already know it is if you want to make use of it), and the arguments property needing to derive from a rather pointless EventArgs base class.

But there is another option, which doesn’t require you to create your own custom implementation of the observer pattern, and that is to make use of the Reactive Extensions (Rx) framework. This has been around for some time now, but perhaps hasn’t gained the attention it deserves. Rx essentially provides a much more powerful way of working with events.

In this post I’ll show how you can take .NET code that both raises and consumes regular .NET events and convert it to using Rx. And I plan to follow up with a future post that looks at the benefits of making this transition.

Raising .NET Events

First, let’s look at how you raise events the standard .NET way. This simple demo class has a Start method that kicks off a background task. It raises two types of event – Progress events, and a Finished event when it’s done which can contain an exception if something went wrong.

class EventDemo
{
    public event EventHandler<ProgressEventArgs> Progress;
    public event EventHandler<FinishedEventArgs> Finished;

    protected virtual void OnFinished(FinishedEventArgs e)
    {
        var handler = Finished;
        if (handler != null) handler(this, e);
    }

    protected virtual void OnProgress(ProgressEventArgs e)
    {
        var handler = Progress;
        if (handler != null) handler(this, e);
    }

    public void Start()
    {
        Task.Run((Action)DoStuff);
    }

    private void DoStuff()
    {
        try
        {
            foreach (var n in Enumerable.Range(1, 10))
            {
                Thread.Sleep(1000);
                OnProgress(new ProgressEventArgs(n));
            }
            OnFinished(new FinishedEventArgs());
        }
        catch (Exception exception)
        {
            OnFinished(new FinishedEventArgs(exception));
        }
    }
}

You can see here that we’ve created a couple of helper functions (OnFinished and OnProgress) to avoid the race condition issue. We also needed to create a couple of event argument classes:

class ProgressEventArgs : EventArgs
{
    public ProgressEventArgs(int progress)
    {
        Progress = progress;
    }

    public int Progress { get; private set; }
}

class FinishedEventArgs : EventArgs
{
    public FinishedEventArgs(Exception exception = null)
    {
        Exception = exception;
    }

    public Exception Exception { get; private set; }
}

Subscribing to .NET events

To subscribe to the events raised by this class, we simply use the += operator and give it either the name of the event handler method or a lambda function to run. Here we use the first technique, since it makes unsubscribing easier if we need to do that later.

class EventConsumer
{
    private readonly EventDemo eventDemo;
    public EventConsumer()
    {
        eventDemo = new EventDemo();
        eventDemo.Progress += OnProgress;
        eventDemo.Finished += EventDemoOnFinished;
        eventDemo.Start();
    }

    private void EventDemoOnFinished(object sender, FinishedEventArgs finishedEventArgs)
    {
        Console.WriteLine("Finished {0}", finishedEventArgs.Exception == null ? "success" : finishedEventArgs.Exception.Message);
    }

    private void OnProgress(object sender, ProgressEventArgs progressEventArgs)
    {
        Console.WriteLine("Progress {0}", progressEventArgs.Progress);
    }
}

Raising Rx Events

Now let’s have a look at how we might implement the same thing, but using Reactive Extensions instead. We might be tempted to think that the Rx version of our class should mirror as closely as possible the .NET version, so we’d add two IObservable properties, which were the equivalent of the Progress and Finished events. The easy way to create IObservables is to make instances of the Rx Subject class , and the “events” can be fired by calling the OnNext method on the subject. The event argument can be any object – there is no need to make it inherit from EventArgs.

class ObservableDemoNaive
    {
        private readonly Subject<Progress> progressSubject;
        private readonly Subject<Finished> finishedSubject;

        public ObservableDemoNaive()
        {
            progressSubject = new Subject<Progress>();
            finishedSubject = new Subject<Finished>();
        }

        public IObservable<Progress> Progress { get { return progressSubject; } }

        public IObservable<Finished> Finished { get { return finishedSubject; } }

        public void Start()
        {
            Task.Run(() => DoStuff());
        }

        private void DoStuff()
        {
            try
            {
                foreach (var n in Enumerable.Range(1, 10))
                {
                    Thread.Sleep(1000);
                    progressSubject.OnNext(new Progress(n));
                }
                finishedSubject.OnNext(new Finished());
            }
            catch (Exception exception)
            {
                finishedSubject.OnNext(new Finished() { Exception = exception});
            }
        }
    }

Whilst this works,  it isn’t a particularly good example of using Reactive Extensions. For starters, the Finished event is trying to solve a problem that Rx already solves for us. An observable can tell us when it is completed, as well as when it has errored. So we can simplify this to work with a single Observable:

class ObservableDemoBetter
{
    private readonly Subject<Progress> progressSubject;

    public ObservableDemoBetter
    {
        progressSubject = new Subject<Progress>();
    }

    public IObservable<Progress> Progress { get { return progressSubject; } }

    public void Start()
    {
        Task.Run(() => DoStuff());
    }

    private void DoStuff()
    {
        try
        {
            foreach (var n in Enumerable.Range(1, 10))
            {
                Thread.Sleep(1000);
                progressSubject.OnNext(new Progress(n));
            }
            progressSubject.OnCompleted();
        }
        catch (Exception exception)
        {
            progressSubject.OnError(exception);
        }
    }
}

Note that the OnCompleted method of the Subject class doesn’t take any parameters. So if your original FinishedEventArgs contained additional data, a different way of passing it back would be needed.

However, in making this change, we’ve actually modified the behaviour. An observable sequence can only complete once, so if you were to call Start twice, you’d not see any results after the first sequence finished. In fact, this probably highlights a design flaw in our original class – if two operations are going on simultaneously, you have no idea which one the Progress and Finished events relate to.

This can be solved by making our Start method return the IObservable stream of progress events for the particular operation that was started:

class ObservableDemo
{
    public IObservable<Progress> Start()
    {
        var subject = new Subject<Progress>();
        Task.Run(() => DoStuff(subject));
        return subject;
    }

    private void DoStuff(Subject<Progress> subject)
    {
        try
        {
            foreach (var n in Enumerable.Range(1, 10))
            {
                Thread.Sleep(1000);
                subject.OnNext(new Progress(n));
            }
            subject.OnCompleted();
        }
        catch (Exception exception)
        {
            subject.OnError(exception);
        }
        finally
        {
            subject.Dispose();
        }
    }
}

Now we have a much cleaner, simpler interface, and there can be no confusion about which background task is raising the events if we call Start twice.

Subscribing to Rx Events

Subscribing to Rx events is nice and simple. You can provide an action that is called for each event, and optionally for when it completes successfully or with an error as shown here:

var observable = eventDemo.Start();
observable.Subscribe(
    p => Console.WriteLine("Progress {0}", p.Value),
    e => Console.WriteLine("Error {0}", e.Message),
    () => Console.WriteLine("Finished success"));

As can be seen, the Rx versions of both the event producer and consumer code are slightly more succinct than the equivalent regular .NET event code.

The Story So Far

So far we’ve seen that it is fairly straightforward to switch from .NET events to Rx Observables, but you may want to consider changing how you work with them to fit more nicely with the way Rx works. In the next post we’ll look at other benefits that Observables bring to the table such as better unsubscribing, and the ability to manipulate and filter the events with a LINQ-style syntax, as well as seeing how to turn existing .NET events into Observables.

If you want to play with Reactive Extensions yourself, the easy way is to simply add the NuGet package to your project.

Monday 14 April 2014

Roundtrip Serialization of DateTimes in C#

Say you need to serialize a DateTime object to string (perhaps for an XML or JSON file), and want to ensure that you get back exactly the same time you serialized. Well, you might think that you can just use DateTime.ToString and DateTime.Parse:

var testDate = DateTime.Now;
var serialized = testDate.ToString();
Console.WriteLine("Serialized: {0}",serialized);
var deserialized = DateTime.Parse(serialized);
Console.WriteLine("Deserialized: {0}",deserialized);

// prints:
Serialized: 14/04/2014 16:32:00
Deserialized: 14/04/2014 16:32:00

At first glance it seems to work, but actually this is a very bad idea. What’s wrong with this approach? Well two things. For starters, the millisecond component of the time has been lost. More seriously, you are entirely dependent on the deserializing system’s short date format being the same as the serializing system’s. For example, if you serialize in a UK culture with a short date format of dd/mm/yyyy and then deserialize in a US culture with a short date format of mm/dd/yyyy you can end up with completely the wrong date (e.g. 1st of March becomes the 3rd of January).

So how can you ensure you get exactly the same DateTime object back that you serialized? Well the answer is to use ToString with the “O” format specifier which is called the “roundtrip format specifier”. This will not only include the milliseconds, but also ensures that the DateTime.Kind property is represented in the string (under the hood a .NET DateTime is essentially a tick count plus a DateTimeKind).

Here’s three dates formatted with the roundtrip format specifier, but each with a different DateTime.Kind value:

Console.WriteLine("Local: {0}", DateTime.Now.ToString("O"));
Console.WriteLine("UTC: {0}", DateTime.UtcNow.ToString("O"));
var unspecified = new DateTime(2014,3,11,16,13,56,123,DateTimeKind.Unspecified);
Console.WriteLine("Unspecified: {0}", unspecified.ToString("O"));

// prints:
Local: 2014-04-14T16:36:01.5305961+01:00
UTC: 2014-04-14T15:36:01.5345961Z
Unspecified: 2014-03-11T16:13:56.1230000

As you can see, UTC times end in Z, local times include the current offset from UTC, and unspecified times have no suffix. You can also see that we have fractions of a second to 7 decimal places. If you’ve serialized your DateTime objects like this, you can then get them back to exactly what they were before by using DateTime.Parse, and passing in the DateTimeStyles.RoundTripKind argument:

DateTime.Parse("2014-03-11T16:14:27.8660648+01:00", CultureInfo.InvariantCulture, DateTimeStyles.RoundtripKind);

The only thing to note here is that the serialization of a local time includes the offset from UTC. Which means that if you deserialize it in a different timezone, you will get the correct local time for that timezone. Which will of course be a different local time to the one originally serialized This is almost certainly what you want, but it does mean that technically, the binary representation of the deserialized DateTime object is not identical to the one that was serialized (different number of ticks).

Wednesday 9 April 2014

Thoughts on Windows RT Audio APIs and BUILD 2014

One of the sessions I was most excited about at BUILD this year was Jason Olson and Pete Brown’s session on Sequencers, Synthesizers, and Software, Oh My! Building Great Music Creation Apps for Windows Store.

I had been hoping before the conference that we might see MIDI support for WinRT...

...and I wasn't disappointed. The talk covered a brand new MIDI API for Windows RT (requires 8.1 Update 1), as well as giving some guidance on low latency WASAPI usage.

Let's look first at the MIDI support…

Basically, it allows you to access MIDI in and out devices (MIDI over USB), receiving and sending messages. This is great news, and enables the creation of several types of application not previously possible in Windows Store apps (I’d wanted to make a software synthesizer for quite some time, so that’s first on my list now).

It’s distributed as a NuGet package allowing access from C#. This is huge in my opinion. One of the most painful things about doing audio work in C# has been endlessly creating wrappers for COM based APIs such as WASAPI and Media Foundation. It's really hard to get right in C# and you can run into all kinds of nasty threading issues. I had hoped when WinRT originally came out that it would wrap WASAPI and MediaFoundation in a way that eliminated the need for all the interop in NAudio, but sadly that was not to be the case. But this represents a great step in the right direction, and I hope it becomes standard.

What can't it do:

It doesn't read or write MIDI files, but that's not a particularly big deal to me. NAudio and MIDI.NET both can do that.

It doesn't provide a MIDI sequencer. You'd need to schedule out your MIDI out events at exactly the right time to play back a MIDI file from your app.

It doesn't offer up a software synthesizer as a MIDI out. That would be a great addition, especially if you could also load the software synthesizer up with SoundFonts.

There is no RTP MIDI support but they suggested it might be a feature under consideration. This would be useful for wireless MIDI, and could also form the basis for sending MIDI streams between applications which could also be useful.

And now onto WASAPI

There was some really useful information in the session on how to set up your audio processing to work at a pro audio thread priority, and how to use a “raw mode” to avoid global software based effects (e.g. a graphic equaliser) introducing additional latency. Getting good information on WASAPI is hard to come by, so it was good to see recommendations as well on using event driven mode and when to use exclusive mode.

What I would love to see with WASAPI is exactly the same approach as has been taken with MIDI. Give us a NuGet package that presents both the Render and Capture devices in a way that can be used from C#. Let me easily open an output device, specify if I need pro audio thread priority, raw mode, exclusive mode, and then give me a callback to fill the output buffer on demand with new samples. Ideally it should incorporate resampling too, as it is a huge pain to resample yourself if you are playing a 44.1kHz file while your soundcard is operating at 48kHz.

Likewise with capture. Let me easily open any capture device (or loopback capture), and get a callback whenever the next audio buffer is received containing the raw sample data. This might be possible already with the MediaCapture class but I'm unclear how you get at the raw samples (somehow create a custom sink?). Again, I’d like to be able to specify my capture sample rate and have the API resample on the fly for me, as often with voice recordings, 16kHz is quite acceptable. WASAPI is much harder to use than the legacy waveIn APIs in this regard.

Now Jason Olson did provide a link to a cool sample application on GitHub, showing the use of these APIs in C++. However, there seems to be a general assumption that if you're using WASAPI you are going to be working in C++. This is probably true for pro audio music applications. Despite having invested a huge amount of my time over the last 12 years in creating a C# audio library, I still recommend to people needing the lowest possible latency that they should consider C++.

But I also know that there is a huge amount of audio related development that does not require super low latency, particularly when dealing with voice recordings such as telephony, radio or VOIP. Recording and replaying voice is something that many businesses want to create software for, and a C# API greatly simplifies the development process. Both my experience from supporting NAudio, and having worked a decade in the telecoms industry tells me that there is a huge market for applications that deal with speech in various formats.

Finally, I'd also like to see Microsoft give some thought to creating an audio buss that allows WinRT apps to transmit real-time audio between themselves, allowing you to link together virtual synthesizers with effects. This could form the basis of solving the audio plugin problem for DAW-like applications in the Windows store.

Anyway, they repeatedly asked for feedback during the talk, so that’s the direction I’d like to see WinRT audio APIs going in. Seamless support for using audio capture and render devices from C# with transparent resampling on playback and record.

Wednesday 2 April 2014

Stop Making Monoliths

Martin Fowler and James Lewis recently published an excellent article on microservices, which describes a new approach to architecting large enterprise systems, by composing them out of many independently deployable services, rather than producing a "monolith", which is usually one giant application that must be deployed/installed in one hit, and usually runs as a single process.

What's wrong with monoliths?

The trouble with monoliths is they become increasingly complex and unwieldy as the project grows larger. Despite our best intentions they usually become very tightly coupled, meaning components cannot be replaced or reused. Performance also becomes an issue, and there is no easy way to scale this approach other than to buy a more powerful server.

Why do we build them?

So why do we keep making monoliths? Two reasons. The first is simply because we can. I wrote a while ago about the fact that the vast increase in computing power has enabled us to build applications that are bigger than they ought to be.

The second reason is because it is the path of least resistance. It's far easier to put new code into the existing service, than to create a new service, which will require us to set up a new build and deployment process. So with a microservice architecture, you have to make it really easy to create a new service, or developers will end up bloating the existing services with additional features. Once the friction of creating new services is eliminated, you can begin to migrate away from your monolithic architecture.

What are the benefits of microservices over monoliths?

What benefits do microservices give over a monolithic architecture? Let me briefly mention two.

First microservices gives us real decoupling. Components in microservice architectures are actually replaceable rather than theoretically replaceable. The service boundary forces a radical decoupling of parts of our application, that is hard to enforce in a monolithic codebase, as it is too easy to circumvent (deliberately or unintentionally).

Second, it gives freedom to adopt new technology. Monoliths typically have to be built with one programming language, one database access technology, one dependency injection framework etc. It makes it easy to get stuck on legacy technology. But a microservice architecture allows you to incrementally improve your application to make use of better technologies, tools and practices.

There are plenty more benefits (not least the implications for scalability). But I'm hoping to blog more about other aspects of microservices, so I'll save them for next time.