Back to files

This is a buffered audio player using POSIX-threads in buffering audio data. Currently supported audio devices are Linux, Solaris, OpenBSD, NetBSD and FreeBSD. Any OS using OSS audio library should work in theory.

This is still considered BETA software and may not work as expected. Please mail me for bug reports, opinions or suggestions.

RIFF/WAVE (WAV) and Sun audio (AU) file headers are recognised.

Command line options:

tplay [-hvVmuxrf] [-s Hz] [-b 8|16] [-B kilobytes] [filename]

        -h, --help              Print help, then exit
        -v, --version           Print version, then exit
        -V, --verbose           Print useful information about the sample
        -x, --swap              Swap endianness
        -r, --raw               Force raw audio format. Ignore headers.
        -f, --force             Force playing with any parameters
        -m, --mono              Mono sample
        -u, --usage             Print buffer usage while playing
        -s, --speed=SPEED       Sample speed (Hz)
        -b, --bytes=BYTES       Bytes in a sample
        -B, --buffer-size=SIZE  Buffer size in (kB)

Buffer size is defaulted to 512k. It is about 3 seconds CD audio (44100Hz/sample, 16bytes, stereo). If filename is not given, standard input is used. If -x (or --swap) flag is set, the byte order of audio sample is swapped before playing. The default is little endian or big endian according to hardware and it is guessed by configure script.

Option -r (or --raw) forces tplay to handle the sample as an raw PCM audio sample. Sun audio or WAV headers are ignored.

Requirements

• Supported OS with audio card support
• POSIX thread library
• Audio card

The code:

tplay starts one thread, named consumer, that reads circular audio buffer and writes it to audio device. The producer is a function that runs in parallel with the consumer and its task is to read the sample file or standard input and write this data to audio buffer to meet consumer's needs. Usually, the buffer is full but on the times when CPU-time is suddenly needed for other processes (usually: disk read/write), the producer can't write fast enough and consumer can use the buffer to keep audio stream uninterrupted. If the buffer is used and the producer is still unable to feed it fast enough, underflow situation is met and consumer waits for awhile (typically: one second) for the producer to fill the buffer again.

Thanks

Jerko Golubovic <jerko.golubovic@public.srce.hr> Jukka Palviainen <oh3kjt@ele.tut.fi>
Derrick J Brashear <shadow+@andrew.cmu.edu> for fixes to Sun port

TODO

Find out the best sizes for the audio buffer and one block. Better documentation.
Better RIFF/WAVE checking.

Ilkka Karvinen
ik@iki.fi