diff options
Diffstat (limited to 'chromium/docs/website/site/chromium-os/chromiumos-design-docs/cras-chromeos-audio-server/index.md')
| -rw-r--r-- | chromium/docs/website/site/chromium-os/chromiumos-design-docs/cras-chromeos-audio-server/index.md | 123 |
1 files changed, 0 insertions, 123 deletions
diff --git a/chromium/docs/website/site/chromium-os/chromiumos-design-docs/cras-chromeos-audio-server/index.md b/chromium/docs/website/site/chromium-os/chromiumos-design-docs/cras-chromeos-audio-server/index.md deleted file mode 100644 index 56b48044bbe..00000000000 --- a/chromium/docs/website/site/chromium-os/chromiumos-design-docs/cras-chromeos-audio-server/index.md +++ /dev/null @@ -1,123 +0,0 @@ ---- -breadcrumbs: -- - /chromium-os - - Chromium OS -- - /chromium-os/chromiumos-design-docs - - Design Documents -page_name: cras-chromeos-audio-server -title: 'CRAS: Chromium OS Audio Server' ---- - -## Why - -Chromium OS needs a way to route audio to different devices. Currently Chromium -OS only plays audio to the first ALSA device in the system. Devices attached -after boot are ignored, and no priority is given to the built in sound device. -The goal of the new server is to allow for sound to be routed dynamically to -newly attached audio-capable monitors (DisplayPort and HDMI), USB webcam, USB -speakers, bluetooth headsets, etc. And to do this in a way that requires as -little CPU as possible and that adds little or no latency. - -## How - -Put an audio server in between Chromium and ALSA that can change how audio flows -on the fly. Chromium will connect to this audio server, send audio data to it, -and the audio server will render this to the selected ALSA device through -alsa-lib. For input the process will be reversed, the server will get audio -samples from alsa and forward them to Chromium. - -## Details - -The design decisions were driven by three main requirements: Low Latency, Low -CPU usage, and dynamic audio routing. This will handle the streaming of PCM -only; audio decode will all be done in Chromium. - -The basic design combines the timer-driven wakeup scheme of pulseaudio with the -synchronous audio callbacks of JACK. This synchronous callback eliminates local -buffering of data in the server, allowing the server to wake up less for a given -latency. The server wakes up when a timer fires, sometime before there is an -ALSA over/underrun and calls back to Chromium to get/put audio data. This -minimizes latency as the only additional latency needed is that to exchange IPC -messages between the server and client. Because ALSA wakeups aren’t used, on -some devices the minimal latency will be lower than without the server; there is -no need to wake up at an ALSA period boundary. The timer can be armed to wake up -when there are an arbitrary number of samples left in the hardware buffer. ALSA -will always be configured with the largest possible buffer size, yet only some -fraction of that will be used at any given time. - -Audio data will be exchanged through shared memory so that no copying is needed -(except into the ALSA buffer). Communication will happen through UNIX domain -sockets. There will be separate communication connections for control (high -latency, lower priority) and audio data (low latency and higher priority). - -At each wakeup a timestamp will be updated that, for playback streams, will -indicate the exact time at which the next written sample will be rendered to the -DAC. For capture, the timestamp will reflect the actual time the sample was -captured at the ADC. - -The key to keeping system resource usage low is to do as little as possible in -the server when it wakes up and similar for the callback in the client. Less -than two percent of the CPU of a CR48 is used while playing back audio with 20ms -latency and waking up every 10ms. The minimum the server can do is read in the -streams, mix them, and write the result to ALSA. Other processing can take place -in the server; DSP blocks can be configured to process the buffers as they pass -through, this will add to the processing time and increase the minimum latency. - -The lowest latency stream will be used to drive the timer wakeup interval (and -will have the most accurate latency). Only clients that need to send more data -will be woken. - -### Device Enumeration - -The server keeps a separate list of inputs and outputs. The server will listen -to udev events that notify it of newly added or removed devices. Whenever a -device appears or disappears, the priority list of devices will be re-evaluated -and the highest priority device will be used. - -Devices will be given a priority based on the device type and the time they are -inserted. The priority is as follows (for both input and output): - -1. Headset jack and USB audio devices. -2. DisplayPort and HDMI outputs (when EDID indicates the sink is audio - capable). -3. Built-in speakers. - -If two devices of the same priority are attached, the device that was plugged -most recently wins. - -On device removal, all streams are removed from the device and the device is -closed. The streams will be moved to the next device in the list when this -happens. - -### Mixing - -The server is required to mix for the case where multiple streams are being -played at once. The mixing will be done immediately before the samples are sent -to the playback hardware. If a DSP block is enabled, it will be applied -post-mix. - -### Per-Board Configuration - -Without a config, the server will automatically discover devices and mute/volume -controls. This provides all that is needed for x86 most of the time. On x86 the -main use of config files is to set volume level mappings between the UI and -hardware, and to configure codec-specific features. - -The volume curve file is per-codec, per-device and the format is described in -the main README file. - -ALSA UCM is used to do low level codec config. On ARM systems, this setup is -necessary to get audio paths routed correctly when a headset is attached and to -initialize codec setup after start up. In addition to this, the UCM file is used -to map jacks to audio devices. - -### More documents - -* [Chrome OS Audio Software - Overview](https://docs.google.com/document/d/1pDdzlJlNacvOB8CS4Qxg-0aQvEuCK8lFKaWaqckSl3w/edit?usp=sharing) -* [CRAS ELC - 2014.pdf](https://drive.google.com/file/d/1WBYe-M_xFaHIajn-hfQRBrKhPkbgHNF9/view?usp=sharing) -* [Gain in - CRAS](https://docs.google.com/document/d/1FfTGylzC-uGPhzxnotfxXjDeBPRPIMxkzqdQbQWJ7aE/edit?usp=sharing) -* [UCM Usage - Guide](https://docs.google.com/document/d/1AcXZI9dvJBW0Vy6h9vraD7VP9X_MpwHx0eJ6hNc4G_s/edit?usp=sharing)
\ No newline at end of file |