Skip to content

Frequently asked questions

Audio stutters

On some hardware we have seen ALSA defaulting to a very small buffer size. A 44.1Khz two channel PCM stream is 88 200 samples/per second. In the below example that’s a context switch 200 times a second (every 5ms). Now a small buffer size is great for low latency game and sound applications where instant sound feedback is needed on user input. This is not the case for audio streaming. With these small buffers we can’t feed ALSA with audio fast enough, so we will get -EPIPE from snd_pcm_writei().

Alsa initialized, buffer_size: 1323 period_size: 441

Set the ALSA buffer size to at least 1 period (second). For 44.1Khz two channel PCM stream is buffer size 88 200 samples and a period size of 22 050 samples. We have provided the code in callbacks_alsa.c. You could try to set the buffer size to 4 periods instead.

Alsa initialized, buffer_size: 88200 period_size: 22050

Can we run multiple instances of the SDK per device?

The SDK supports running multiple, independent instances on a single device, provided the following conditions are met:

  • Audio Hardware Support: The host device must be capable of mixing and playing back multiple audio streams simultaneously.
  • Unique Storage Paths: Each SDK instance must be configured with its own unique filesystem path data directory and caching.

Warning

Never allow two instances to share the same cache or data directory. Doing so will lead to resource conflicts, unpredictable behavior, and potential data corruption.

Can we run multiple sound zones on a single SDK instance?

Rule of thumb, one instance of SDK is equal to one sound zone.

The Soundtrack system is built on a hierarchy where a business account can have multiple locations, and each location can contain several sound zones—like a "Dance Floor" or "Dining Area"—to play different music in distinct spaces. The SDK instance on that device, therefore, manages the connection and audio playback exclusively for the one sound zone it's paired with. If a business wants the same music throughout a venue, they simply use one device for one sound zone and distribute that audio through their own sound system.

Older version of libstdc++ and ld.so running on the target.

Depending on GCC version you might have an older version of libc, libstdc++ and ld.

./libSplayer_alsa: /lib/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by libSplayer.so)
./libSplayer_alsa: /lib/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by libSplayer.so)
./libSplayer_alsa: /lib/libstdc++.so.6: version `GLIBCXX_3.4.19' not found (required by libSplayer.so)
./libSplayer_alsa: /lib/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by libSplayer.so)

If needed, we can link libstdc++ statically to avoid most of the issues, but your target platform needs a compatible libc.so. Use the same version of libc and libstdc++ on your target as in the toolchain that you provide us. For Linux, you can create them using Yocto or Buildroot. Be aware that we are using atomics from c++ 11, and some gcc toolchains put these in a separate library called libatomic.so. This library is required on the device for our player to run.