Linux Audio: Origins & Futures Paul Davis Linux Audio Systems - - PowerPoint PPT Presentation
Linux Audio: Origins & Futures Paul Davis Linux Audio Systems Linux Plumbers Conference, 2009 Introduction Who am I Why am I here What is good about Linux audio support? What is bad about it? How did it get this way?
Linux Plumbers Conference, 2009
Hardware (DMA) buffer Write pointer Read pointer User Space Hardware (A/D or digital I/O) Optional extra buffering
Hardware (DMA) buffer Read pointer Write pointer User Space Hardware (A/D or digital I/O) Optional extra buffering
1
Linux Audio: Origins & Futures Paul Davis
Linux Audio Systems
Linux Plumbers Conference, 2009
2
Introduction
3
Who & Why
in 1998
2000, including RME support.
workstation.
more than 10 years
4
Who & Why: 2
use
support
the state of audio support
5
What audio support is needed?
audio interface and/or any network connection
between applications
request or as h/w reconfiguration occurs
6
Two Perspectives
support exists?
audio support exists?
some references to the former
7
History of Linux Audio Support
Savolainen writes drivers for the Creative
Open Sound System (OSS), which also runs on
more devices
OSS is growing, Jaroslav Kysela begins work
(ALSA)
sample rate, no more than 4 channels
8
History 2
times to reflect new high end audio interfaces, along with attempts to “improve” the API.
Sequencer, a kernel-space MIDI router and scheduler.
kernel community in favor of OSS as the official driver system for audio on Linux.
NDAs and closed source drivers.
9
History 3
community discusses techniques to connect applications to each other
from Ardour's own audio engine.
latency in the kernel begins, continues,
and other kernel developers regarding RT patches and access to RT scheduling
10
History 4
continue to improve kernel latency
access to RT scheduling and memory locking to standard mechanisms
not provide this.
11
History 5
for desktop applications, start implementing their own libraries (Phonon, libsydney)
devices
12
Audio H/W Basics
Hardware (DMA) buffer Write pointer Read pointer User Space Hardware (A/D or digital I/O) Optional extra buffering
CAPTURE/RECORDING
13
Audio H/W Basics
Hardware (DMA) buffer Read pointer Write pointer User Space Hardware (A/D or digital I/O) Optional extra buffering
PLAYBACK
14
Push & Pull Models
audio data, and how much to read/write.
architecture determine when to read/write audio data and how much to read/write.
to handle arbitrary behaviour by the application
capable of meeting externally imposed deadlines.
15
Key Point
is easy: just add buffering and an API
is hard, and performs badly.
include push-based APIs layered above it to support application design that requires it.
16
How Should Applications Access Audio Support?
the usual Unix open/close/read/write/ioctl/ select/mmap system calls.
library (libasound) that presents a huge set of functions to control:
17
The Video/Audio Comparison
generates human sensory experience (vision/display, hearing/speakers)
data buffer and then “rendering” its contents to the output medium
applications, the desired output doesn't change very often (eg. GUIs)
18
Audio/Video Comparison 2
application that wants to display stuff on a screen with open/read/write/close?
been mediated by either a server, or a server- like API.
audio?
19
The Problem with Unix
kernel.
bytes I give you, whenever”
me whatever bytes you discover, ASAP”
20
Unix Issues 2
be used to interact with realtime devices
application design, does not encourage considering temporal aspects, does not deal with data formats.
with video or audio interfaces.
21
What we want
esque API
22
What we don't want
the API requires it
they are actually in user space (via user space FS)
control hardware devices
23
What We Can (maybe) Factor Out
API.
identified, high quality libraries for format conversion and SRC.
control, even for the hardware mixer.
24
OSS API MUST DIE!
services provided are implemented in the kernel
encourages, developers to use application design that doesn't play well with others
relevant.
25
Why didn't we fix this in 2000?
important
ALSA
API
anyway
26
CoreAudio's introduction on OS X
simplistic audio API and infrastructure
for OS X
feedback requested on basic issues.
adequately supports desktop, consumer media and professional applications.
27
The Windows Experience
OS X to support really low latency audio I/O
user space APIs on top of pull model system architecture.
developers could switch if desired.
28
JACK & PulseAudio
synchronous execution of clients, single data format, single sample rate, some h/w
primary targets.
consumption are high priorities, desktop and consumer usage dominate feature set, few h/w requirements.
29
Do We Need Both?
desktop and consumer apps.
and music creation apps; offers valuable services for desktops and consumer uses.
kernel mixing latency) + ASIO (similar design to JACK, used by almost all music creation apps)
30
Do We Have A Stick?
Linux?
to improve the audio infrastructure?
design goals (e.g. PulseAudio and JACK)
audio I/O on linux really is
31
Where is the mixer?
in hardware (most don't), access to the device by multiple apps requires a mixer, somewhere.
the kernel
users
32
The Importance of Timing
interrupts and registers to understand where the h/w read and write ptrs are
interrupts are asynchronous WRT the sample clock (USB, FireWire, network audio)
control system) to predict positions
access models) much easier because accurate time/position predictions are always available
33
A Unified API?
that can be done w/CoreAudio too
library? Many libraries?
about X Window, DirectFB etc)
34
Thanks...
Alaska Airlines for taking 13 hours to get me across the country.
for me to work full time on libre audio & MIDI software.