oto

Oto (v3)

A low-level library to play sound.

• Oto (v3)
  • Platforms
  • Prerequisite
    • macOS
    • iOS
    • Linux, FreeBSD, OpenBSD
  • Usage
    • Playing sounds from memory
    • Playing sounds by file streaming
    • Advanced usage
  • Crosscompiling

Platforms

• Windows (no Cgo required)
• macOS (no Cgo required)
• Linux (no Cgo required)
• FreeBSD (no Cgo required)
• OpenBSD (no Cgo required)
• Android
• iOS
• WebAssembly (no Cgo required)
• Nintendo Switch
• Xbox

Prerequisite

On some platforms you will need a C/C++ compiler in your path that Go can use.

• iOS: On newer macOS versions type clang on your terminal and a dialog with installation instructions will appear if you don't have it
  • If you get an error with clang use xcode instead xcode-select --install
• Console targets may still need a working C/C++ toolchain; if not installed, try GCC or Clang

macOS

Oto requires AudioToolbox.framework, but this is automatically linked.

iOS

Oto requires these frameworks:

• AVFoundation.framework
• AudioToolbox.framework

Add them to "Linked Frameworks and Libraries" on your Xcode project.

Linux, FreeBSD, OpenBSD

Oto uses PulseAudio on Linux and BSD systems via the pure-Go package github.com/jfreymuth/pulse, though BSD systems are not well tested.

If the PulseAudio server is not discoverable automatically, set PULSE_SERVER.

When no PulseAudio server is reachable, Oto falls back to ALSA. This fallback also requires no Cgo: libasound.so.2 is loaded dynamically at runtime, so no ALSA development headers are needed to build, though libasound.so.2 itself must be present at runtime.

On FreeBSD, building with CGO_ENABLED=0 (for example when cross-compiling) additionally requires -gcflags="github.com/ebitengine/purego/internal/fakecgo=-std"; native FreeBSD builds, where Cgo is enabled by default, need nothing extra.

Usage

The two main components of Oto are Context and Player. The context handles interactions with the OS and audio drivers, and as such there can only be one context in your program.

From a context you can create any number of different players, where each player is given an io.Reader that it reads bytes representing sounds from and plays.

Note that a single io.Reader must not be used by multiple players.

Playing sounds from memory

The following is an example of loading and playing an MP3 file:

…

Playing sounds by file streaming

The above example loads the entire file into memory and then plays it. This is great for smaller files but might be an issue if you are playing a long song since it would take too much memory and too long to load.

In such cases you might want to stream the file. Luckily this is very simple, just use os.Open:

…

The only thing to note about streaming is that the file object must be kept alive, otherwise you might just play static.

To keep it alive not only must you be careful about when you close it, but you might need to keep a reference to the original file object alive (by for example keeping it in a struct).

Advanced usage

Players have their own internal audio data buffer, so while for example 200 bytes have been read from the io.Reader that doesn't mean they were all played from the audio device.

Data is moved from io.Reader->internal buffer->audio device, and when the internal buffer moves data to the audio device is not guaranteed, so there might be a small delay. The amount of data in the buffer can be retrieved using Player.BufferedSize().

The size of the underlying buffer of a player can also be set by calling the player's SetBufferSize function:

myPlayer.SetBufferSize(newBufferSize)

NewPlayer returns a *oto.Player, which has functions like SetBufferSize and Seek.

Crosscompiling

Crosscompiling to macOS, Windows, Linux or BSD is as easy as setting GOOS=darwin, GOOS=windows, GOOS=linux or GOOS=freebsd (or your particular BSD flavor) respectively.

To crosscompile for other platforms, make sure the libraries for the target architecture are installed, and set CGO_ENABLED=1 as Go disables Cgo on crosscompiles by default.