Commercial Hardware tools and the eSDK are available only for approved partners

The Spotify Embedded SDK is NOT thread-safe.

You must make sure that you only ever invoke Spotify Embedded APIs from the same thread. This means, if you invoked SpInit() from one thread, all subsequent actions in the Spotify Embedded SDK must be performed from the same thread. If, for example, your application has a separate UI thread that needs to invoke APIs, the recommended way of doing this is to make your UI thread send an application-specific message to the other thread.

On most platforms, the Spotify Embedded SDK will return the error kSpErrorMultiThreadingDetected if you invoke APIs from different threads. (On some platforms, the SDK is unable to detect this, and the behavior will be undefined.)

This is how the example code in the SDK package solves the issue of multiple threads: Instead of invoking the API from the UI thread, you can send some form of message to the main Embedded SDK thread, and have the main thread execute the API between calls to SpPumpEvents().

Note For simplicity, the following code simply sets an integer when a button is pressed, and the main thread executes the API when the integer is set. You could use a proper message queue instead.

/* Recommended implementation */

enum ButtonID {
  kButtonNone = 0,
  kButtonSkipToNext = 1
};

int button_pressed = kButtonNone;

void MainESDKThread(void) {
  while (!shutdown) {
    if (button_pressed == kButtonSkipToNext) {
      SpPlaybackSkipToNext();
      button_pressed = kButtonNone;
    }
    SpPumpEvents();
  }
}

void UIThread(void) {
  while (!shutdown) {
    if (NextButtonWasPressed()) {
      button_pressed = kButtonSkipToNext;
    }
  }
}

Other considerations

If you implement ZeroConf, the web server that handles ZeroConf requests might run in a different thread as well. Make sure to add proper message-passing so that the web server thread does not invoke Embedded SDK APIs from its own thread.