♪ 一个低级别的库,可在多个平台上播放声音 ♪
A low-level library to play sound.
On some platforms you will need a C/C++ compiler in your path that Go can use.
clang on your terminal and a dialog with installation instructions will appear if you don't have itxcode-select --installOto requires AudioToolbox.framework, but this is automatically linked.
Oto requires these frameworks:
AVFoundation.frameworkAudioToolbox.frameworkAdd them to "Linked Frameworks and Libraries" on your Xcode project.
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.
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.
The following is an example of loading and playing an MP3 file:
…
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).
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 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.
暂无开放 Issues，或尚未同步最近议题。