Merge remote-tracking branch 'sound/topic/restize-docs' into sound
Bring in the sphinxification of the sound documentation.
This commit is contained in:
Jonathan Corbet
Коммит
726d661fea
|
|
@ -12,8 +12,7 @@ DOCBOOKS := z8530book.xml \
|
|||
kernel-api.xml filesystems.xml lsm.xml kgdb.xml \
|
||||
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
|
||||
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
|
||||
debugobjects.xml sh.xml regulator.xml \
|
||||
alsa-driver-api.xml writing-an-alsa-driver.xml \
|
||||
80211.xml debugobjects.xml sh.xml regulator.xml \
|
||||
tracepoint.xml w1.xml \
|
||||
writing_musb_glue_layer.xml crypto-API.xml iio.xml
|
||||
|
||||
|
|
|
|||
|
|
@ -1,142 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
|
||||
|
||||
<!-- ****************************************************** -->
|
||||
<!-- Header -->
|
||||
<!-- ****************************************************** -->
|
||||
<book id="ALSA-Driver-API">
|
||||
<bookinfo>
|
||||
<title>The ALSA Driver API</title>
|
||||
|
||||
<legalnotice>
|
||||
<para>
|
||||
This document is free; you can redistribute it and/or modify it
|
||||
under the terms of the GNU General Public License as published by
|
||||
the Free Software Foundation; either version 2 of the License, or
|
||||
(at your option) any later version.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This document is distributed in the hope that it will be useful,
|
||||
but <emphasis>WITHOUT ANY WARRANTY</emphasis>; without even the
|
||||
implied warranty of <emphasis>MERCHANTABILITY or FITNESS FOR A
|
||||
PARTICULAR PURPOSE</emphasis>. See the GNU General Public License
|
||||
for more details.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You should have received a copy of the GNU General Public
|
||||
License along with this program; if not, write to the Free
|
||||
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
|
||||
MA 02111-1307 USA
|
||||
</para>
|
||||
</legalnotice>
|
||||
|
||||
</bookinfo>
|
||||
|
||||
<toc></toc>
|
||||
|
||||
<chapter><title>Management of Cards and Devices</title>
|
||||
<sect1><title>Card Management</title>
|
||||
!Esound/core/init.c
|
||||
</sect1>
|
||||
<sect1><title>Device Components</title>
|
||||
!Esound/core/device.c
|
||||
</sect1>
|
||||
<sect1><title>Module requests and Device File Entries</title>
|
||||
!Esound/core/sound.c
|
||||
</sect1>
|
||||
<sect1><title>Memory Management Helpers</title>
|
||||
!Esound/core/memory.c
|
||||
!Esound/core/memalloc.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
<chapter><title>PCM API</title>
|
||||
<sect1><title>PCM Core</title>
|
||||
!Esound/core/pcm.c
|
||||
!Esound/core/pcm_lib.c
|
||||
!Esound/core/pcm_native.c
|
||||
!Iinclude/sound/pcm.h
|
||||
</sect1>
|
||||
<sect1><title>PCM Format Helpers</title>
|
||||
!Esound/core/pcm_misc.c
|
||||
</sect1>
|
||||
<sect1><title>PCM Memory Management</title>
|
||||
!Esound/core/pcm_memory.c
|
||||
</sect1>
|
||||
<sect1><title>PCM DMA Engine API</title>
|
||||
!Esound/core/pcm_dmaengine.c
|
||||
!Iinclude/sound/dmaengine_pcm.h
|
||||
</sect1>
|
||||
</chapter>
|
||||
<chapter><title>Control/Mixer API</title>
|
||||
<sect1><title>General Control Interface</title>
|
||||
!Esound/core/control.c
|
||||
</sect1>
|
||||
<sect1><title>AC97 Codec API</title>
|
||||
!Esound/pci/ac97/ac97_codec.c
|
||||
!Esound/pci/ac97/ac97_pcm.c
|
||||
</sect1>
|
||||
<sect1><title>Virtual Master Control API</title>
|
||||
!Esound/core/vmaster.c
|
||||
!Iinclude/sound/control.h
|
||||
</sect1>
|
||||
</chapter>
|
||||
<chapter><title>MIDI API</title>
|
||||
<sect1><title>Raw MIDI API</title>
|
||||
!Esound/core/rawmidi.c
|
||||
</sect1>
|
||||
<sect1><title>MPU401-UART API</title>
|
||||
!Esound/drivers/mpu401/mpu401_uart.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
<chapter><title>Proc Info API</title>
|
||||
<sect1><title>Proc Info Interface</title>
|
||||
!Esound/core/info.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
<chapter><title>Compress Offload</title>
|
||||
<sect1><title>Compress Offload API</title>
|
||||
!Esound/core/compress_offload.c
|
||||
!Iinclude/uapi/sound/compress_offload.h
|
||||
!Iinclude/uapi/sound/compress_params.h
|
||||
!Iinclude/sound/compress_driver.h
|
||||
</sect1>
|
||||
</chapter>
|
||||
<chapter><title>ASoC</title>
|
||||
<sect1><title>ASoC Core API</title>
|
||||
!Iinclude/sound/soc.h
|
||||
!Esound/soc/soc-core.c
|
||||
<!-- !Esound/soc/soc-cache.c no docbook comments here -->
|
||||
!Esound/soc/soc-devres.c
|
||||
!Esound/soc/soc-io.c
|
||||
!Esound/soc/soc-pcm.c
|
||||
!Esound/soc/soc-ops.c
|
||||
!Esound/soc/soc-compress.c
|
||||
</sect1>
|
||||
<sect1><title>ASoC DAPM API</title>
|
||||
!Esound/soc/soc-dapm.c
|
||||
</sect1>
|
||||
<sect1><title>ASoC DMA Engine API</title>
|
||||
!Esound/soc/soc-generic-dmaengine-pcm.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
<chapter><title>Miscellaneous Functions</title>
|
||||
<sect1><title>Hardware-Dependent Devices API</title>
|
||||
!Esound/core/hwdep.c
|
||||
</sect1>
|
||||
<sect1><title>Jack Abstraction Layer API</title>
|
||||
!Iinclude/sound/jack.h
|
||||
!Esound/core/jack.c
|
||||
!Esound/soc/soc-jack.c
|
||||
</sect1>
|
||||
<sect1><title>ISA DMA Helpers</title>
|
||||
!Esound/core/isadma.c
|
||||
</sect1>
|
||||
<sect1><title>Other Helper Macros</title>
|
||||
!Iinclude/sound/core.h
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
</book>
|
||||
Разница между файлами не показана из-за своего большого размера
Загрузить разницу
|
|
@ -58,6 +58,7 @@ needed).
|
|||
gpu/index
|
||||
80211/index
|
||||
security/index
|
||||
sound/index
|
||||
|
||||
Korean translations
|
||||
-------------------
|
||||
|
|
|
|||
Разница между файлами не показана из-за своего большого размера
Загрузить разницу
Разница между файлами не показана из-за своего большого размера
Загрузить разницу
|
|
@ -1,107 +0,0 @@
|
|||
This document describes standard names of mixer controls.
|
||||
|
||||
Syntax: [LOCATION] SOURCE [CHANNEL] [DIRECTION] FUNCTION
|
||||
|
||||
DIRECTION:
|
||||
<nothing> (both directions)
|
||||
Playback
|
||||
Capture
|
||||
Bypass Playback
|
||||
Bypass Capture
|
||||
|
||||
FUNCTION:
|
||||
Switch (on/off switch)
|
||||
Volume
|
||||
Route (route control, hardware specific)
|
||||
|
||||
CHANNEL:
|
||||
<nothing> (channel independent, or applies to all channels)
|
||||
Front
|
||||
Surround (rear left/right in 4.0/5.1 surround)
|
||||
CLFE
|
||||
Center
|
||||
LFE
|
||||
Side (side left/right for 7.1 surround)
|
||||
|
||||
LOCATION: (physical location of source)
|
||||
Front
|
||||
Rear
|
||||
Dock (docking station)
|
||||
Internal
|
||||
|
||||
SOURCE:
|
||||
Master
|
||||
Master Mono
|
||||
Hardware Master
|
||||
Speaker (internal speaker)
|
||||
Bass Speaker (internal LFE speaker)
|
||||
Headphone
|
||||
Line Out
|
||||
Beep (beep generator)
|
||||
Phone
|
||||
Phone Input
|
||||
Phone Output
|
||||
Synth
|
||||
FM
|
||||
Mic
|
||||
Headset Mic (mic part of combined headset jack - 4-pin headphone + mic)
|
||||
Headphone Mic (mic part of either/or - 3-pin headphone or mic)
|
||||
Line (input only, use "Line Out" for output)
|
||||
CD
|
||||
Video
|
||||
Zoom Video
|
||||
Aux
|
||||
PCM
|
||||
PCM Pan
|
||||
Loopback
|
||||
Analog Loopback (D/A -> A/D loopback)
|
||||
Digital Loopback (playback -> capture loopback - without analog path)
|
||||
Mono
|
||||
Mono Output
|
||||
Multi
|
||||
ADC
|
||||
Wave
|
||||
Music
|
||||
I2S
|
||||
IEC958
|
||||
HDMI
|
||||
SPDIF (output only)
|
||||
SPDIF In
|
||||
Digital In
|
||||
HDMI/DP (either HDMI or DisplayPort)
|
||||
|
||||
Exceptions (deprecated):
|
||||
[Analogue|Digital] Capture Source
|
||||
[Analogue|Digital] Capture Switch (aka input gain switch)
|
||||
[Analogue|Digital] Capture Volume (aka input gain volume)
|
||||
[Analogue|Digital] Playback Switch (aka output gain switch)
|
||||
[Analogue|Digital] Playback Volume (aka output gain volume)
|
||||
Tone Control - Switch
|
||||
Tone Control - Bass
|
||||
Tone Control - Treble
|
||||
3D Control - Switch
|
||||
3D Control - Center
|
||||
3D Control - Depth
|
||||
3D Control - Wide
|
||||
3D Control - Space
|
||||
3D Control - Level
|
||||
Mic Boost [(?dB)]
|
||||
|
||||
PCM interface:
|
||||
|
||||
Sample Clock Source { "Word", "Internal", "AutoSync" }
|
||||
Clock Sync Status { "Lock", "Sync", "No Lock" }
|
||||
External Rate /* external capture rate */
|
||||
Capture Rate /* capture rate taken from external source */
|
||||
|
||||
IEC958 (S/PDIF) interface:
|
||||
|
||||
IEC958 [...] [Playback|Capture] Switch /* turn on/off the IEC958 interface */
|
||||
IEC958 [...] [Playback|Capture] Volume /* digital volume control */
|
||||
IEC958 [...] [Playback|Capture] Default /* default or global value - read/write */
|
||||
IEC958 [...] [Playback|Capture] Mask /* consumer and professional mask */
|
||||
IEC958 [...] [Playback|Capture] Con Mask /* consumer mask */
|
||||
IEC958 [...] [Playback|Capture] Pro Mask /* professional mask */
|
||||
IEC958 [...] [Playback|Capture] PCM Stream /* the settings assigned to a PCM stream */
|
||||
IEC958 Q-subcode [Playback|Capture] Default /* Q-subcode bits */
|
||||
IEC958 Preamble [Playback|Capture] Default /* burst preamble words (4*16bits) */
|
||||
|
|
@ -1,324 +0,0 @@
|
|||
Model name Description
|
||||
---------- -----------
|
||||
ALC880
|
||||
======
|
||||
3stack 3-jack in back and a headphone out
|
||||
3stack-digout 3-jack in back, a HP out and a SPDIF out
|
||||
5stack 5-jack in back, 2-jack in front
|
||||
5stack-digout 5-jack in back, 2-jack in front, a SPDIF out
|
||||
6stack 6-jack in back, 2-jack in front
|
||||
6stack-digout 6-jack with a SPDIF out
|
||||
|
||||
ALC260
|
||||
======
|
||||
gpio1 Enable GPIO1
|
||||
coef Enable EAPD via COEF table
|
||||
fujitsu Quirk for FSC S7020
|
||||
fujitsu-jwse Quirk for FSC S7020 with jack modes and HP mic support
|
||||
|
||||
ALC262
|
||||
======
|
||||
inv-dmic Inverted internal mic workaround
|
||||
|
||||
ALC267/268
|
||||
==========
|
||||
inv-dmic Inverted internal mic workaround
|
||||
hp-eapd Disable HP EAPD on NID 0x15
|
||||
|
||||
ALC22x/23x/25x/269/27x/28x/29x (and vendor-specific ALC3xxx models)
|
||||
======
|
||||
laptop-amic Laptops with analog-mic input
|
||||
laptop-dmic Laptops with digital-mic input
|
||||
alc269-dmic Enable ALC269(VA) digital mic workaround
|
||||
alc271-dmic Enable ALC271X digital mic workaround
|
||||
inv-dmic Inverted internal mic workaround
|
||||
headset-mic Indicates a combined headset (headphone+mic) jack
|
||||
headset-mode More comprehensive headset support for ALC269 & co
|
||||
headset-mode-no-hp-mic Headset mode support without headphone mic
|
||||
lenovo-dock Enables docking station I/O for some Lenovos
|
||||
hp-gpio-led GPIO LED support on HP laptops
|
||||
dell-headset-multi Headset jack, which can also be used as mic-in
|
||||
dell-headset-dock Headset jack (without mic-in), and also dock I/O
|
||||
alc283-dac-wcaps Fixups for Chromebook with ALC283
|
||||
alc283-sense-combo Combo jack sensing on ALC283
|
||||
tpt440-dock Pin configs for Lenovo Thinkpad Dock support
|
||||
|
||||
ALC66x/67x/892
|
||||
==============
|
||||
mario Chromebook mario model fixup
|
||||
asus-mode1 ASUS
|
||||
asus-mode2 ASUS
|
||||
asus-mode3 ASUS
|
||||
asus-mode4 ASUS
|
||||
asus-mode5 ASUS
|
||||
asus-mode6 ASUS
|
||||
asus-mode7 ASUS
|
||||
asus-mode8 ASUS
|
||||
inv-dmic Inverted internal mic workaround
|
||||
dell-headset-multi Headset jack, which can also be used as mic-in
|
||||
|
||||
ALC680
|
||||
======
|
||||
N/A
|
||||
|
||||
ALC88x/898/1150
|
||||
======================
|
||||
acer-aspire-4930g Acer Aspire 4930G/5930G/6530G/6930G/7730G
|
||||
acer-aspire-8930g Acer Aspire 8330G/6935G
|
||||
acer-aspire Acer Aspire others
|
||||
inv-dmic Inverted internal mic workaround
|
||||
no-primary-hp VAIO Z/VGC-LN51JGB workaround (for fixed speaker DAC)
|
||||
|
||||
ALC861/660
|
||||
==========
|
||||
N/A
|
||||
|
||||
ALC861VD/660VD
|
||||
==============
|
||||
N/A
|
||||
|
||||
CMI9880
|
||||
=======
|
||||
minimal 3-jack in back
|
||||
min_fp 3-jack in back, 2-jack in front
|
||||
full 6-jack in back, 2-jack in front
|
||||
full_dig 6-jack in back, 2-jack in front, SPDIF I/O
|
||||
allout 5-jack in back, 2-jack in front, SPDIF out
|
||||
auto auto-config reading BIOS (default)
|
||||
|
||||
AD1882 / AD1882A
|
||||
================
|
||||
3stack 3-stack mode
|
||||
3stack-automute 3-stack with automute front HP (default)
|
||||
6stack 6-stack mode
|
||||
|
||||
AD1884A / AD1883 / AD1984A / AD1984B
|
||||
====================================
|
||||
desktop 3-stack desktop (default)
|
||||
laptop laptop with HP jack sensing
|
||||
mobile mobile devices with HP jack sensing
|
||||
thinkpad Lenovo Thinkpad X300
|
||||
touchsmart HP Touchsmart
|
||||
|
||||
AD1884
|
||||
======
|
||||
N/A
|
||||
|
||||
AD1981
|
||||
======
|
||||
basic 3-jack (default)
|
||||
hp HP nx6320
|
||||
thinkpad Lenovo Thinkpad T60/X60/Z60
|
||||
toshiba Toshiba U205
|
||||
|
||||
AD1983
|
||||
======
|
||||
N/A
|
||||
|
||||
AD1984
|
||||
======
|
||||
basic default configuration
|
||||
thinkpad Lenovo Thinkpad T61/X61
|
||||
dell_desktop Dell T3400
|
||||
|
||||
AD1986A
|
||||
=======
|
||||
3stack 3-stack, shared surrounds
|
||||
laptop 2-channel only (FSC V2060, Samsung M50)
|
||||
laptop-imic 2-channel with built-in mic
|
||||
eapd Turn on EAPD constantly
|
||||
|
||||
AD1988/AD1988B/AD1989A/AD1989B
|
||||
==============================
|
||||
6stack 6-jack
|
||||
6stack-dig ditto with SPDIF
|
||||
3stack 3-jack
|
||||
3stack-dig ditto with SPDIF
|
||||
laptop 3-jack with hp-jack automute
|
||||
laptop-dig ditto with SPDIF
|
||||
auto auto-config reading BIOS (default)
|
||||
|
||||
Conexant 5045
|
||||
=============
|
||||
laptop-hpsense Laptop with HP sense (old model laptop)
|
||||
laptop-micsense Laptop with Mic sense (old model fujitsu)
|
||||
laptop-hpmicsense Laptop with HP and Mic senses
|
||||
benq Benq R55E
|
||||
laptop-hp530 HP 530 laptop
|
||||
test for testing/debugging purpose, almost all controls
|
||||
can be adjusted. Appearing only when compiled with
|
||||
$CONFIG_SND_DEBUG=y
|
||||
|
||||
Conexant 5047
|
||||
=============
|
||||
laptop Basic Laptop config
|
||||
laptop-hp Laptop config for some HP models (subdevice 30A5)
|
||||
laptop-eapd Laptop config with EAPD support
|
||||
test for testing/debugging purpose, almost all controls
|
||||
can be adjusted. Appearing only when compiled with
|
||||
$CONFIG_SND_DEBUG=y
|
||||
|
||||
Conexant 5051
|
||||
=============
|
||||
laptop Basic Laptop config (default)
|
||||
hp HP Spartan laptop
|
||||
hp-dv6736 HP dv6736
|
||||
hp-f700 HP Compaq Presario F700
|
||||
ideapad Lenovo IdeaPad laptop
|
||||
toshiba Toshiba Satellite M300
|
||||
|
||||
Conexant 5066
|
||||
=============
|
||||
laptop Basic Laptop config (default)
|
||||
hp-laptop HP laptops, e g G60
|
||||
asus Asus K52JU, Lenovo G560
|
||||
dell-laptop Dell laptops
|
||||
dell-vostro Dell Vostro
|
||||
olpc-xo-1_5 OLPC XO 1.5
|
||||
ideapad Lenovo IdeaPad U150
|
||||
thinkpad Lenovo Thinkpad
|
||||
|
||||
STAC9200
|
||||
========
|
||||
ref Reference board
|
||||
oqo OQO Model 2
|
||||
dell-d21 Dell (unknown)
|
||||
dell-d22 Dell (unknown)
|
||||
dell-d23 Dell (unknown)
|
||||
dell-m21 Dell Inspiron 630m, Dell Inspiron 640m
|
||||
dell-m22 Dell Latitude D620, Dell Latitude D820
|
||||
dell-m23 Dell XPS M1710, Dell Precision M90
|
||||
dell-m24 Dell Latitude 120L
|
||||
dell-m25 Dell Inspiron E1505n
|
||||
dell-m26 Dell Inspiron 1501
|
||||
dell-m27 Dell Inspiron E1705/9400
|
||||
gateway-m4 Gateway laptops with EAPD control
|
||||
gateway-m4-2 Gateway laptops with EAPD control
|
||||
panasonic Panasonic CF-74
|
||||
auto BIOS setup (default)
|
||||
|
||||
STAC9205/9254
|
||||
=============
|
||||
ref Reference board
|
||||
dell-m42 Dell (unknown)
|
||||
dell-m43 Dell Precision
|
||||
dell-m44 Dell Inspiron
|
||||
eapd Keep EAPD on (e.g. Gateway T1616)
|
||||
auto BIOS setup (default)
|
||||
|
||||
STAC9220/9221
|
||||
=============
|
||||
ref Reference board
|
||||
3stack D945 3stack
|
||||
5stack D945 5stack + SPDIF
|
||||
intel-mac-v1 Intel Mac Type 1
|
||||
intel-mac-v2 Intel Mac Type 2
|
||||
intel-mac-v3 Intel Mac Type 3
|
||||
intel-mac-v4 Intel Mac Type 4
|
||||
intel-mac-v5 Intel Mac Type 5
|
||||
intel-mac-auto Intel Mac (detect type according to subsystem id)
|
||||
macmini Intel Mac Mini (equivalent with type 3)
|
||||
macbook Intel Mac Book (eq. type 5)
|
||||
macbook-pro-v1 Intel Mac Book Pro 1st generation (eq. type 3)
|
||||
macbook-pro Intel Mac Book Pro 2nd generation (eq. type 3)
|
||||
imac-intel Intel iMac (eq. type 2)
|
||||
imac-intel-20 Intel iMac (newer version) (eq. type 3)
|
||||
ecs202 ECS/PC chips
|
||||
dell-d81 Dell (unknown)
|
||||
dell-d82 Dell (unknown)
|
||||
dell-m81 Dell (unknown)
|
||||
dell-m82 Dell XPS M1210
|
||||
auto BIOS setup (default)
|
||||
|
||||
STAC9202/9250/9251
|
||||
==================
|
||||
ref Reference board, base config
|
||||
m1 Some Gateway MX series laptops (NX560XL)
|
||||
m1-2 Some Gateway MX series laptops (MX6453)
|
||||
m2 Some Gateway MX series laptops (M255)
|
||||
m2-2 Some Gateway MX series laptops
|
||||
m3 Some Gateway MX series laptops
|
||||
m5 Some Gateway MX series laptops (MP6954)
|
||||
m6 Some Gateway NX series laptops
|
||||
auto BIOS setup (default)
|
||||
|
||||
STAC9227/9228/9229/927x
|
||||
=======================
|
||||
ref Reference board
|
||||
ref-no-jd Reference board without HP/Mic jack detection
|
||||
3stack D965 3stack
|
||||
5stack D965 5stack + SPDIF
|
||||
5stack-no-fp D965 5stack without front panel
|
||||
dell-3stack Dell Dimension E520
|
||||
dell-bios Fixes with Dell BIOS setup
|
||||
dell-bios-amic Fixes with Dell BIOS setup including analog mic
|
||||
volknob Fixes with volume-knob widget 0x24
|
||||
auto BIOS setup (default)
|
||||
|
||||
STAC92HD71B*
|
||||
============
|
||||
ref Reference board
|
||||
dell-m4-1 Dell desktops
|
||||
dell-m4-2 Dell desktops
|
||||
dell-m4-3 Dell desktops
|
||||
hp-m4 HP mini 1000
|
||||
hp-dv5 HP dv series
|
||||
hp-hdx HP HDX series
|
||||
hp-dv4-1222nr HP dv4-1222nr (with LED support)
|
||||
auto BIOS setup (default)
|
||||
|
||||
STAC92HD73*
|
||||
===========
|
||||
ref Reference board
|
||||
no-jd BIOS setup but without jack-detection
|
||||
intel Intel DG45* mobos
|
||||
dell-m6-amic Dell desktops/laptops with analog mics
|
||||
dell-m6-dmic Dell desktops/laptops with digital mics
|
||||
dell-m6 Dell desktops/laptops with both type of mics
|
||||
dell-eq Dell desktops/laptops
|
||||
alienware Alienware M17x
|
||||
auto BIOS setup (default)
|
||||
|
||||
STAC92HD83*
|
||||
===========
|
||||
ref Reference board
|
||||
mic-ref Reference board with power management for ports
|
||||
dell-s14 Dell laptop
|
||||
dell-vostro-3500 Dell Vostro 3500 laptop
|
||||
hp-dv7-4000 HP dv-7 4000
|
||||
hp_cNB11_intquad HP CNB models with 4 speakers
|
||||
hp-zephyr HP Zephyr
|
||||
hp-led HP with broken BIOS for mute LED
|
||||
hp-inv-led HP with broken BIOS for inverted mute LED
|
||||
hp-mic-led HP with mic-mute LED
|
||||
headset-jack Dell Latitude with a 4-pin headset jack
|
||||
hp-envy-bass Pin fixup for HP Envy bass speaker (NID 0x0f)
|
||||
hp-envy-ts-bass Pin fixup for HP Envy TS bass speaker (NID 0x10)
|
||||
hp-bnb13-eq Hardware equalizer setup for HP laptops
|
||||
auto BIOS setup (default)
|
||||
|
||||
STAC92HD95
|
||||
==========
|
||||
hp-led LED support for HP laptops
|
||||
hp-bass Bass HPF setup for HP Spectre 13
|
||||
|
||||
STAC9872
|
||||
========
|
||||
vaio VAIO laptop without SPDIF
|
||||
auto BIOS setup (default)
|
||||
|
||||
Cirrus Logic CS4206/4207
|
||||
========================
|
||||
mbp55 MacBook Pro 5,5
|
||||
imac27 IMac 27 Inch
|
||||
auto BIOS setup (default)
|
||||
|
||||
Cirrus Logic CS4208
|
||||
===================
|
||||
mba6 MacBook Air 6,1 and 6,2
|
||||
gpio0 Enable GPIO 0 amp
|
||||
auto BIOS setup (default)
|
||||
|
||||
VIA VT17xx/VT18xx/VT20xx
|
||||
========================
|
||||
auto BIOS setup (default)
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
|
||||
VIA82xx mixer
|
||||
=============
|
||||
|
||||
On many VIA82xx boards, the 'Input Source Select' mixer control does not work.
|
||||
Setting it to 'Input2' on such boards will cause recording to hang, or fail
|
||||
with EIO (input/output error) via OSS emulation. This control should be left
|
||||
at 'Input1' for such cards.
|
||||
|
|
@ -1,135 +0,0 @@
|
|||
ALSA Kernel Parameters
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
See Documentation/admin-guide/kernel-parameters.rst for general information on
|
||||
specifying module parameters.
|
||||
|
||||
This document may not be entirely up to date and comprehensive. The command
|
||||
"modinfo -p ${modulename}" shows a current list of all parameters of a loadable
|
||||
module. Loadable modules, after being loaded into the running kernel, also
|
||||
reveal their parameters in /sys/module/${modulename}/parameters/. Some of these
|
||||
parameters may be changed at runtime by the command
|
||||
"echo -n ${value} > /sys/module/${modulename}/parameters/${parm}".
|
||||
|
||||
|
||||
snd-ad1816a= [HW,ALSA]
|
||||
|
||||
snd-ad1848= [HW,ALSA]
|
||||
|
||||
snd-ali5451= [HW,ALSA]
|
||||
|
||||
snd-als100= [HW,ALSA]
|
||||
|
||||
snd-als4000= [HW,ALSA]
|
||||
|
||||
snd-azt2320= [HW,ALSA]
|
||||
|
||||
snd-cmi8330= [HW,ALSA]
|
||||
|
||||
snd-cmipci= [HW,ALSA]
|
||||
|
||||
snd-cs4231= [HW,ALSA]
|
||||
|
||||
snd-cs4232= [HW,ALSA]
|
||||
|
||||
snd-cs4236= [HW,ALSA]
|
||||
|
||||
snd-cs4281= [HW,ALSA]
|
||||
|
||||
snd-cs46xx= [HW,ALSA]
|
||||
|
||||
snd-dt019x= [HW,ALSA]
|
||||
|
||||
snd-dummy= [HW,ALSA]
|
||||
|
||||
snd-emu10k1= [HW,ALSA]
|
||||
|
||||
snd-ens1370= [HW,ALSA]
|
||||
|
||||
snd-ens1371= [HW,ALSA]
|
||||
|
||||
snd-es968= [HW,ALSA]
|
||||
|
||||
snd-es1688= [HW,ALSA]
|
||||
|
||||
snd-es18xx= [HW,ALSA]
|
||||
|
||||
snd-es1938= [HW,ALSA]
|
||||
|
||||
snd-es1968= [HW,ALSA]
|
||||
|
||||
snd-fm801= [HW,ALSA]
|
||||
|
||||
snd-gusclassic= [HW,ALSA]
|
||||
|
||||
snd-gusextreme= [HW,ALSA]
|
||||
|
||||
snd-gusmax= [HW,ALSA]
|
||||
|
||||
snd-hdsp= [HW,ALSA]
|
||||
|
||||
snd-ice1712= [HW,ALSA]
|
||||
|
||||
snd-intel8x0= [HW,ALSA]
|
||||
|
||||
snd-interwave= [HW,ALSA]
|
||||
|
||||
snd-interwave-stb=
|
||||
[HW,ALSA]
|
||||
|
||||
snd-korg1212= [HW,ALSA]
|
||||
|
||||
snd-maestro3= [HW,ALSA]
|
||||
|
||||
snd-mpu401= [HW,ALSA]
|
||||
|
||||
snd-mtpav= [HW,ALSA]
|
||||
|
||||
snd-nm256= [HW,ALSA]
|
||||
|
||||
snd-opl3sa2= [HW,ALSA]
|
||||
|
||||
snd-opti92x-ad1848=
|
||||
[HW,ALSA]
|
||||
|
||||
snd-opti92x-cs4231=
|
||||
[HW,ALSA]
|
||||
|
||||
snd-opti93x= [HW,ALSA]
|
||||
|
||||
snd-pmac= [HW,ALSA]
|
||||
|
||||
snd-rme32= [HW,ALSA]
|
||||
|
||||
snd-rme96= [HW,ALSA]
|
||||
|
||||
snd-rme9652= [HW,ALSA]
|
||||
|
||||
snd-sb8= [HW,ALSA]
|
||||
|
||||
snd-sb16= [HW,ALSA]
|
||||
|
||||
snd-sbawe= [HW,ALSA]
|
||||
|
||||
snd-serial= [HW,ALSA]
|
||||
|
||||
snd-sgalaxy= [HW,ALSA]
|
||||
|
||||
snd-sonicvibes= [HW,ALSA]
|
||||
|
||||
snd-sun-amd7930=
|
||||
[HW,ALSA]
|
||||
|
||||
snd-sun-cs4231= [HW,ALSA]
|
||||
|
||||
snd-trident= [HW,ALSA]
|
||||
|
||||
snd-usb-audio= [HW,ALSA,USB]
|
||||
|
||||
snd-via82xx= [HW,ALSA]
|
||||
|
||||
snd-virmidi= [HW,ALSA]
|
||||
|
||||
snd-wavefront= [HW,ALSA]
|
||||
|
||||
snd-ymfpci= [HW,ALSA]
|
||||
|
|
@ -1,409 +0,0 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>OSS Sequencer Emulation on ALSA</TITLE>
|
||||
</HEAD>
|
||||
<BODY>
|
||||
|
||||
<CENTER>
|
||||
<H1>
|
||||
|
||||
<HR WIDTH="100%"></H1></CENTER>
|
||||
|
||||
<CENTER>
|
||||
<H1>
|
||||
OSS Sequencer Emulation on ALSA</H1></CENTER>
|
||||
|
||||
<HR WIDTH="100%">
|
||||
<P>Copyright (c) 1998,1999 by Takashi Iwai
|
||||
<TT><A HREF="mailto:iwai@ww.uni-erlangen.de"><iwai@ww.uni-erlangen.de></A></TT>
|
||||
<P>ver.0.1.8; Nov. 16, 1999
|
||||
<H2>
|
||||
|
||||
<HR WIDTH="100%"></H2>
|
||||
|
||||
<H2>
|
||||
1. Description</H2>
|
||||
This directory contains the OSS sequencer emulation driver on ALSA. Note
|
||||
that this program is still in the development state.
|
||||
<P>What this does - it provides the emulation of the OSS sequencer, access
|
||||
via
|
||||
<TT>/dev/sequencer</TT> and <TT>/dev/music</TT> devices.
|
||||
The most of applications using OSS can run if the appropriate ALSA
|
||||
sequencer is prepared.
|
||||
<P>The following features are emulated by this driver:
|
||||
<UL>
|
||||
<LI>
|
||||
Normal sequencer and MIDI events:</LI>
|
||||
|
||||
<BR>They are converted to the ALSA sequencer events, and sent to the corresponding
|
||||
port.
|
||||
<LI>
|
||||
Timer events:</LI>
|
||||
|
||||
<BR>The timer is not selectable by ioctl. The control rate is fixed to
|
||||
100 regardless of HZ. That is, even on Alpha system, a tick is always
|
||||
1/100 second. The base rate and tempo can be changed in <TT>/dev/music</TT>.
|
||||
|
||||
<LI>
|
||||
Patch loading:</LI>
|
||||
|
||||
<BR>It purely depends on the synth drivers whether it's supported since
|
||||
the patch loading is realized by callback to the synth driver.
|
||||
<LI>
|
||||
I/O controls:</LI>
|
||||
|
||||
<BR>Most of controls are accepted. Some controls
|
||||
are dependent on the synth driver, as well as even on original OSS.</UL>
|
||||
Furthermore, you can find the following advanced features:
|
||||
<UL>
|
||||
<LI>
|
||||
Better queue mechanism:</LI>
|
||||
|
||||
<BR>The events are queued before processing them.
|
||||
<LI>
|
||||
Multiple applications:</LI>
|
||||
|
||||
<BR>You can run two or more applications simultaneously (even for OSS sequencer)!
|
||||
However, each MIDI device is exclusive - that is, if a MIDI device is opened
|
||||
once by some application, other applications can't use it. No such a restriction
|
||||
in synth devices.
|
||||
<LI>
|
||||
Real-time event processing:</LI>
|
||||
|
||||
<BR>The events can be processed in real time without using out of bound
|
||||
ioctl. To switch to real-time mode, send ABSTIME 0 event. The followed
|
||||
events will be processed in real-time without queued. To switch off the
|
||||
real-time mode, send RELTIME 0 event.
|
||||
<LI>
|
||||
<TT>/proc</TT> interface:</LI>
|
||||
|
||||
<BR>The status of applications and devices can be shown via <TT>/proc/asound/seq/oss</TT>
|
||||
at any time. In the later version, configuration will be changed via <TT>/proc</TT>
|
||||
interface, too.</UL>
|
||||
|
||||
<H2>
|
||||
2. Installation</H2>
|
||||
Run configure script with both sequencer support (<TT>--with-sequencer=yes</TT>)
|
||||
and OSS emulation (<TT>--with-oss=yes</TT>) options. A module <TT>snd-seq-oss.o</TT>
|
||||
will be created. If the synth module of your sound card supports for OSS
|
||||
emulation (so far, only Emu8000 driver), this module will be loaded automatically.
|
||||
Otherwise, you need to load this module manually.
|
||||
<P>At beginning, this module probes all the MIDI ports which have been
|
||||
already connected to the sequencer. Once after that, the creation and deletion
|
||||
of ports are watched by announcement mechanism of ALSA sequencer.
|
||||
<P>The available synth and MIDI devices can be found in proc interface.
|
||||
Run "<TT>cat /proc/asound/seq/oss</TT>", and check the devices. For example,
|
||||
if you use an AWE64 card, you'll see like the following:
|
||||
<PRE> OSS sequencer emulation version 0.1.8
|
||||
ALSA client number 63
|
||||
ALSA receiver port 0
|
||||
|
||||
Number of applications: 0
|
||||
|
||||
Number of synth devices: 1
|
||||
|
||||
synth 0: [EMU8000]
|
||||
type 0x1 : subtype 0x20 : voices 32
|
||||
capabilties : ioctl enabled / load_patch enabled
|
||||
|
||||
Number of MIDI devices: 3
|
||||
|
||||
midi 0: [Emu8000 Port-0] ALSA port 65:0
|
||||
capability write / opened none
|
||||
|
||||
midi 1: [Emu8000 Port-1] ALSA port 65:1
|
||||
capability write / opened none
|
||||
|
||||
midi 2: [0: MPU-401 (UART)] ALSA port 64:0
|
||||
capability read/write / opened none</PRE>
|
||||
Note that the device number may be different from the information of
|
||||
<TT>/proc/asound/oss-devices</TT>
|
||||
or ones of the original OSS driver. Use the device number listed in <TT>/proc/asound/seq/oss</TT>
|
||||
to play via OSS sequencer emulation.
|
||||
<H2>
|
||||
3. Using Synthesizer Devices</H2>
|
||||
Run your favorite program. I've tested playmidi-2.4, awemidi-0.4.3, gmod-3.1
|
||||
and xmp-1.1.5. You can load samples via <TT>/dev/sequencer</TT> like sfxload,
|
||||
too.
|
||||
<P>If the lowlevel driver supports multiple access to synth devices (like
|
||||
Emu8000 driver), two or more applications are allowed to run at the same
|
||||
time.
|
||||
<H2>
|
||||
4. Using MIDI Devices</H2>
|
||||
So far, only MIDI output was tested. MIDI input was not checked at all,
|
||||
but hopefully it will work. Use the device number listed in <TT>/proc/asound/seq/oss</TT>.
|
||||
Be aware that these numbers are mostly different from the list in
|
||||
<TT>/proc/asound/oss-devices</TT>.
|
||||
<H2>
|
||||
5. Module Options</H2>
|
||||
The following module options are available:
|
||||
<UL>
|
||||
<LI>
|
||||
<TT>maxqlen</TT></LI>
|
||||
|
||||
<BR>specifies the maximum read/write queue length. This queue is private
|
||||
for OSS sequencer, so that it is independent from the queue length of ALSA
|
||||
sequencer. Default value is 1024.
|
||||
<LI>
|
||||
<TT>seq_oss_debug</TT></LI>
|
||||
|
||||
<BR>specifies the debug level and accepts zero (= no debug message) or
|
||||
positive integer. Default value is 0.</UL>
|
||||
|
||||
<H2>
|
||||
6. Queue Mechanism</H2>
|
||||
OSS sequencer emulation uses an ALSA priority queue. The
|
||||
events from <TT>/dev/sequencer</TT> are processed and put onto the queue
|
||||
specified by module option.
|
||||
<P>All the events from <TT>/dev/sequencer</TT> are parsed at beginning.
|
||||
The timing events are also parsed at this moment, so that the events may
|
||||
be processed in real-time. Sending an event ABSTIME 0 switches the operation
|
||||
mode to real-time mode, and sending an event RELTIME 0 switches it off.
|
||||
In the real-time mode, all events are dispatched immediately.
|
||||
<P>The queued events are dispatched to the corresponding ALSA sequencer
|
||||
ports after scheduled time by ALSA sequencer dispatcher.
|
||||
<P>If the write-queue is full, the application sleeps until a certain amount
|
||||
(as default one half) becomes empty in blocking mode. The synchronization
|
||||
to write timing was implemented, too.
|
||||
<P>The input from MIDI devices or echo-back events are stored on read FIFO
|
||||
queue. If application reads <TT>/dev/sequencer</TT> in blocking mode, the
|
||||
process will be awaked.
|
||||
|
||||
<H2>
|
||||
7. Interface to Synthesizer Device</H2>
|
||||
|
||||
<H3>
|
||||
7.1. Registration</H3>
|
||||
To register an OSS synthesizer device, use <TT>snd_seq_oss_synth_register</TT>
|
||||
function.
|
||||
<PRE>int snd_seq_oss_synth_register(char *name, int type, int subtype, int nvoices,
|
||||
snd_seq_oss_callback_t *oper, void *private_data)</PRE>
|
||||
The arguments <TT>name</TT>, <TT>type</TT>, <TT>subtype</TT> and
|
||||
<TT>nvoices</TT>
|
||||
are used for making the appropriate synth_info structure for ioctl. The
|
||||
return value is an index number of this device. This index must be remembered
|
||||
for unregister. If registration is failed, -errno will be returned.
|
||||
<P>To release this device, call <TT>snd_seq_oss_synth_unregister function</TT>:
|
||||
<PRE>int snd_seq_oss_synth_unregister(int index),</PRE>
|
||||
where the <TT>index</TT> is the index number returned by register function.
|
||||
<H3>
|
||||
7.2. Callbacks</H3>
|
||||
OSS synthesizer devices have capability for sample downloading and ioctls
|
||||
like sample reset. In OSS emulation, these special features are realized
|
||||
by using callbacks. The registration argument oper is used to specify these
|
||||
callbacks. The following callback functions must be defined:
|
||||
<PRE>snd_seq_oss_callback_t:
|
||||
int (*open)(snd_seq_oss_arg_t *p, void *closure);
|
||||
int (*close)(snd_seq_oss_arg_t *p);
|
||||
int (*ioctl)(snd_seq_oss_arg_t *p, unsigned int cmd, unsigned long arg);
|
||||
int (*load_patch)(snd_seq_oss_arg_t *p, int format, const char *buf, int offs, int count);
|
||||
int (*reset)(snd_seq_oss_arg_t *p);
|
||||
Except for <TT>open</TT> and <TT>close</TT> callbacks, they are allowed
|
||||
to be NULL.
|
||||
<P>Each callback function takes the argument type snd_seq_oss_arg_t as the
|
||||
first argument.
|
||||
<PRE>struct snd_seq_oss_arg_t {
|
||||
int app_index;
|
||||
int file_mode;
|
||||
int seq_mode;
|
||||
snd_seq_addr_t addr;
|
||||
void *private_data;
|
||||
int event_passing;
|
||||
};</PRE>
|
||||
The first three fields, <TT>app_index</TT>, <TT>file_mode</TT> and
|
||||
<TT>seq_mode</TT>
|
||||
are initialized by OSS sequencer. The <TT>app_index</TT> is the application
|
||||
index which is unique to each application opening OSS sequencer. The
|
||||
<TT>file_mode</TT>
|
||||
is bit-flags indicating the file operation mode. See
|
||||
<TT>seq_oss.h</TT>
|
||||
for its meaning. The <TT>seq_mode</TT> is sequencer operation mode. In
|
||||
the current version, only <TT>SND_OSSSEQ_MODE_SYNTH</TT> is used.
|
||||
<P>The next two fields, <TT>addr</TT> and <TT>private_data</TT>, must be
|
||||
filled by the synth driver at open callback. The <TT>addr</TT> contains
|
||||
the address of ALSA sequencer port which is assigned to this device. If
|
||||
the driver allocates memory for <TT>private_data</TT>, it must be released
|
||||
in close callback by itself.
|
||||
<P>The last field, <TT>event_passing</TT>, indicates how to translate note-on
|
||||
/ off events. In <TT>PROCESS_EVENTS</TT> mode, the note 255 is regarded
|
||||
as velocity change, and key pressure event is passed to the port. In <TT>PASS_EVENTS</TT>
|
||||
mode, all note on/off events are passed to the port without modified. <TT>PROCESS_KEYPRESS</TT>
|
||||
mode checks the note above 128 and regards it as key pressure event (mainly
|
||||
for Emu8000 driver).
|
||||
<H4>
|
||||
7.2.1. Open Callback</H4>
|
||||
The <TT>open</TT> is called at each time this device is opened by an application
|
||||
using OSS sequencer. This must not be NULL. Typically, the open callback
|
||||
does the following procedure:
|
||||
<OL>
|
||||
<LI>
|
||||
Allocate private data record.</LI>
|
||||
|
||||
<LI>
|
||||
Create an ALSA sequencer port.</LI>
|
||||
|
||||
<LI>
|
||||
Set the new port address on arg->addr.</LI>
|
||||
|
||||
<LI>
|
||||
Set the private data record pointer on arg->private_data.</LI>
|
||||
</OL>
|
||||
Note that the type bit-flags in port_info of this synth port must NOT contain
|
||||
<TT>TYPE_MIDI_GENERIC</TT>
|
||||
bit. Instead, <TT>TYPE_SPECIFIC</TT> should be used. Also, <TT>CAP_SUBSCRIPTION</TT>
|
||||
bit should NOT be included, too. This is necessary to tell it from other
|
||||
normal MIDI devices. If the open procedure succeeded, return zero. Otherwise,
|
||||
return -errno.
|
||||
<H4>
|
||||
7.2.2 Ioctl Callback</H4>
|
||||
The <TT>ioctl</TT> callback is called when the sequencer receives device-specific
|
||||
ioctls. The following two ioctls should be processed by this callback:
|
||||
<UL>
|
||||
<LI>
|
||||
<TT>IOCTL_SEQ_RESET_SAMPLES</TT></LI>
|
||||
|
||||
<BR>reset all samples on memory -- return 0
|
||||
<LI>
|
||||
<TT>IOCTL_SYNTH_MEMAVL</TT></LI>
|
||||
|
||||
<BR>return the available memory size
|
||||
<LI>
|
||||
<TT>FM_4OP_ENABLE</TT></LI>
|
||||
|
||||
<BR>can be ignored usually</UL>
|
||||
The other ioctls are processed inside the sequencer without passing to
|
||||
the lowlevel driver.
|
||||
<H4>
|
||||
7.2.3 Load_Patch Callback</H4>
|
||||
The <TT>load_patch</TT> callback is used for sample-downloading. This callback
|
||||
must read the data on user-space and transfer to each device. Return 0
|
||||
if succeeded, and -errno if failed. The format argument is the patch key
|
||||
in patch_info record. The buf is user-space pointer where patch_info record
|
||||
is stored. The offs can be ignored. The count is total data size of this
|
||||
sample data.
|
||||
<H4>
|
||||
7.2.4 Close Callback</H4>
|
||||
The <TT>close</TT> callback is called when this device is closed by the
|
||||
application. If any private data was allocated in open callback, it must
|
||||
be released in the close callback. The deletion of ALSA port should be
|
||||
done here, too. This callback must not be NULL.
|
||||
<H4>
|
||||
7.2.5 Reset Callback</H4>
|
||||
The <TT>reset</TT> callback is called when sequencer device is reset or
|
||||
closed by applications. The callback should turn off the sounds on the
|
||||
relevant port immediately, and initialize the status of the port. If this
|
||||
callback is undefined, OSS seq sends a <TT>HEARTBEAT</TT> event to the
|
||||
port.
|
||||
<H3>
|
||||
7.3 Events</H3>
|
||||
Most of the events are processed by sequencer and translated to the adequate
|
||||
ALSA sequencer events, so that each synth device can receive by input_event
|
||||
callback of ALSA sequencer port. The following ALSA events should be implemented
|
||||
by the driver:
|
||||
<BR>
|
||||
<TABLE BORDER WIDTH="75%" NOSAVE >
|
||||
<TR NOSAVE>
|
||||
<TD NOSAVE><B>ALSA event</B></TD>
|
||||
|
||||
<TD><B>Original OSS events</B></TD>
|
||||
</TR>
|
||||
|
||||
<TR>
|
||||
<TD>NOTEON</TD>
|
||||
|
||||
<TD>SEQ_NOTEON
|
||||
<BR>MIDI_NOTEON</TD>
|
||||
</TR>
|
||||
|
||||
<TR>
|
||||
<TD>NOTE</TD>
|
||||
|
||||
<TD>SEQ_NOTEOFF
|
||||
<BR>MIDI_NOTEOFF</TD>
|
||||
</TR>
|
||||
|
||||
<TR NOSAVE>
|
||||
<TD NOSAVE>KEYPRESS</TD>
|
||||
|
||||
<TD>MIDI_KEY_PRESSURE</TD>
|
||||
</TR>
|
||||
|
||||
<TR NOSAVE>
|
||||
<TD>CHANPRESS</TD>
|
||||
|
||||
<TD NOSAVE>SEQ_AFTERTOUCH
|
||||
<BR>MIDI_CHN_PRESSURE</TD>
|
||||
</TR>
|
||||
|
||||
<TR NOSAVE>
|
||||
<TD NOSAVE>PGMCHANGE</TD>
|
||||
|
||||
<TD NOSAVE>SEQ_PGMCHANGE
|
||||
<BR>MIDI_PGM_CHANGE</TD>
|
||||
</TR>
|
||||
|
||||
<TR>
|
||||
<TD>PITCHBEND</TD>
|
||||
|
||||
<TD>SEQ_CONTROLLER(CTRL_PITCH_BENDER)
|
||||
<BR>MIDI_PITCH_BEND</TD>
|
||||
</TR>
|
||||
|
||||
<TR>
|
||||
<TD>CONTROLLER</TD>
|
||||
|
||||
<TD>MIDI_CTL_CHANGE
|
||||
<BR>SEQ_BALANCE (with CTL_PAN)</TD>
|
||||
</TR>
|
||||
|
||||
<TR>
|
||||
<TD>CONTROL14</TD>
|
||||
|
||||
<TD>SEQ_CONTROLLER</TD>
|
||||
</TR>
|
||||
|
||||
<TR>
|
||||
<TD>REGPARAM</TD>
|
||||
|
||||
<TD>SEQ_CONTROLLER(CTRL_PITCH_BENDER_RANGE)</TD>
|
||||
</TR>
|
||||
|
||||
<TR>
|
||||
<TD>SYSEX</TD>
|
||||
|
||||
<TD>SEQ_SYSEX</TD>
|
||||
</TR>
|
||||
</TABLE>
|
||||
|
||||
<P>The most of these behavior can be realized by MIDI emulation driver
|
||||
included in the Emu8000 lowlevel driver. In the future release, this module
|
||||
will be independent.
|
||||
<P>Some OSS events (<TT>SEQ_PRIVATE</TT> and <TT>SEQ_VOLUME</TT> events) are passed as event
|
||||
type SND_SEQ_OSS_PRIVATE. The OSS sequencer passes these event 8 byte
|
||||
packets without any modification. The lowlevel driver should process these
|
||||
events appropriately.
|
||||
<H2>
|
||||
8. Interface to MIDI Device</H2>
|
||||
Since the OSS emulation probes the creation and deletion of ALSA MIDI sequencer
|
||||
ports automatically by receiving announcement from ALSA sequencer, the
|
||||
MIDI devices don't need to be registered explicitly like synth devices.
|
||||
However, the MIDI port_info registered to ALSA sequencer must include a group
|
||||
name <TT>SND_SEQ_GROUP_DEVICE</TT> and a capability-bit <TT>CAP_READ</TT> or
|
||||
<TT>CAP_WRITE</TT>. Also, subscription capabilities, <TT>CAP_SUBS_READ</TT> or <TT>CAP_SUBS_WRITE</TT>,
|
||||
must be defined, too. If these conditions are not satisfied, the port is not
|
||||
registered as OSS sequencer MIDI device.
|
||||
<P>The events via MIDI devices are parsed in OSS sequencer and converted
|
||||
to the corresponding ALSA sequencer events. The input from MIDI sequencer
|
||||
is also converted to MIDI byte events by OSS sequencer. This works just
|
||||
a reverse way of seq_midi module.
|
||||
<H2>
|
||||
9. Known Problems / TODO's</H2>
|
||||
|
||||
<UL>
|
||||
<LI>
|
||||
Patch loading via ALSA instrument layer is not implemented yet.</LI>
|
||||
</UL>
|
||||
|
||||
</BODY>
|
||||
</HTML>
|
||||
|
|
@ -1,8 +1,8 @@
|
|||
=============================================
|
||||
Sound Blaster Audigy mixer / default DSP code
|
||||
=============================================
|
||||
|
||||
Sound Blaster Audigy mixer / default DSP code
|
||||
===========================================
|
||||
|
||||
This is based on SB-Live-mixer.txt.
|
||||
This is based on sb-live-mixer.rst.
|
||||
|
||||
The EMU10K2 chips have a DSP part which can be programmed to support
|
||||
various ways of sample processing, which is described here.
|
||||
|
|
@ -13,8 +13,8 @@ The ALSA driver programs this portion of chip by default code
|
|||
(can be altered later) which offers the following functionality:
|
||||
|
||||
|
||||
1) Digital mixer controls
|
||||
-------------------------
|
||||
Digital mixer controls
|
||||
======================
|
||||
|
||||
These controls are built using the DSP instructions. They offer extended
|
||||
functionality. Only the default build-in code in the ALSA driver is described
|
||||
|
|
@ -26,320 +26,343 @@ is mentioned in multiple controls, the signal is accumulated and can be wrapped
|
|||
|
||||
Explanation of used abbreviations:
|
||||
|
||||
DAC - digital to analog converter
|
||||
ADC - analog to digital converter
|
||||
I2S - one-way three wire serial bus for digital sound by Philips Semiconductors
|
||||
(this standard is used for connecting standalone DAC and ADC converters)
|
||||
LFE - low frequency effects (subwoofer signal)
|
||||
AC97 - a chip containing an analog mixer, DAC and ADC converters
|
||||
IEC958 - S/PDIF
|
||||
FX-bus - the EMU10K2 chip has an effect bus containing 64 accumulators.
|
||||
Each of the synthesizer voices can feed its output to these accumulators
|
||||
and the DSP microcontroller can operate with the resulting sum.
|
||||
DAC
|
||||
digital to analog converter
|
||||
ADC
|
||||
analog to digital converter
|
||||
I2S
|
||||
one-way three wire serial bus for digital sound by Philips Semiconductors
|
||||
(this standard is used for connecting standalone DAC and ADC converters)
|
||||
LFE
|
||||
low frequency effects (subwoofer signal)
|
||||
AC97
|
||||
a chip containing an analog mixer, DAC and ADC converters
|
||||
IEC958
|
||||
S/PDIF
|
||||
FX-bus
|
||||
the EMU10K2 chip has an effect bus containing 64 accumulators.
|
||||
Each of the synthesizer voices can feed its output to these accumulators
|
||||
and the DSP microcontroller can operate with the resulting sum.
|
||||
|
||||
name='PCM Front Playback Volume',index=0
|
||||
|
||||
----------------------------------------
|
||||
This control is used to attenuate samples for left and right front PCM FX-bus
|
||||
accumulators. ALSA uses accumulators 8 and 9 for left and right front PCM
|
||||
samples for 5.1 playback. The result samples are forwarded to the front DAC PCM
|
||||
slots of the Philips DAC.
|
||||
|
||||
name='PCM Surround Playback Volume',index=0
|
||||
|
||||
-------------------------------------------
|
||||
This control is used to attenuate samples for left and right surround PCM FX-bus
|
||||
accumulators. ALSA uses accumulators 2 and 3 for left and right surround PCM
|
||||
samples for 5.1 playback. The result samples are forwarded to the surround DAC PCM
|
||||
slots of the Philips DAC.
|
||||
|
||||
name='PCM Center Playback Volume',index=0
|
||||
|
||||
-----------------------------------------
|
||||
This control is used to attenuate samples for center PCM FX-bus accumulator.
|
||||
ALSA uses accumulator 6 for center PCM sample for 5.1 playback. The result sample
|
||||
is forwarded to the center DAC PCM slot of the Philips DAC.
|
||||
|
||||
name='PCM LFE Playback Volume',index=0
|
||||
|
||||
--------------------------------------
|
||||
This control is used to attenuate sample for LFE PCM FX-bus accumulator.
|
||||
ALSA uses accumulator 7 for LFE PCM sample for 5.1 playback. The result sample
|
||||
is forwarded to the LFE DAC PCM slot of the Philips DAC.
|
||||
|
||||
name='PCM Playback Volume',index=0
|
||||
|
||||
----------------------------------
|
||||
This control is used to attenuate samples for left and right PCM FX-bus
|
||||
accumulators. ALSA uses accumulators 0 and 1 for left and right PCM samples for
|
||||
stereo playback. The result samples are forwarded to the front DAC PCM slots
|
||||
of the Philips DAC.
|
||||
|
||||
name='PCM Capture Volume',index=0
|
||||
|
||||
---------------------------------
|
||||
This control is used to attenuate samples for left and right PCM FX-bus
|
||||
accumulator. ALSA uses accumulators 0 and 1 for left and right PCM.
|
||||
The result is forwarded to the ADC capture FIFO (thus to the standard capture
|
||||
PCM device).
|
||||
|
||||
name='Music Playback Volume',index=0
|
||||
|
||||
------------------------------------
|
||||
This control is used to attenuate samples for left and right MIDI FX-bus
|
||||
accumulators. ALSA uses accumulators 4 and 5 for left and right MIDI samples.
|
||||
The result samples are forwarded to the front DAC PCM slots of the AC97 codec.
|
||||
|
||||
name='Music Capture Volume',index=0
|
||||
|
||||
-----------------------------------
|
||||
These controls are used to attenuate samples for left and right MIDI FX-bus
|
||||
accumulator. ALSA uses accumulators 4 and 5 for left and right PCM.
|
||||
The result is forwarded to the ADC capture FIFO (thus to the standard capture
|
||||
PCM device).
|
||||
|
||||
name='Mic Playback Volume',index=0
|
||||
|
||||
----------------------------------
|
||||
This control is used to attenuate samples for left and right Mic input.
|
||||
For Mic input is used AC97 codec. The result samples are forwarded to
|
||||
the front DAC PCM slots of the Philips DAC. Samples are forwarded to Mic
|
||||
capture FIFO (device 1 - 16bit/8KHz mono) too without volume control.
|
||||
|
||||
name='Mic Capture Volume',index=0
|
||||
|
||||
---------------------------------
|
||||
This control is used to attenuate samples for left and right Mic input.
|
||||
The result is forwarded to the ADC capture FIFO (thus to the standard capture
|
||||
PCM device).
|
||||
|
||||
name='Audigy CD Playback Volume',index=0
|
||||
|
||||
----------------------------------------
|
||||
This control is used to attenuate samples from left and right IEC958 TTL
|
||||
digital inputs (usually used by a CDROM drive). The result samples are
|
||||
forwarded to the front DAC PCM slots of the Philips DAC.
|
||||
|
||||
name='Audigy CD Capture Volume',index=0
|
||||
|
||||
---------------------------------------
|
||||
This control is used to attenuate samples from left and right IEC958 TTL
|
||||
digital inputs (usually used by a CDROM drive). The result samples are
|
||||
forwarded to the ADC capture FIFO (thus to the standard capture PCM device).
|
||||
|
||||
name='IEC958 Optical Playback Volume',index=0
|
||||
|
||||
---------------------------------------------
|
||||
This control is used to attenuate samples from left and right IEC958 optical
|
||||
digital input. The result samples are forwarded to the front DAC PCM slots
|
||||
of the Philips DAC.
|
||||
|
||||
name='IEC958 Optical Capture Volume',index=0
|
||||
|
||||
--------------------------------------------
|
||||
This control is used to attenuate samples from left and right IEC958 optical
|
||||
digital inputs. The result samples are forwarded to the ADC capture FIFO
|
||||
(thus to the standard capture PCM device).
|
||||
|
||||
name='Line2 Playback Volume',index=0
|
||||
|
||||
------------------------------------
|
||||
This control is used to attenuate samples from left and right I2S ADC
|
||||
inputs (on the AudigyDrive). The result samples are forwarded to the front
|
||||
DAC PCM slots of the Philips DAC.
|
||||
|
||||
name='Line2 Capture Volume',index=1
|
||||
|
||||
-----------------------------------
|
||||
This control is used to attenuate samples from left and right I2S ADC
|
||||
inputs (on the AudigyDrive). The result samples are forwarded to the ADC
|
||||
capture FIFO (thus to the standard capture PCM device).
|
||||
|
||||
name='Analog Mix Playback Volume',index=0
|
||||
|
||||
-----------------------------------------
|
||||
This control is used to attenuate samples from left and right I2S ADC
|
||||
inputs from Philips ADC. The result samples are forwarded to the front
|
||||
DAC PCM slots of the Philips DAC. This contains mix from analog sources
|
||||
like CD, Line In, Aux, ....
|
||||
|
||||
name='Analog Mix Capture Volume',index=1
|
||||
|
||||
----------------------------------------
|
||||
This control is used to attenuate samples from left and right I2S ADC
|
||||
inputs Philips ADC. The result samples are forwarded to the ADC
|
||||
capture FIFO (thus to the standard capture PCM device).
|
||||
|
||||
name='Aux2 Playback Volume',index=0
|
||||
|
||||
-----------------------------------
|
||||
This control is used to attenuate samples from left and right I2S ADC
|
||||
inputs (on the AudigyDrive). The result samples are forwarded to the front
|
||||
DAC PCM slots of the Philips DAC.
|
||||
|
||||
name='Aux2 Capture Volume',index=1
|
||||
|
||||
----------------------------------
|
||||
This control is used to attenuate samples from left and right I2S ADC
|
||||
inputs (on the AudigyDrive). The result samples are forwarded to the ADC
|
||||
capture FIFO (thus to the standard capture PCM device).
|
||||
|
||||
name='Front Playback Volume',index=0
|
||||
|
||||
------------------------------------
|
||||
All stereo signals are mixed together and mirrored to surround, center and LFE.
|
||||
This control is used to attenuate samples for left and right front speakers of
|
||||
this mix.
|
||||
|
||||
name='Surround Playback Volume',index=0
|
||||
|
||||
---------------------------------------
|
||||
All stereo signals are mixed together and mirrored to surround, center and LFE.
|
||||
This control is used to attenuate samples for left and right surround speakers of
|
||||
this mix.
|
||||
|
||||
name='Center Playback Volume',index=0
|
||||
|
||||
-------------------------------------
|
||||
All stereo signals are mixed together and mirrored to surround, center and LFE.
|
||||
This control is used to attenuate sample for center speaker of this mix.
|
||||
|
||||
name='LFE Playback Volume',index=0
|
||||
|
||||
----------------------------------
|
||||
All stereo signals are mixed together and mirrored to surround, center and LFE.
|
||||
This control is used to attenuate sample for LFE speaker of this mix.
|
||||
|
||||
name='Tone Control - Switch',index=0
|
||||
|
||||
------------------------------------
|
||||
This control turns the tone control on or off. The samples for front, rear
|
||||
and center / LFE outputs are affected.
|
||||
|
||||
name='Tone Control - Bass',index=0
|
||||
|
||||
----------------------------------
|
||||
This control sets the bass intensity. There is no neutral value!!
|
||||
When the tone control code is activated, the samples are always modified.
|
||||
The closest value to pure signal is 20.
|
||||
|
||||
name='Tone Control - Treble',index=0
|
||||
|
||||
------------------------------------
|
||||
This control sets the treble intensity. There is no neutral value!!
|
||||
When the tone control code is activated, the samples are always modified.
|
||||
The closest value to pure signal is 20.
|
||||
|
||||
name='Master Playback Volume',index=0
|
||||
|
||||
-------------------------------------
|
||||
This control is used to attenuate samples for front, surround, center and
|
||||
LFE outputs.
|
||||
|
||||
name='IEC958 Optical Raw Playback Switch',index=0
|
||||
|
||||
-------------------------------------------------
|
||||
If this switch is on, then the samples for the IEC958 (S/PDIF) digital
|
||||
output are taken only from the raw FX8010 PCM, otherwise standard front
|
||||
PCM samples are taken.
|
||||
|
||||
|
||||
2) PCM stream related controls
|
||||
------------------------------
|
||||
PCM stream related controls
|
||||
===========================
|
||||
|
||||
name='EMU10K1 PCM Volume',index 0-31
|
||||
|
||||
------------------------------------
|
||||
Channel volume attenuation in range 0-0xffff. The maximum value (no
|
||||
attenuation) is default. The channel mapping for three values is
|
||||
as follows:
|
||||
|
||||
0 - mono, default 0xffff (no attenuation)
|
||||
1 - left, default 0xffff (no attenuation)
|
||||
2 - right, default 0xffff (no attenuation)
|
||||
* 0 - mono, default 0xffff (no attenuation)
|
||||
* 1 - left, default 0xffff (no attenuation)
|
||||
* 2 - right, default 0xffff (no attenuation)
|
||||
|
||||
name='EMU10K1 PCM Send Routing',index 0-31
|
||||
|
||||
------------------------------------------
|
||||
This control specifies the destination - FX-bus accumulators. There 24
|
||||
values with this mapping:
|
||||
|
||||
0 - mono, A destination (FX-bus 0-63), default 0
|
||||
1 - mono, B destination (FX-bus 0-63), default 1
|
||||
2 - mono, C destination (FX-bus 0-63), default 2
|
||||
3 - mono, D destination (FX-bus 0-63), default 3
|
||||
4 - mono, E destination (FX-bus 0-63), default 0
|
||||
5 - mono, F destination (FX-bus 0-63), default 0
|
||||
6 - mono, G destination (FX-bus 0-63), default 0
|
||||
7 - mono, H destination (FX-bus 0-63), default 0
|
||||
8 - left, A destination (FX-bus 0-63), default 0
|
||||
9 - left, B destination (FX-bus 0-63), default 1
|
||||
10 - left, C destination (FX-bus 0-63), default 2
|
||||
11 - left, D destination (FX-bus 0-63), default 3
|
||||
12 - left, E destination (FX-bus 0-63), default 0
|
||||
13 - left, F destination (FX-bus 0-63), default 0
|
||||
14 - left, G destination (FX-bus 0-63), default 0
|
||||
15 - left, H destination (FX-bus 0-63), default 0
|
||||
16 - right, A destination (FX-bus 0-63), default 0
|
||||
17 - right, B destination (FX-bus 0-63), default 1
|
||||
18 - right, C destination (FX-bus 0-63), default 2
|
||||
19 - right, D destination (FX-bus 0-63), default 3
|
||||
20 - right, E destination (FX-bus 0-63), default 0
|
||||
21 - right, F destination (FX-bus 0-63), default 0
|
||||
22 - right, G destination (FX-bus 0-63), default 0
|
||||
23 - right, H destination (FX-bus 0-63), default 0
|
||||
* 0 - mono, A destination (FX-bus 0-63), default 0
|
||||
* 1 - mono, B destination (FX-bus 0-63), default 1
|
||||
* 2 - mono, C destination (FX-bus 0-63), default 2
|
||||
* 3 - mono, D destination (FX-bus 0-63), default 3
|
||||
* 4 - mono, E destination (FX-bus 0-63), default 0
|
||||
* 5 - mono, F destination (FX-bus 0-63), default 0
|
||||
* 6 - mono, G destination (FX-bus 0-63), default 0
|
||||
* 7 - mono, H destination (FX-bus 0-63), default 0
|
||||
* 8 - left, A destination (FX-bus 0-63), default 0
|
||||
* 9 - left, B destination (FX-bus 0-63), default 1
|
||||
* 10 - left, C destination (FX-bus 0-63), default 2
|
||||
* 11 - left, D destination (FX-bus 0-63), default 3
|
||||
* 12 - left, E destination (FX-bus 0-63), default 0
|
||||
* 13 - left, F destination (FX-bus 0-63), default 0
|
||||
* 14 - left, G destination (FX-bus 0-63), default 0
|
||||
* 15 - left, H destination (FX-bus 0-63), default 0
|
||||
* 16 - right, A destination (FX-bus 0-63), default 0
|
||||
* 17 - right, B destination (FX-bus 0-63), default 1
|
||||
* 18 - right, C destination (FX-bus 0-63), default 2
|
||||
* 19 - right, D destination (FX-bus 0-63), default 3
|
||||
* 20 - right, E destination (FX-bus 0-63), default 0
|
||||
* 21 - right, F destination (FX-bus 0-63), default 0
|
||||
* 22 - right, G destination (FX-bus 0-63), default 0
|
||||
* 23 - right, H destination (FX-bus 0-63), default 0
|
||||
|
||||
Don't forget that it's illegal to assign a channel to the same FX-bus accumulator
|
||||
more than once (it means 0=0 && 1=0 is an invalid combination).
|
||||
|
||||
name='EMU10K1 PCM Send Volume',index 0-31
|
||||
|
||||
-----------------------------------------
|
||||
It specifies the attenuation (amount) for given destination in range 0-255.
|
||||
The channel mapping is following:
|
||||
|
||||
0 - mono, A destination attn, default 255 (no attenuation)
|
||||
1 - mono, B destination attn, default 255 (no attenuation)
|
||||
2 - mono, C destination attn, default 0 (mute)
|
||||
3 - mono, D destination attn, default 0 (mute)
|
||||
4 - mono, E destination attn, default 0 (mute)
|
||||
5 - mono, F destination attn, default 0 (mute)
|
||||
6 - mono, G destination attn, default 0 (mute)
|
||||
7 - mono, H destination attn, default 0 (mute)
|
||||
8 - left, A destination attn, default 255 (no attenuation)
|
||||
9 - left, B destination attn, default 0 (mute)
|
||||
10 - left, C destination attn, default 0 (mute)
|
||||
11 - left, D destination attn, default 0 (mute)
|
||||
12 - left, E destination attn, default 0 (mute)
|
||||
13 - left, F destination attn, default 0 (mute)
|
||||
14 - left, G destination attn, default 0 (mute)
|
||||
15 - left, H destination attn, default 0 (mute)
|
||||
16 - right, A destination attn, default 0 (mute)
|
||||
17 - right, B destination attn, default 255 (no attenuation)
|
||||
18 - right, C destination attn, default 0 (mute)
|
||||
19 - right, D destination attn, default 0 (mute)
|
||||
20 - right, E destination attn, default 0 (mute)
|
||||
21 - right, F destination attn, default 0 (mute)
|
||||
22 - right, G destination attn, default 0 (mute)
|
||||
23 - right, H destination attn, default 0 (mute)
|
||||
* 0 - mono, A destination attn, default 255 (no attenuation)
|
||||
* 1 - mono, B destination attn, default 255 (no attenuation)
|
||||
* 2 - mono, C destination attn, default 0 (mute)
|
||||
* 3 - mono, D destination attn, default 0 (mute)
|
||||
* 4 - mono, E destination attn, default 0 (mute)
|
||||
* 5 - mono, F destination attn, default 0 (mute)
|
||||
* 6 - mono, G destination attn, default 0 (mute)
|
||||
* 7 - mono, H destination attn, default 0 (mute)
|
||||
* 8 - left, A destination attn, default 255 (no attenuation)
|
||||
* 9 - left, B destination attn, default 0 (mute)
|
||||
* 10 - left, C destination attn, default 0 (mute)
|
||||
* 11 - left, D destination attn, default 0 (mute)
|
||||
* 12 - left, E destination attn, default 0 (mute)
|
||||
* 13 - left, F destination attn, default 0 (mute)
|
||||
* 14 - left, G destination attn, default 0 (mute)
|
||||
* 15 - left, H destination attn, default 0 (mute)
|
||||
* 16 - right, A destination attn, default 0 (mute)
|
||||
* 17 - right, B destination attn, default 255 (no attenuation)
|
||||
* 18 - right, C destination attn, default 0 (mute)
|
||||
* 19 - right, D destination attn, default 0 (mute)
|
||||
* 20 - right, E destination attn, default 0 (mute)
|
||||
* 21 - right, F destination attn, default 0 (mute)
|
||||
* 22 - right, G destination attn, default 0 (mute)
|
||||
* 23 - right, H destination attn, default 0 (mute)
|
||||
|
||||
|
||||
|
||||
4) MANUALS/PATENTS:
|
||||
-------------------
|
||||
MANUALS/PATENTS
|
||||
===============
|
||||
|
||||
ftp://opensource.creative.com/pub/doc
|
||||
-------------------------------------
|
||||
|
||||
Files:
|
||||
LM4545.pdf AC97 Codec
|
||||
LM4545.pdf
|
||||
AC97 Codec
|
||||
|
||||
m2049.pdf The EMU10K1 Digital Audio Processor
|
||||
m2049.pdf
|
||||
The EMU10K1 Digital Audio Processor
|
||||
|
||||
hog63.ps FX8010 - A DSP Chip Architecture for Audio Effects
|
||||
hog63.ps
|
||||
FX8010 - A DSP Chip Architecture for Audio Effects
|
||||
|
||||
|
||||
WIPO Patents
|
||||
------------
|
||||
Patent numbers:
|
||||
WO 9901813 (A1) Audio Effects Processor with multiple asynchronous (Jan. 14, 1999)
|
||||
streams
|
||||
|
||||
WO 9901814 (A1) Processor with Instruction Set for Audio Effects (Jan. 14, 1999)
|
||||
WO 9901813 (A1)
|
||||
Audio Effects Processor with multiple asynchronous streams
|
||||
(Jan. 14, 1999)
|
||||
|
||||
WO 9901953 (A1) Audio Effects Processor having Decoupled Instruction
|
||||
Execution and Audio Data Sequencing (Jan. 14, 1999)
|
||||
WO 9901814 (A1)
|
||||
Processor with Instruction Set for Audio Effects (Jan. 14, 1999)
|
||||
|
||||
WO 9901953 (A1)
|
||||
Audio Effects Processor having Decoupled Instruction
|
||||
Execution and Audio Data Sequencing (Jan. 14, 1999)
|
||||
|
||||
|
||||
US Patents (http://www.uspto.gov/)
|
||||
----------------------------------
|
||||
|
||||
US 5925841 Digital Sampling Instrument employing cache memory (Jul. 20, 1999)
|
||||
US 5925841
|
||||
Digital Sampling Instrument employing cache memory (Jul. 20, 1999)
|
||||
|
||||
US 5928342 Audio Effects Processor integrated on a single chip (Jul. 27, 1999)
|
||||
with a multiport memory onto which multiple asynchronous
|
||||
digital sound samples can be concurrently loaded
|
||||
US 5928342
|
||||
Audio Effects Processor integrated on a single chip
|
||||
with a multiport memory onto which multiple asynchronous
|
||||
digital sound samples can be concurrently loaded
|
||||
(Jul. 27, 1999)
|
||||
|
||||
US 5930158 Processor with Instruction Set for Audio Effects (Jul. 27, 1999)
|
||||
US 5930158
|
||||
Processor with Instruction Set for Audio Effects (Jul. 27, 1999)
|
||||
|
||||
US 6032235 Memory initialization circuit (Tram) (Feb. 29, 2000)
|
||||
US 6032235
|
||||
Memory initialization circuit (Tram) (Feb. 29, 2000)
|
||||
|
||||
US 6138207 Interpolation looping of audio samples in cache connected to (Oct. 24, 2000)
|
||||
system bus with prioritization and modification of bus transfers
|
||||
in accordance with loop ends and minimum block sizes
|
||||
US 6138207
|
||||
Interpolation looping of audio samples in cache connected to
|
||||
system bus with prioritization and modification of bus transfers
|
||||
in accordance with loop ends and minimum block sizes
|
||||
(Oct. 24, 2000)
|
||||
|
||||
US 6151670 Method for conserving memory storage using a (Nov. 21, 2000)
|
||||
pool of short term memory registers
|
||||
US 6151670
|
||||
Method for conserving memory storage using a
|
||||
pool of short term memory registers
|
||||
(Nov. 21, 2000)
|
||||
|
||||
US 6195715 Interrupt control for multiple programs communicating with (Feb. 27, 2001)
|
||||
a common interrupt by associating programs to GP registers,
|
||||
defining interrupt register, polling GP registers, and invoking
|
||||
callback routine associated with defined interrupt register
|
||||
US 6195715
|
||||
Interrupt control for multiple programs communicating with
|
||||
a common interrupt by associating programs to GP registers,
|
||||
defining interrupt register, polling GP registers, and invoking
|
||||
callback routine associated with defined interrupt register
|
||||
(Feb. 27, 2001)
|
||||
|
|
@ -1,32 +1,41 @@
|
|||
Guide to using M-Audio Audiophile USB with ALSA and Jack v1.5
|
||||
========================================================
|
||||
========================================================
|
||||
Guide to using M-Audio Audiophile USB with ALSA and Jack
|
||||
========================================================
|
||||
|
||||
Thibault Le Meur <Thibault.LeMeur@supelec.fr>
|
||||
v1.5
|
||||
|
||||
Thibault Le Meur <Thibault.LeMeur@supelec.fr>
|
||||
|
||||
This document is a guide to using the M-Audio Audiophile USB (tm) device with
|
||||
ALSA and JACK.
|
||||
|
||||
History
|
||||
=======
|
||||
|
||||
* v1.4 - Thibault Le Meur (2007-07-11)
|
||||
- Added Low Endianness nature of 16bits-modes
|
||||
found by Hakan Lennestal <Hakan.Lennestal@brfsodrahamn.se>
|
||||
- Modifying document structure
|
||||
|
||||
- Added Low Endianness nature of 16bits-modes
|
||||
found by Hakan Lennestal <Hakan.Lennestal@brfsodrahamn.se>
|
||||
- Modifying document structure
|
||||
|
||||
* v1.5 - Thibault Le Meur (2007-07-12)
|
||||
- Added AC3/DTS passthru info
|
||||
- Added AC3/DTS passthru info
|
||||
|
||||
|
||||
1 - Audiophile USB Specs and correct usage
|
||||
==========================================
|
||||
Audiophile USB Specs and correct usage
|
||||
======================================
|
||||
|
||||
This part is a reminder of important facts about the functions and limitations
|
||||
of the device.
|
||||
|
||||
The device has 4 audio interfaces, and 2 MIDI ports:
|
||||
|
||||
* Analog Stereo Input (Ai)
|
||||
|
||||
- This port supports 2 pairs of line-level audio inputs (1/4" TS and RCA)
|
||||
- When the 1/4" TS (jack) connectors are connected, the RCA connectors
|
||||
are disabled
|
||||
|
||||
* Analog Stereo Output (Ao)
|
||||
* Digital Stereo Input (Di)
|
||||
* Digital Stereo Output (Do)
|
||||
|
|
@ -34,56 +43,69 @@ The device has 4 audio interfaces, and 2 MIDI ports:
|
|||
* Midi Out (Mo)
|
||||
|
||||
The internal DAC/ADC has the following characteristics:
|
||||
|
||||
* sample depth of 16 or 24 bits
|
||||
* sample rate from 8kHz to 96kHz
|
||||
* Two interfaces can't use different sample depths at the same time.
|
||||
|
||||
Moreover, the Audiophile USB documentation gives the following Warning:
|
||||
"Please exit any audio application running before switching between bit depths"
|
||||
Please exit any audio application running before switching between bit depths
|
||||
|
||||
Due to the USB 1.1 bandwidth limitation, a limited number of interfaces can be
|
||||
activated at the same time depending on the audio mode selected:
|
||||
|
||||
* 16-bit/48kHz ==> 4 channels in + 4 channels out
|
||||
|
||||
- Ai+Ao+Di+Do
|
||||
|
||||
* 24-bit/48kHz ==> 4 channels in + 2 channels out,
|
||||
or 2 channels in + 4 channels out
|
||||
or 2 channels in + 4 channels out
|
||||
|
||||
- Ai+Ao+Do or Ai+Di+Ao or Ai+Di+Do or Di+Ao+Do
|
||||
|
||||
* 24-bit/96kHz ==> 2 channels in _or_ 2 channels out (half duplex only)
|
||||
|
||||
- Ai or Ao or Di or Do
|
||||
|
||||
Important facts about the Digital interface:
|
||||
--------------------------------------------
|
||||
|
||||
* The Do port additionally supports surround-encoded AC-3 and DTS passthrough,
|
||||
though I haven't tested it under Linux
|
||||
though I haven't tested it under Linux
|
||||
|
||||
- Note that in this setup only the Do interface can be enabled
|
||||
|
||||
* Apart from recording an audio digital stream, enabling the Di port is a way
|
||||
to synchronize the device to an external sample clock
|
||||
to synchronize the device to an external sample clock
|
||||
|
||||
- As a consequence, the Di port must be enable only if an active Digital
|
||||
source is connected
|
||||
source is connected
|
||||
- Enabling Di when no digital source is connected can result in a
|
||||
synchronization error (for instance sound played at an odd sample rate)
|
||||
synchronization error (for instance sound played at an odd sample rate)
|
||||
|
||||
|
||||
2 - Audiophile USB MIDI support in ALSA
|
||||
=======================================
|
||||
Audiophile USB MIDI support in ALSA
|
||||
===================================
|
||||
|
||||
The Audiophile USB MIDI ports will be automatically supported once the
|
||||
following modules have been loaded:
|
||||
|
||||
* snd-usb-audio
|
||||
* snd-seq-midi
|
||||
|
||||
No additional setting is required.
|
||||
|
||||
|
||||
3 - Audiophile USB Audio support in ALSA
|
||||
========================================
|
||||
Audiophile USB Audio support in ALSA
|
||||
====================================
|
||||
|
||||
Audio functions of the Audiophile USB device are handled by the snd-usb-audio
|
||||
module. This module can work in a default mode (without any device-specific
|
||||
parameter), or in an "advanced" mode with the device-specific parameter called
|
||||
"device_setup".
|
||||
``device_setup``.
|
||||
|
||||
3.1 - Default Alsa driver mode
|
||||
------------------------------
|
||||
Default Alsa driver mode
|
||||
------------------------
|
||||
|
||||
The default behavior of the snd-usb-audio driver is to list the device
|
||||
capabilities at startup and activate the required mode when required
|
||||
|
|
@ -101,6 +123,7 @@ Default Alsa driver mode can lead to device misconfigurations.
|
|||
Let's get back to the Default Alsa driver mode for now. In this case the
|
||||
Audiophile interfaces are mapped to alsa pcm devices in the following
|
||||
way (I suppose the device's index is 1):
|
||||
|
||||
* hw:1,0 is Ao in playback and Di in capture
|
||||
* hw:1,1 is Do in playback and Ai in capture
|
||||
* hw:1,2 is Do in AC3/DTS passthrough mode
|
||||
|
|
@ -115,20 +138,28 @@ This has been fixed in kernel 2.6.23 and above and now the hw:1,2 interface
|
|||
is reported to be big endian in this default driver mode.
|
||||
|
||||
Examples:
|
||||
* playing a S24_3BE encoded raw file to the Ao port
|
||||
|
||||
* playing a S24_3BE encoded raw file to the Ao port::
|
||||
|
||||
% aplay -D hw:1,0 -c2 -t raw -r48000 -fS24_3BE test.raw
|
||||
* recording a S24_3BE encoded raw file from the Ai port
|
||||
|
||||
* recording a S24_3BE encoded raw file from the Ai port::
|
||||
|
||||
% arecord -D hw:1,1 -c2 -t raw -r48000 -fS24_3BE test.raw
|
||||
* playing a S16_BE encoded raw file to the Do port
|
||||
|
||||
* playing a S16_BE encoded raw file to the Do port::
|
||||
|
||||
% aplay -D hw:1,1 -c2 -t raw -r48000 -fS16_BE test.raw
|
||||
* playing an ac3 sample file to the Do port
|
||||
|
||||
* playing an ac3 sample file to the Do port::
|
||||
|
||||
% aplay -D hw:1,2 --channels=6 ac3_S16_BE_encoded_file.raw
|
||||
|
||||
If you're happy with the default Alsa driver mode and don't experience any
|
||||
issue with this mode, then you can skip the following chapter.
|
||||
|
||||
3.2 - Advanced module setup
|
||||
---------------------------
|
||||
Advanced module setup
|
||||
---------------------
|
||||
|
||||
Due to the hardware constraints described above, the device initialization made
|
||||
by the Alsa driver in default mode may result in a corrupted state of the
|
||||
|
|
@ -137,34 +168,39 @@ from the Ai interface sounds distorted (as if boosted with an excessive high
|
|||
volume gain).
|
||||
|
||||
For people having this problem, the snd-usb-audio module has a new module
|
||||
parameter called "device_setup" (this parameter was introduced in kernel
|
||||
parameter called ``device_setup`` (this parameter was introduced in kernel
|
||||
release 2.6.17)
|
||||
|
||||
3.2.1 - Initializing the working mode of the Audiophile USB
|
||||
Initializing the working mode of the Audiophile USB
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
As far as the Audiophile USB device is concerned, this value let the user
|
||||
specify:
|
||||
|
||||
* the sample depth
|
||||
* the sample rate
|
||||
* whether the Di port is used or not
|
||||
|
||||
When initialized with "device_setup=0x00", the snd-usb-audio module has
|
||||
When initialized with ``device_setup=0x00``, the snd-usb-audio module has
|
||||
the same behaviour as when the parameter is omitted (see paragraph "Default
|
||||
Alsa driver mode" above)
|
||||
|
||||
Others modes are described in the following subsections.
|
||||
|
||||
3.2.1.1 - 16-bit modes
|
||||
16-bit modes
|
||||
~~~~~~~~~~~~
|
||||
|
||||
The two supported modes are:
|
||||
|
||||
* device_setup=0x01
|
||||
* ``device_setup=0x01``
|
||||
|
||||
- 16bits 48kHz mode with Di disabled
|
||||
- Ai,Ao,Do can be used at the same time
|
||||
- hw:1,0 is not available in capture mode
|
||||
- hw:1,2 is not available
|
||||
|
||||
* device_setup=0x11
|
||||
* ``device_setup=0x11``
|
||||
|
||||
- 16bits 48kHz mode with Di enabled
|
||||
- Ai,Ao,Di,Do can be used at the same time
|
||||
- hw:1,0 is available in capture mode
|
||||
|
|
@ -173,33 +209,43 @@ The two supported modes are:
|
|||
In this modes the device operates only at 16bits-modes. Before kernel 2.6.23,
|
||||
the devices where reported to be Big-Endian when in fact they were Little-Endian
|
||||
so that playing a file was a matter of using:
|
||||
::
|
||||
|
||||
% aplay -D hw:1,1 -c2 -t raw -r48000 -fS16_BE test_S16_LE.raw
|
||||
|
||||
where "test_S16_LE.raw" was in fact a little-endian sample file.
|
||||
|
||||
Thanks to Hakan Lennestal (who discovered the Little-Endiannes of the device in
|
||||
these modes) a fix has been committed (expected in kernel 2.6.23) and
|
||||
Alsa now reports Little-Endian interfaces. Thus playing a file now is as simple as
|
||||
using:
|
||||
::
|
||||
|
||||
% aplay -D hw:1,1 -c2 -t raw -r48000 -fS16_LE test_S16_LE.raw
|
||||
|
||||
3.2.1.2 - 24-bit modes
|
||||
|
||||
24-bit modes
|
||||
~~~~~~~~~~~~
|
||||
|
||||
The three supported modes are:
|
||||
|
||||
* device_setup=0x09
|
||||
* ``device_setup=0x09``
|
||||
|
||||
- 24bits 48kHz mode with Di disabled
|
||||
- Ai,Ao,Do can be used at the same time
|
||||
- hw:1,0 is not available in capture mode
|
||||
- hw:1,2 is not available
|
||||
|
||||
* device_setup=0x19
|
||||
* ``device_setup=0x19``
|
||||
|
||||
- 24bits 48kHz mode with Di enabled
|
||||
- 3 ports from {Ai,Ao,Di,Do} can be used at the same time
|
||||
- hw:1,0 is available in capture mode and an active digital source must be
|
||||
connected to Di
|
||||
- hw:1,2 is not available
|
||||
|
||||
* device_setup=0x0D or 0x10
|
||||
* ``device_setup=0x0D`` or ``0x10``
|
||||
|
||||
- 24bits 96kHz mode
|
||||
- Di is enabled by default for this mode but does not need to be connected
|
||||
to an active source
|
||||
|
|
@ -210,29 +256,35 @@ The three supported modes are:
|
|||
In these modes the device is only Big-Endian compliant (see "Default Alsa driver
|
||||
mode" above for an aplay command example)
|
||||
|
||||
3.2.1.3 - AC3 w/ DTS passthru mode
|
||||
AC3 w/ DTS passthru mode
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Thanks to Hakan Lennestal, I now have a report saying that this mode works.
|
||||
|
||||
* device_setup=0x03
|
||||
* ``device_setup=0x03``
|
||||
|
||||
- 16bits 48kHz mode with only the Do port enabled
|
||||
- AC3 with DTS passthru
|
||||
- Caution with this setup the Do port is mapped to the pcm device hw:1,0
|
||||
|
||||
The command line used to playback the AC3/DTS encoded .wav-files in this mode:
|
||||
::
|
||||
|
||||
% aplay -D hw:1,0 --channels=6 ac3_S16_LE_encoded_file.raw
|
||||
|
||||
3.2.2 - How to use the device_setup parameter
|
||||
----------------------------------------------
|
||||
How to use the ``device_setup`` parameter
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The parameter can be given:
|
||||
|
||||
* By manually probing the device (as root):
|
||||
* By manually probing the device (as root):::
|
||||
|
||||
# modprobe -r snd-usb-audio
|
||||
# modprobe snd-usb-audio index=1 device_setup=0x09
|
||||
|
||||
* Or while configuring the modules options in your modules configuration file
|
||||
(typically a .conf file in /etc/modprobe.d/ directory:
|
||||
(typically a .conf file in /etc/modprobe.d/ directory:::
|
||||
|
||||
alias snd-card-1 snd-usb-audio
|
||||
options snd-usb-audio index=1 device_setup=0x09
|
||||
|
||||
|
|
@ -250,26 +302,31 @@ CAUTION when initializing the device
|
|||
* If you've correctly initialized the device in a valid mode and then want to switch
|
||||
to another mode (possibly with another sample-depth), please use also the following
|
||||
procedure:
|
||||
|
||||
- first turn off the device
|
||||
- de-register the snd-usb-audio module (modprobe -r)
|
||||
- change the device_setup parameter by changing the device_setup
|
||||
option in /etc/modprobe.d/*.conf
|
||||
option in ``/etc/modprobe.d/*.conf``
|
||||
- turn on the device
|
||||
|
||||
* A workaround for this last issue has been applied to kernel 2.6.23, but it may not
|
||||
be enough to ensure the 'stability' of the device initialization.
|
||||
|
||||
3.2.3 - Technical details for hackers
|
||||
-------------------------------------
|
||||
Technical details for hackers
|
||||
-----------------------------
|
||||
|
||||
This section is for hackers, wanting to understand details about the device
|
||||
internals and how Alsa supports it.
|
||||
|
||||
3.2.3.1 - Audiophile USB's device_setup structure
|
||||
Audiophile USB's ``device_setup`` structure
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you want to understand the device_setup magic numbers for the Audiophile
|
||||
USB, you need some very basic understanding of binary computation. However,
|
||||
this is not required to use the parameter and you may skip this section.
|
||||
|
||||
The device_setup is one byte long and its structure is the following:
|
||||
::
|
||||
|
||||
+---+---+---+---+---+---+---+---+
|
||||
| b7| b6| b5| b4| b3| b2| b1| b0|
|
||||
|
|
@ -278,38 +335,55 @@ The device_setup is one byte long and its structure is the following:
|
|||
+---+---+---+---+---+---+---+---+
|
||||
|
||||
Where:
|
||||
* b0 is the "SET" bit
|
||||
|
||||
* b0 is the ``SET`` bit
|
||||
|
||||
- it MUST be set if device_setup is initialized
|
||||
* b1 is the "DTS" bit
|
||||
|
||||
* b1 is the ``DTS`` bit
|
||||
|
||||
- it is set only for Digital output with DTS/AC3
|
||||
- this setup is not tested
|
||||
|
||||
* b2 is the Rate selection flag
|
||||
- When set to "1" the rate range is 48.1-96kHz
|
||||
|
||||
- When set to ``1`` the rate range is 48.1-96kHz
|
||||
- Otherwise the sample rate range is 8-48kHz
|
||||
|
||||
* b3 is the bit depth selection flag
|
||||
- When set to "1" samples are 24bits long
|
||||
|
||||
- When set to ``1`` samples are 24bits long
|
||||
- Otherwise they are 16bits long
|
||||
- Note that b2 implies b3 as the 96kHz mode is only supported for 24 bits
|
||||
samples
|
||||
|
||||
* b4 is the Digital input flag
|
||||
- When set to "1" the device assumes that an active digital source is
|
||||
|
||||
- When set to ``1`` the device assumes that an active digital source is
|
||||
connected
|
||||
- You shouldn't enable Di if no source is seen on the port (this leads to
|
||||
synchronization issues)
|
||||
- b4 is implied by b2 (since only one port is enabled at a time no synch
|
||||
error can occur)
|
||||
* b5 to b7 are reserved for future uses, and must be set to "0"
|
||||
|
||||
* b5 to b7 are reserved for future uses, and must be set to ``0``
|
||||
|
||||
- might become Ao, Do, Ai, for b7, b6, b4 respectively
|
||||
|
||||
Caution:
|
||||
|
||||
* there is no check on the value you will give to device_setup
|
||||
|
||||
- for instance choosing 0x05 (16bits 96kHz) will fail back to 0x09 since
|
||||
b2 implies b3. But _there_will_be_no_warning_ in /var/log/messages
|
||||
|
||||
* Hardware constraints due to the USB bus limitation aren't checked
|
||||
|
||||
- choosing b2 will prepare all interfaces for 24bits/96kHz but you'll
|
||||
only be able to use one at the same time
|
||||
|
||||
3.2.3.2 - USB implementation details for this device
|
||||
USB implementation details for this device
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You may safely skip this section if you're not interested in driver
|
||||
hacking.
|
||||
|
|
@ -319,46 +393,72 @@ data I got by usb-snooping the windows and Linux drivers.
|
|||
|
||||
The M-Audio Audiophile USB has 7 USB Interfaces:
|
||||
a "USB interface":
|
||||
|
||||
* USB Interface nb.0
|
||||
* USB Interface nb.1
|
||||
|
||||
- Audio Control function
|
||||
|
||||
* USB Interface nb.2
|
||||
|
||||
- Analog Output
|
||||
|
||||
* USB Interface nb.3
|
||||
|
||||
- Digital Output
|
||||
|
||||
* USB Interface nb.4
|
||||
|
||||
- Analog Input
|
||||
|
||||
* USB Interface nb.5
|
||||
|
||||
- Digital Input
|
||||
|
||||
* USB Interface nb.6
|
||||
|
||||
- MIDI interface compliant with the MIDIMAN quirk
|
||||
|
||||
Each interface has 5 altsettings (AltSet 1,2,3,4,5) except:
|
||||
|
||||
* Interface 3 (Digital Out) has an extra Alset nb.6
|
||||
* Interface 5 (Digital In) does not have Alset nb.3 and 5
|
||||
|
||||
Here is a short description of the AltSettings capabilities:
|
||||
* AltSettings 1 corresponds to
|
||||
|
||||
* AltSettings 1 corresponds to
|
||||
|
||||
- 24-bit depth, 48.1-96kHz sample mode
|
||||
- Adaptive playback (Ao and Do), Synch capture (Ai), or Asynch capture (Di)
|
||||
* AltSettings 2 corresponds to
|
||||
|
||||
* AltSettings 2 corresponds to
|
||||
|
||||
- 24-bit depth, 8-48kHz sample mode
|
||||
- Asynch capture and playback (Ao,Ai,Do,Di)
|
||||
* AltSettings 3 corresponds to
|
||||
|
||||
* AltSettings 3 corresponds to
|
||||
|
||||
- 24-bit depth, 8-48kHz sample mode
|
||||
- Synch capture (Ai) and Adaptive playback (Ao,Do)
|
||||
* AltSettings 4 corresponds to
|
||||
|
||||
* AltSettings 4 corresponds to
|
||||
|
||||
- 16-bit depth, 8-48kHz sample mode
|
||||
- Asynch capture and playback (Ao,Ai,Do,Di)
|
||||
* AltSettings 5 corresponds to
|
||||
|
||||
* AltSettings 5 corresponds to
|
||||
|
||||
- 16-bit depth, 8-48kHz sample mode
|
||||
- Synch capture (Ai) and Adaptive playback (Ao,Do)
|
||||
* AltSettings 6 corresponds to
|
||||
|
||||
* AltSettings 6 corresponds to
|
||||
|
||||
- 16-bit depth, 8-48kHz sample mode
|
||||
- Synch playback (Do), audio format type III IEC1937_AC-3
|
||||
|
||||
In order to ensure a correct initialization of the device, the driver
|
||||
_must_know_ how the device will be used:
|
||||
*must* *know* how the device will be used:
|
||||
|
||||
* if DTS is chosen, only Interface 2 with AltSet nb.6 must be
|
||||
registered
|
||||
* if 96KHz only AltSets nb.1 of each interface must be selected
|
||||
|
|
@ -371,20 +471,21 @@ _must_know_ how the device will be used:
|
|||
|
||||
When device_setup is given as a parameter to the snd-usb-audio module, the
|
||||
parse_audio_endpoints function uses a quirk called
|
||||
"audiophile_skip_setting_quirk" in order to prevent AltSettings not
|
||||
``audiophile_skip_setting_quirk`` in order to prevent AltSettings not
|
||||
corresponding to device_setup from being registered in the driver.
|
||||
|
||||
4 - Audiophile USB and Jack support
|
||||
===================================
|
||||
Audiophile USB and Jack support
|
||||
===============================
|
||||
|
||||
This section deals with support of the Audiophile USB device in Jack.
|
||||
|
||||
There are 2 main potential issues when using Jackd with the device:
|
||||
|
||||
* support for Big-Endian devices in 24-bit modes
|
||||
* support for 4-in / 4-out channels
|
||||
|
||||
4.1 - Direct support in Jackd
|
||||
-----------------------------
|
||||
Direct support in Jackd
|
||||
-----------------------
|
||||
|
||||
Jack supports big endian devices only in recent versions (thanks to
|
||||
Andreas Steinmetz for his first big-endian patch). I can't remember
|
||||
|
|
@ -396,29 +497,35 @@ are now Little Endians ;-) ).
|
|||
|
||||
You can run jackd with the following command for playback with Ao and
|
||||
record with Ai:
|
||||
::
|
||||
|
||||
% jackd -R -dalsa -Phw:1,0 -r48000 -p128 -n2 -D -Chw:1,1
|
||||
|
||||
4.2 - Using Alsa plughw
|
||||
-----------------------
|
||||
Using Alsa plughw
|
||||
-----------------
|
||||
|
||||
If you don't have a recent Jackd installed, you can downgrade to using
|
||||
the Alsa "plug" converter.
|
||||
the Alsa ``plug`` converter.
|
||||
|
||||
For instance here is one way to run Jack with 2 playback channels on Ao and 2
|
||||
capture channels from Ai:
|
||||
::
|
||||
|
||||
% jackd -R -dalsa -dplughw:1 -r48000 -p256 -n2 -D -Cplughw:1,1
|
||||
|
||||
However you may see the following warning message:
|
||||
"You appear to be using the ALSA software "plug" layer, probably a result of
|
||||
using the "default" ALSA device. This is less efficient than it could be.
|
||||
Consider using a hardware device instead rather than using the plug layer."
|
||||
You appear to be using the ALSA software "plug" layer, probably a result of
|
||||
using the "default" ALSA device. This is less efficient than it could be.
|
||||
Consider using a hardware device instead rather than using the plug layer.
|
||||
|
||||
4.3 - Getting 2 input and/or output interfaces in Jack
|
||||
------------------------------------------------------
|
||||
Getting 2 input and/or output interfaces in Jack
|
||||
------------------------------------------------
|
||||
|
||||
As you can see, starting the Jack server this way will only enable 1 stereo
|
||||
input (Di or Ai) and 1 stereo output (Ao or Do).
|
||||
|
||||
This is due to the following restrictions:
|
||||
|
||||
* Jack can only open one capture device and one playback device at a time
|
||||
* The Audiophile USB is seen as 2 (or three) Alsa devices: hw:1,0, hw:1,1
|
||||
(and optionally hw:1,2)
|
||||
|
|
@ -432,6 +539,7 @@ It is related to another device (ice1712) but can be adapted to suit
|
|||
the Audiophile USB.
|
||||
|
||||
Enabling multiple Audiophile USB interfaces for Jackd will certainly require:
|
||||
|
||||
* Making sure your Jackd version has the MMAP_COMPLEX patch (see the ice1712 page)
|
||||
* (maybe) patching the alsa-lib/src/pcm/pcm_multi.c file (see the ice1712 page)
|
||||
* define a multi device (combination of hw:1,0 and hw:1,1) in your .asoundrc
|
||||
|
|
@ -1,18 +1,23 @@
|
|||
=================
|
||||
ALSA BT87x Driver
|
||||
=================
|
||||
|
||||
Intro
|
||||
=====
|
||||
|
||||
You might have noticed that the bt878 grabber cards have actually
|
||||
_two_ PCI functions:
|
||||
*two* PCI functions:
|
||||
::
|
||||
|
||||
$ lspci
|
||||
[ ... ]
|
||||
00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02)
|
||||
00:0a.1 Multimedia controller: Brooktree Corporation Bt878 (rev 02)
|
||||
[ ... ]
|
||||
$ lspci
|
||||
[ ... ]
|
||||
00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02)
|
||||
00:0a.1 Multimedia controller: Brooktree Corporation Bt878 (rev 02)
|
||||
[ ... ]
|
||||
|
||||
The first does video, it is backward compatible to the bt848. The second
|
||||
does audio. snd-bt87x is a driver for the second function. It's a sound
|
||||
driver which can be used for recording sound (and _only_ recording, no
|
||||
driver which can be used for recording sound (and *only* recording, no
|
||||
playback). As most TV cards come with a short cable which can be plugged
|
||||
into your sound card's line-in you probably don't need this driver if all
|
||||
you want to do is just watching TV...
|
||||
|
|
@ -30,9 +35,9 @@ The driver is now stable. However, it doesn't know about many TV cards,
|
|||
and it refuses to load for cards it doesn't know.
|
||||
|
||||
If the driver complains ("Unknown TV card found, the audio driver will
|
||||
not load"), you can specify the load_all=1 option to force the driver to
|
||||
not load"), you can specify the ``load_all=1`` option to force the driver to
|
||||
try to use the audio capture function of your card. If the frequency of
|
||||
recorded data is not right, try to specify the digital_rate option with
|
||||
recorded data is not right, try to specify the ``digital_rate`` option with
|
||||
other values than the default 32000 (often it's 44100 or 64000).
|
||||
|
||||
If you have an unknown card, please mail the ID and board name to
|
||||
|
|
@ -1,7 +1,8 @@
|
|||
Brief Notes on C-Media 8338/8738/8768/8770 Driver
|
||||
=================================================
|
||||
=================================================
|
||||
Brief Notes on C-Media 8338/8738/8768/8770 Driver
|
||||
=================================================
|
||||
|
||||
Takashi Iwai <tiwai@suse.de>
|
||||
Takashi Iwai <tiwai@suse.de>
|
||||
|
||||
|
||||
Front/Rear Multi-channel Playback
|
||||
|
|
@ -30,19 +31,20 @@ The rear output can be heard only when "Four Channel Mode" switch is
|
|||
disabled. Otherwise no signal will be routed to the rear speakers.
|
||||
As default it's turned on.
|
||||
|
||||
*** WARNING ***
|
||||
When "Four Channel Mode" switch is off, the output from rear speakers
|
||||
will be FULL VOLUME regardless of Master and PCM volumes.
|
||||
This might damage your audio equipment. Please disconnect speakers
|
||||
before your turn off this switch.
|
||||
*** WARNING ***
|
||||
.. WARNING::
|
||||
When "Four Channel Mode" switch is off, the output from rear speakers
|
||||
will be FULL VOLUME regardless of Master and PCM volumes [#]_.
|
||||
This might damage your audio equipment. Please disconnect speakers
|
||||
before your turn off this switch.
|
||||
|
||||
[ Well.. I once got the output with correct volume (i.e. same with the
|
||||
|
||||
.. [#]
|
||||
Well.. I once got the output with correct volume (i.e. same with the
|
||||
front one) and was so excited. It was even with "Four Channel" bit
|
||||
on and "double DAC" mode. Actually I could hear separate 4 channels
|
||||
from front and rear speakers! But.. after reboot, all was gone.
|
||||
It's a very pity that I didn't save the register dump at that
|
||||
time.. Maybe there is an unknown register to achieve this... ]
|
||||
time.. Maybe there is an unknown register to achieve this...
|
||||
|
||||
If your card has an extra output jack for the rear output, the rear
|
||||
playback should be routed there as default. If not, there is a
|
||||
|
|
@ -73,12 +75,14 @@ cannot operate with full-duplex.
|
|||
|
||||
The 4.0 and 5.1 modes are defined as the pcm "surround40" and "surround51"
|
||||
in alsa-lib. For example, you can play a WAV file with 6 channels like
|
||||
::
|
||||
|
||||
% aplay -Dsurround51 sixchannels.wav
|
||||
|
||||
For programming the 4/6 channel playback, you need to specify the PCM
|
||||
channels as you like and set the format S16LE. For example, for playback
|
||||
with 4 channels,
|
||||
::
|
||||
|
||||
snd_pcm_hw_params_set_access(pcm, hw, SND_PCM_ACCESS_RW_INTERLEAVED);
|
||||
// or mmap if you like
|
||||
|
|
@ -89,13 +93,15 @@ and use the interleaved 4 channel data.
|
|||
|
||||
There are some control switches affecting to the speaker connections:
|
||||
|
||||
"Line-In Mode" - an enum control to change the behavior of line-in
|
||||
Line-In Mode
|
||||
an enum control to change the behavior of line-in
|
||||
jack. Either "Line-In", "Rear Output" or "Bass Output" can
|
||||
be selected. The last item is available only with model 039
|
||||
or newer.
|
||||
When "Rear Output" is chosen, the surround channels 3 and 4
|
||||
are output to line-in jack.
|
||||
"Mic-In Mode" - an enum control to change the behavior of mic-in
|
||||
Mic-In Mode
|
||||
an enum control to change the behavior of mic-in
|
||||
jack. Either "Mic-In" or "Center/LFE Output" can be
|
||||
selected.
|
||||
When "Center/LFE Output" is chosen, the center and bass
|
||||
|
|
@ -111,11 +117,14 @@ The SPDIF playback and capture are done via the third PCM device
|
|||
(hw:0,2). Usually this is assigned to the PCM device "spdif".
|
||||
The available rates are 44100 and 48000 Hz.
|
||||
For playback with aplay, you can run like below:
|
||||
::
|
||||
|
||||
% aplay -Dhw:0,2 foo.wav
|
||||
|
||||
or
|
||||
|
||||
::
|
||||
|
||||
% aplay -Dspdif foo.wav
|
||||
|
||||
24bit format is also supported experimentally.
|
||||
|
|
@ -140,31 +149,40 @@ off. (Also don't forget to turn on "IEC958 Output Switch", too.)
|
|||
|
||||
Additionally there are relevant control switches:
|
||||
|
||||
"IEC958 Mix Analog" - Mix analog PCM playback and FM-OPL/3 streams and
|
||||
IEC958 Mix Analog
|
||||
Mix analog PCM playback and FM-OPL/3 streams and
|
||||
output through SPDIF. This switch appears only on old chip
|
||||
models (CM8738 033 and 037).
|
||||
|
||||
Note: without this control you can output PCM to SPDIF.
|
||||
This is "mixing" of streams, so e.g. it's not for AC3 output
|
||||
(see the next section).
|
||||
|
||||
"IEC958 In Select" - Select SPDIF input, the internal CD-in (false)
|
||||
IEC958 In Select
|
||||
Select SPDIF input, the internal CD-in (false)
|
||||
and the external input (true).
|
||||
|
||||
"IEC958 Loop" - SPDIF input data is loop back into SPDIF
|
||||
IEC958 Loop
|
||||
SPDIF input data is loop back into SPDIF
|
||||
output (aka bypass)
|
||||
|
||||
"IEC958 Copyright" - Set the copyright bit.
|
||||
IEC958 Copyright
|
||||
Set the copyright bit.
|
||||
|
||||
"IEC958 5V" - Select 0.5V (coax) or 5V (optical) interface.
|
||||
IEC958 5V
|
||||
Select 0.5V (coax) or 5V (optical) interface.
|
||||
On some cards this doesn't work and you need to change the
|
||||
configuration with hardware dip-switch.
|
||||
|
||||
"IEC958 In Monitor" - SPDIF input is routed to DAC.
|
||||
IEC958 In Monitor
|
||||
SPDIF input is routed to DAC.
|
||||
|
||||
"IEC958 In Phase Inverse" - Set SPDIF input format as inverse.
|
||||
IEC958 In Phase Inverse
|
||||
Set SPDIF input format as inverse.
|
||||
[FIXME: this doesn't work on all chips..]
|
||||
|
||||
"IEC958 In Valid" - Set input validity flag detection.
|
||||
IEC958 In Valid
|
||||
Set input validity flag detection.
|
||||
|
||||
Note: When "PCM Playback Switch" is on, you'll hear the digital output
|
||||
stream through analog line-out.
|
||||
|
|
@ -217,7 +235,7 @@ to enable MIDI support. Valid I/O ports are 0x300, 0x310, 0x320 and
|
|||
With CMI8738 and newer chips, the MIDI interface is enabled by default
|
||||
and the driver automatically chooses a port address.
|
||||
|
||||
There is _no_ hardware wavetable function on this chip (except for
|
||||
There is *no* hardware wavetable function on this chip (except for
|
||||
OPL3 synth below).
|
||||
What's said as MIDI synth on Windows is a software synthesizer
|
||||
emulation. On Linux use TiMidity or other softsynth program for
|
||||
|
|
@ -1,3 +1,7 @@
|
|||
=================================================================
|
||||
Low latency, multichannel audio with JACK and the emu10k1/emu10k2
|
||||
=================================================================
|
||||
|
||||
This document is a guide to using the emu10k1 based devices with JACK for low
|
||||
latency, multichannel recording functionality. All of my recent work to allow
|
||||
Linux users to use the full capabilities of their hardware has been inspired
|
||||
|
|
@ -7,8 +11,6 @@ power of this hardware.
|
|||
http://www.kxproject.com
|
||||
- Lee Revell, 2005.03.30
|
||||
|
||||
Low latency, multichannel audio with JACK and the emu10k1/emu10k2
|
||||
-----------------------------------------------------------------
|
||||
|
||||
Until recently, emu10k1 users on Linux did not have access to the same low
|
||||
latency, multichannel features offered by the "kX ASIO" feature of their
|
||||
|
|
@ -23,14 +25,15 @@ select the correct device for JACK to use. Actually, for qjackctl users it's
|
|||
fairly self explanatory - select Duplex, then for capture and playback select
|
||||
the multichannel devices, set the in and out channels to 16, and the sample
|
||||
rate to 48000Hz. The command line looks like this:
|
||||
::
|
||||
|
||||
/usr/local/bin/jackd -R -dalsa -r48000 -p64 -n2 -D -Chw:0,2 -Phw:0,3 -S
|
||||
/usr/local/bin/jackd -R -dalsa -r48000 -p64 -n2 -D -Chw:0,2 -Phw:0,3 -S
|
||||
|
||||
This will give you 16 input ports and 16 output ports.
|
||||
|
||||
The 16 output ports map onto the 16 FX buses (or the first 16 of 64, for the
|
||||
Audigy). The mapping from FX bus to physical output is described in
|
||||
SB-Live-mixer.txt (or Audigy-mixer.txt).
|
||||
sb-live-mixer.rst (or audigy-mixer.rst).
|
||||
|
||||
The 16 input ports are connected to the 16 physical inputs. Contrary to
|
||||
popular belief, all emu10k1 cards are multichannel cards. Which of these
|
||||
|
|
@ -49,10 +52,11 @@ This chart, borrowed from kxfxlib/da_asio51.cpp, describes the mapping of JACK
|
|||
ports to FXBUS2 (multitrack recording input) and EXTOUT (physical output)
|
||||
channels.
|
||||
|
||||
/*JACK (& ASIO) mappings on 10k1 5.1 SBLive cards:
|
||||
--------------------------------------------
|
||||
JACK (& ASIO) mappings on 10k1 5.1 SBLive cards:
|
||||
|
||||
============== ======== ============
|
||||
JACK Epilog FXBUS2(nr)
|
||||
--------------------------------------------
|
||||
============== ======== ============
|
||||
capture_1 asio14 FXBUS2(0xe)
|
||||
capture_2 asio15 FXBUS2(0xf)
|
||||
capture_3 asio0 FXBUS2(0x0)
|
||||
|
|
@ -69,6 +73,6 @@ capture_13 asio10 FXBUS2(0xa)
|
|||
capture_14 asio11 FXBUS2(0xb)
|
||||
capture_15 asio12 FXBUS2(0xc)
|
||||
capture_16 asio13 FXBUS2(0xd)
|
||||
*/
|
||||
============== ======== ============
|
||||
|
||||
TODO: describe use of ld10k1/qlo10k1 in conjunction with JACK
|
||||
|
|
@ -1,21 +1,24 @@
|
|||
=======================================
|
||||
Software Interface ALSA-DSP MADI Driver
|
||||
=======================================
|
||||
|
||||
(translated from German, so no good English ;-),
|
||||
|
||||
2004 - winfried ritsch
|
||||
|
||||
|
||||
|
||||
Full functionality has been added to the driver. Since some of
|
||||
the Controls and startup-options are ALSA-Standard and only the
|
||||
special Controls are described and discussed below.
|
||||
Full functionality has been added to the driver. Since some of
|
||||
the Controls and startup-options are ALSA-Standard and only the
|
||||
special Controls are described and discussed below.
|
||||
|
||||
|
||||
hardware functionality:
|
||||
|
||||
Hardware functionality
|
||||
======================
|
||||
|
||||
Audio transmission:
|
||||
Audio transmission
|
||||
------------------
|
||||
|
||||
number of channels -- depends on transmission mode
|
||||
* number of channels -- depends on transmission mode
|
||||
|
||||
The number of channels chosen is from 1..Nmax. The reason to
|
||||
use for a lower number of channels is only resource allocation,
|
||||
|
|
@ -23,31 +26,34 @@ Software Interface ALSA-DSP MADI Driver
|
|||
allocated. So also the throughput of the PCI system can be
|
||||
scaled. (Only important for low performance boards).
|
||||
|
||||
Single Speed -- 1..64 channels
|
||||
* Single Speed -- 1..64 channels
|
||||
|
||||
.. note::
|
||||
(Note: Choosing the 56channel mode for transmission or as
|
||||
receiver, only 56 are transmitted/received over the MADI, but
|
||||
all 64 channels are available for the mixer, so channel count
|
||||
for the driver)
|
||||
|
||||
Double Speed -- 1..32 channels
|
||||
* Double Speed -- 1..32 channels
|
||||
|
||||
.. note::
|
||||
Note: Choosing the 56-channel mode for
|
||||
transmission/receive-mode , only 28 are transmitted/received
|
||||
over the MADI, but all 32 channels are available for the mixer,
|
||||
so channel count for the driver
|
||||
|
||||
|
||||
Quad Speed -- 1..16 channels
|
||||
* Quad Speed -- 1..16 channels
|
||||
|
||||
Note: Choosing the 56-channel mode for
|
||||
.. note::
|
||||
Choosing the 56-channel mode for
|
||||
transmission/receive-mode , only 14 are transmitted/received
|
||||
over the MADI, but all 16 channels are available for the mixer,
|
||||
so channel count for the driver
|
||||
|
||||
Format -- signed 32 Bit Little Endian (SNDRV_PCM_FMTBIT_S32_LE)
|
||||
* Format -- signed 32 Bit Little Endian (SNDRV_PCM_FMTBIT_S32_LE)
|
||||
|
||||
Sample Rates --
|
||||
* Sample Rates --
|
||||
|
||||
Single Speed -- 32000, 44100, 48000
|
||||
|
||||
|
|
@ -55,14 +61,13 @@ Software Interface ALSA-DSP MADI Driver
|
|||
|
||||
Quad Speed -- 128000, 176400, 192000 (untested)
|
||||
|
||||
access-mode -- MMAP (memory mapped), Not interleaved
|
||||
(PCM_NON-INTERLEAVED)
|
||||
* access-mode -- MMAP (memory mapped), Not interleaved (PCM_NON-INTERLEAVED)
|
||||
|
||||
buffer-sizes -- 64,128,256,512,1024,2048,8192 Samples
|
||||
* buffer-sizes -- 64,128,256,512,1024,2048,8192 Samples
|
||||
|
||||
fragments -- 2
|
||||
* fragments -- 2
|
||||
|
||||
Hardware-pointer -- 2 Modi
|
||||
* Hardware-pointer -- 2 Modi
|
||||
|
||||
|
||||
The Card supports the readout of the actual Buffer-pointer,
|
||||
|
|
@ -74,53 +79,54 @@ Software Interface ALSA-DSP MADI Driver
|
|||
precise-pointer.
|
||||
|
||||
|
||||
.. hint::
|
||||
(Hint: Experimenting I found that the pointer is maximum 64 to
|
||||
large never to small. So if you subtract 64 you always have a
|
||||
safe pointer for writing, which is used on this mode inside
|
||||
ALSA. In theory now you can get now a latency as low as 16
|
||||
Samples, which is a quarter of the interrupt possibilities.)
|
||||
|
||||
Precise Pointer -- off
|
||||
* Precise Pointer -- off
|
||||
interrupt used for pointer-calculation
|
||||
|
||||
Precise Pointer -- on
|
||||
|
||||
* Precise Pointer -- on
|
||||
hardware pointer used.
|
||||
|
||||
Controller:
|
||||
Controller
|
||||
----------
|
||||
|
||||
Since DSP-MADI-Mixer has 8152 Fader, it does not make sense to
|
||||
use the standard mixer-controls, since this would break most of
|
||||
(especially graphic) ALSA-Mixer GUIs. So Mixer control has be
|
||||
provided by a 2-dimensional controller using the
|
||||
hwdep-interface.
|
||||
|
||||
Since DSP-MADI-Mixer has 8152 Fader, it does not make sense to
|
||||
use the standard mixer-controls, since this would break most of
|
||||
(especially graphic) ALSA-Mixer GUIs. So Mixer control has be
|
||||
provided by a 2-dimensional controller using the
|
||||
hwdep-interface.
|
||||
|
||||
Also all 128+256 Peak and RMS-Meter can be accessed via the
|
||||
hwdep-interface. Since it could be a performance problem always
|
||||
copying and converting Peak and RMS-Levels even if you just need
|
||||
one, I decided to export the hardware structure, so that of
|
||||
needed some driver-guru can implement a memory-mapping of mixer
|
||||
or peak-meters over ioctl, or also to do only copying and no
|
||||
conversion. A test-application shows the usage of the controller.
|
||||
|
||||
Latency Controls --- not implemented !!!
|
||||
Also all 128+256 Peak and RMS-Meter can be accessed via the
|
||||
hwdep-interface. Since it could be a performance problem always
|
||||
copying and converting Peak and RMS-Levels even if you just need
|
||||
one, I decided to export the hardware structure, so that of
|
||||
needed some driver-guru can implement a memory-mapping of mixer
|
||||
or peak-meters over ioctl, or also to do only copying and no
|
||||
conversion. A test-application shows the usage of the controller.
|
||||
|
||||
* Latency Controls --- not implemented !!!
|
||||
|
||||
.. note::
|
||||
Note: Within the windows-driver the latency is accessible of a
|
||||
control-panel, but buffer-sizes are controlled with ALSA from
|
||||
hwparams-calls and should not be changed in run-state, I did not
|
||||
implement it here.
|
||||
|
||||
|
||||
System Clock -- suspended !!!!
|
||||
* System Clock -- suspended !!!!
|
||||
|
||||
Name -- "System Clock Mode"
|
||||
|
||||
Access -- Read Write
|
||||
|
||||
Values -- "Master" "Slave"
|
||||
* Name -- "System Clock Mode"
|
||||
|
||||
* Access -- Read Write
|
||||
|
||||
* Values -- "Master" "Slave"
|
||||
|
||||
.. note::
|
||||
!!!! This is a hardware-function but is in conflict with the
|
||||
Clock-source controller, which is a kind of ALSA-standard. I
|
||||
makes sense to set the card to a special mode (master at some
|
||||
|
|
@ -128,106 +134,107 @@ Software Interface ALSA-DSP MADI Driver
|
|||
a studio should have working synchronisations setup. So use
|
||||
Clock-source-controller instead !!!!
|
||||
|
||||
Clock Source
|
||||
* Clock Source
|
||||
|
||||
Name -- "Sample Clock Source"
|
||||
* Name -- "Sample Clock Source"
|
||||
|
||||
Access -- Read Write
|
||||
* Access -- Read Write
|
||||
|
||||
Values -- "AutoSync", "Internal 32.0 kHz", "Internal 44.1 kHz",
|
||||
"Internal 48.0 kHz", "Internal 64.0 kHz", "Internal 88.2 kHz",
|
||||
"Internal 96.0 kHz"
|
||||
* Values -- "AutoSync", "Internal 32.0 kHz", "Internal 44.1 kHz",
|
||||
"Internal 48.0 kHz", "Internal 64.0 kHz", "Internal 88.2 kHz",
|
||||
"Internal 96.0 kHz"
|
||||
|
||||
Choose between Master at a specific Frequency and so also the
|
||||
Speed-mode or Slave (Autosync). Also see "Preferred Sync Ref"
|
||||
|
||||
|
||||
.. warning::
|
||||
!!!! This is no pure hardware function but was implemented by
|
||||
ALSA by some ALSA-drivers before, so I use it also. !!!
|
||||
|
||||
|
||||
Preferred Sync Ref
|
||||
* Preferred Sync Ref
|
||||
|
||||
Name -- "Preferred Sync Reference"
|
||||
* Name -- "Preferred Sync Reference"
|
||||
|
||||
Access -- Read Write
|
||||
* Access -- Read Write
|
||||
|
||||
Values -- "Word" "MADI"
|
||||
* Values -- "Word" "MADI"
|
||||
|
||||
|
||||
Within the Auto-sync-Mode the preferred Sync Source can be
|
||||
chosen. If it is not available another is used if possible.
|
||||
|
||||
.. note::
|
||||
Note: Since MADI has a much higher bit-rate than word-clock, the
|
||||
card should synchronise better in MADI Mode. But since the
|
||||
RME-PLL is very good, there are almost no problems with
|
||||
word-clock too. I never found a difference.
|
||||
|
||||
|
||||
TX 64 channel ---
|
||||
* TX 64 channel
|
||||
|
||||
Name -- "TX 64 channels mode"
|
||||
* Name -- "TX 64 channels mode"
|
||||
|
||||
Access -- Read Write
|
||||
* Access -- Read Write
|
||||
|
||||
Values -- 0 1
|
||||
* Values -- 0 1
|
||||
|
||||
Using 64-channel-modus (1) or 56-channel-modus for
|
||||
MADI-transmission (0).
|
||||
|
||||
|
||||
.. note::
|
||||
Note: This control is for output only. Input-mode is detected
|
||||
automatically from hardware sending MADI.
|
||||
|
||||
|
||||
Clear TMS ---
|
||||
* Clear TMS
|
||||
|
||||
Name -- "Clear Track Marker"
|
||||
* Name -- "Clear Track Marker"
|
||||
|
||||
Access -- Read Write
|
||||
* Access -- Read Write
|
||||
|
||||
Values -- 0 1
|
||||
* Values -- 0 1
|
||||
|
||||
|
||||
Don't use to lower 5 Audio-bits on AES as additional Bits.
|
||||
|
||||
|
||||
Safe Mode oder Auto Input ---
|
||||
* Safe Mode oder Auto Input
|
||||
|
||||
Name -- "Safe Mode"
|
||||
* Name -- "Safe Mode"
|
||||
|
||||
Access -- Read Write
|
||||
* Access -- Read Write
|
||||
|
||||
Values -- 0 1
|
||||
|
||||
(default on)
|
||||
* Values -- 0 1 (default on)
|
||||
|
||||
If on (1), then if either the optical or coaxial connection
|
||||
has a failure, there is a takeover to the working one, with no
|
||||
sample failure. Its only useful if you use the second as a
|
||||
backup connection.
|
||||
|
||||
Input ---
|
||||
* Input
|
||||
|
||||
Name -- "Input Select"
|
||||
* Name -- "Input Select"
|
||||
|
||||
Access -- Read Write
|
||||
* Access -- Read Write
|
||||
|
||||
Values -- optical coaxial
|
||||
* Values -- optical coaxial
|
||||
|
||||
|
||||
Choosing the Input, optical or coaxial. If Safe-mode is active,
|
||||
this is the preferred Input.
|
||||
|
||||
-------------- Mixer ----------------------
|
||||
Mixer
|
||||
-----
|
||||
|
||||
Mixer
|
||||
* Mixer
|
||||
|
||||
Name -- "Mixer"
|
||||
* Name -- "Mixer"
|
||||
|
||||
Access -- Read Write
|
||||
* Access -- Read Write
|
||||
|
||||
Values - <channel-number 0-127> <Value 0-65535>
|
||||
* Values - <channel-number 0-127> <Value 0-65535>
|
||||
|
||||
|
||||
Here as a first value the channel-index is taken to get/set the
|
||||
|
|
@ -235,40 +242,41 @@ Software Interface ALSA-DSP MADI Driver
|
|||
fader and 64-127 the playback to outputs fader. Value 0
|
||||
is channel muted 0 and 32768 an amplification of 1.
|
||||
|
||||
Chn 1-64
|
||||
* Chn 1-64
|
||||
|
||||
fast mixer for the ALSA-mixer utils. The diagonal of the
|
||||
mixer-matrix is implemented from playback to output.
|
||||
|
||||
|
||||
Line Out
|
||||
* Line Out
|
||||
|
||||
Name -- "Line Out"
|
||||
* Name -- "Line Out"
|
||||
|
||||
Access -- Read Write
|
||||
* Access -- Read Write
|
||||
|
||||
Values -- 0 1
|
||||
* Values -- 0 1
|
||||
|
||||
Switching on and off the analog out, which has nothing to do
|
||||
with mixing or routing. the analog outs reflects channel 63,64.
|
||||
|
||||
|
||||
--- information (only read access):
|
||||
Information (only read access)
|
||||
------------------------------
|
||||
|
||||
Sample Rate
|
||||
* Sample Rate
|
||||
|
||||
Name -- "System Sample Rate"
|
||||
* Name -- "System Sample Rate"
|
||||
|
||||
Access -- Read-only
|
||||
* Access -- Read-only
|
||||
|
||||
getting the sample rate.
|
||||
|
||||
|
||||
External Rate measured
|
||||
* External Rate measured
|
||||
|
||||
Name -- "External Rate"
|
||||
* Name -- "External Rate"
|
||||
|
||||
Access -- Read only
|
||||
* Access -- Read only
|
||||
|
||||
|
||||
Should be "Autosync Rate", but Name used is
|
||||
|
|
@ -276,79 +284,86 @@ Software Interface ALSA-DSP MADI Driver
|
|||
reported.
|
||||
|
||||
|
||||
MADI Sync Status
|
||||
* MADI Sync Status
|
||||
|
||||
Name -- "MADI Sync Lock Status"
|
||||
* Name -- "MADI Sync Lock Status"
|
||||
|
||||
Access -- Read
|
||||
* Access -- Read
|
||||
|
||||
Values -- 0,1,2
|
||||
* Values -- 0,1,2
|
||||
|
||||
MADI-Input is 0=Unlocked, 1=Locked, or 2=Synced.
|
||||
|
||||
|
||||
Word Clock Sync Status
|
||||
* Word Clock Sync Status
|
||||
|
||||
Name -- "Word Clock Lock Status"
|
||||
* Name -- "Word Clock Lock Status"
|
||||
|
||||
Access -- Read
|
||||
* Access -- Read
|
||||
|
||||
Values -- 0,1,2
|
||||
* Values -- 0,1,2
|
||||
|
||||
Word Clock Input is 0=Unlocked, 1=Locked, or 2=Synced.
|
||||
|
||||
AutoSync
|
||||
* AutoSync
|
||||
|
||||
Name -- "AutoSync Reference"
|
||||
* Name -- "AutoSync Reference"
|
||||
|
||||
Access -- Read
|
||||
* Access -- Read
|
||||
|
||||
Values -- "WordClock", "MADI", "None"
|
||||
* Values -- "WordClock", "MADI", "None"
|
||||
|
||||
Sync-Reference is either "WordClock", "MADI" or none.
|
||||
|
||||
RX 64ch --- noch nicht implementiert
|
||||
* RX 64ch --- noch nicht implementiert
|
||||
|
||||
MADI-Receiver is in 64 channel mode oder 56 channel mode.
|
||||
|
||||
|
||||
AB_inp --- not tested
|
||||
* AB_inp --- not tested
|
||||
|
||||
Used input for Auto-Input.
|
||||
|
||||
|
||||
actual Buffer Position --- not implemented
|
||||
* actual Buffer Position --- not implemented
|
||||
|
||||
!!! this is a ALSA internal function, so no control is used !!!
|
||||
|
||||
|
||||
|
||||
Calling Parameter:
|
||||
Calling Parameter
|
||||
=================
|
||||
|
||||
index int array (min = 1, max = 8),
|
||||
"Index value for RME HDSPM interface." card-index within ALSA
|
||||
* index int array (min = 1, max = 8)
|
||||
|
||||
Index value for RME HDSPM interface. card-index within ALSA
|
||||
|
||||
note: ALSA-standard
|
||||
|
||||
id string array (min = 1, max = 8),
|
||||
"ID string for RME HDSPM interface."
|
||||
* id string array (min = 1, max = 8)
|
||||
|
||||
ID string for RME HDSPM interface.
|
||||
|
||||
note: ALSA-standard
|
||||
|
||||
enable int array (min = 1, max = 8),
|
||||
"Enable/disable specific HDSPM sound-cards."
|
||||
* enable int array (min = 1, max = 8)
|
||||
|
||||
Enable/disable specific HDSPM sound-cards.
|
||||
|
||||
note: ALSA-standard
|
||||
|
||||
precise_ptr int array (min = 1, max = 8),
|
||||
"Enable precise pointer, or disable."
|
||||
* precise_ptr int array (min = 1, max = 8)
|
||||
|
||||
Enable precise pointer, or disable.
|
||||
|
||||
.. note::
|
||||
note: Use only when the application supports this (which is a special case).
|
||||
|
||||
line_outs_monitor int array (min = 1, max = 8),
|
||||
"Send playback streams to analog outs by default."
|
||||
* line_outs_monitor int array (min = 1, max = 8)
|
||||
|
||||
Send playback streams to analog outs by default.
|
||||
|
||||
.. note::
|
||||
note: each playback channel is mixed to the same numbered output
|
||||
channel (routed). This is against the ALSA-convention, where all
|
||||
channels have to be muted on after loading the driver, but was
|
||||
|
|
@ -356,7 +371,9 @@ Calling Parameter:
|
|||
|
||||
|
||||
|
||||
enable_monitor int array (min = 1, max = 8),
|
||||
"Enable Analog Out on Channel 63/64 by default."
|
||||
* enable_monitor int array (min = 1, max = 8)
|
||||
|
||||
Enable Analog Out on Channel 63/64 by default.
|
||||
|
||||
.. note ::
|
||||
note: here the analog output is enabled (but not routed).
|
||||
|
|
@ -1,21 +1,25 @@
|
|||
================================================
|
||||
Imagination Technologies SPDIF Input Controllers
|
||||
================================================
|
||||
|
||||
The Imagination Technologies SPDIF Input controller contains the following
|
||||
controls:
|
||||
|
||||
name='IEC958 Capture Mask',index=0
|
||||
* name='IEC958 Capture Mask',index=0
|
||||
|
||||
This control returns a mask that shows which of the IEC958 status bits
|
||||
can be read using the 'IEC958 Capture Default' control.
|
||||
|
||||
name='IEC958 Capture Default',index=0
|
||||
* name='IEC958 Capture Default',index=0
|
||||
|
||||
This control returns the status bits contained within the SPDIF stream that
|
||||
is being received. The 'IEC958 Capture Mask' shows which bits can be read
|
||||
from this control.
|
||||
|
||||
name='SPDIF In Multi Frequency Acquire',index=0
|
||||
name='SPDIF In Multi Frequency Acquire',index=1
|
||||
name='SPDIF In Multi Frequency Acquire',index=2
|
||||
name='SPDIF In Multi Frequency Acquire',index=3
|
||||
* name='SPDIF In Multi Frequency Acquire',index=0
|
||||
* name='SPDIF In Multi Frequency Acquire',index=1
|
||||
* name='SPDIF In Multi Frequency Acquire',index=2
|
||||
* name='SPDIF In Multi Frequency Acquire',index=3
|
||||
|
||||
This control is used to attempt acquisition of up to four different sample
|
||||
rates. The active rate can be obtained by reading the 'SPDIF In Lock Frequency'
|
||||
|
|
@ -29,21 +33,21 @@ four sample rates set here.
|
|||
If less than four rates are required, the same rate can be specified more than
|
||||
once
|
||||
|
||||
name='SPDIF In Lock Frequency',index=0
|
||||
* name='SPDIF In Lock Frequency',index=0
|
||||
|
||||
This control returns the active capture rate, or 0 if a lock has not been
|
||||
acquired
|
||||
|
||||
name='SPDIF In Lock TRK',index=0
|
||||
* name='SPDIF In Lock TRK',index=0
|
||||
|
||||
This control is used to modify the locking/jitter rejection characteristics
|
||||
of the block. Larger values increase the locking range, but reduce jitter
|
||||
rejection.
|
||||
|
||||
name='SPDIF In Lock Acquire Threshold',index=0
|
||||
* name='SPDIF In Lock Acquire Threshold',index=0
|
||||
|
||||
This control is used to change the threshold at which a lock is acquired.
|
||||
|
||||
name='SPDIF In Lock Release Threshold',index=0
|
||||
* name='SPDIF In Lock Release Threshold',index=0
|
||||
|
||||
This control is used to change the threshold at which a lock is released.
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
Card-Specific Information
|
||||
=========================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
joystick
|
||||
cmipci
|
||||
sb-live-mixer
|
||||
audigy-mixer
|
||||
emu10k1-jack
|
||||
via82xx-mixer
|
||||
audiophile-usb
|
||||
mixart
|
||||
bt87x
|
||||
maya44
|
||||
hdspm
|
||||
serial-u16550
|
||||
img-spdif-in
|
||||
|
|
@ -1,7 +1,10 @@
|
|||
=======================================
|
||||
Analog Joystick Support on ALSA Drivers
|
||||
=======================================
|
||||
Oct. 14, 2003
|
||||
Takashi Iwai <tiwai@suse.de>
|
||||
|
||||
Oct. 14, 2003
|
||||
|
||||
Takashi Iwai <tiwai@suse.de>
|
||||
|
||||
General
|
||||
-------
|
||||
|
|
@ -34,44 +37,46 @@ stability and the resource management.
|
|||
|
||||
The following PCI drivers support the joystick natively.
|
||||
|
||||
Driver Module Option Available Values
|
||||
---------------------------------------------------------------------------
|
||||
als4000 joystick_port 0 = disable (default), 1 = auto-detect,
|
||||
manual: any address (e.g. 0x200)
|
||||
au88x0 N/A N/A
|
||||
azf3328 joystick 0 = disable, 1 = enable, -1 = auto (default)
|
||||
ens1370 joystick 0 = disable (default), 1 = enable
|
||||
ens1371 joystick_port 0 = disable (default), 1 = auto-detect,
|
||||
manual: 0x200, 0x208, 0x210, 0x218
|
||||
cmipci joystick_port 0 = disable (default), 1 = auto-detect,
|
||||
manual: any address (e.g. 0x200)
|
||||
cs4281 N/A N/A
|
||||
cs46xx N/A N/A
|
||||
es1938 N/A N/A
|
||||
es1968 joystick 0 = disable (default), 1 = enable
|
||||
sonicvibes N/A N/A
|
||||
trident N/A N/A
|
||||
via82xx(*1) joystick 0 = disable (default), 1 = enable
|
||||
ymfpci joystick_port 0 = disable (default), 1 = auto-detect,
|
||||
manual: 0x201, 0x202, 0x204, 0x205(*2)
|
||||
---------------------------------------------------------------------------
|
||||
============== ============= ============================================
|
||||
Driver Module Option Available Values
|
||||
============== ============= ============================================
|
||||
als4000 joystick_port 0 = disable (default), 1 = auto-detect,
|
||||
manual: any address (e.g. 0x200)
|
||||
au88x0 N/A N/A
|
||||
azf3328 joystick 0 = disable, 1 = enable, -1 = auto (default)
|
||||
ens1370 joystick 0 = disable (default), 1 = enable
|
||||
ens1371 joystick_port 0 = disable (default), 1 = auto-detect,
|
||||
manual: 0x200, 0x208, 0x210, 0x218
|
||||
cmipci joystick_port 0 = disable (default), 1 = auto-detect,
|
||||
manual: any address (e.g. 0x200)
|
||||
cs4281 N/A N/A
|
||||
cs46xx N/A N/A
|
||||
es1938 N/A N/A
|
||||
es1968 joystick 0 = disable (default), 1 = enable
|
||||
sonicvibes N/A N/A
|
||||
trident N/A N/A
|
||||
via82xx [#f1]_ joystick 0 = disable (default), 1 = enable
|
||||
ymfpci joystick_port 0 = disable (default), 1 = auto-detect,
|
||||
manual: 0x201, 0x202, 0x204, 0x205 [#f2]_
|
||||
============== ============= ============================================
|
||||
|
||||
*1) VIA686A/B only
|
||||
*2) With YMF744/754 chips, the port address can be chosen arbitrarily
|
||||
.. [#f1] VIA686A/B only
|
||||
.. [#f2] With YMF744/754 chips, the port address can be chosen arbitrarily
|
||||
|
||||
The following drivers don't support gameport natively, but there are
|
||||
additional modules. Load the corresponding module to add the gameport
|
||||
support.
|
||||
|
||||
Driver Additional Module
|
||||
-----------------------------
|
||||
emu10k1 emu10k1-gp
|
||||
fm801 fm801-gp
|
||||
-----------------------------
|
||||
======= =================
|
||||
Driver Additional Module
|
||||
======= =================
|
||||
emu10k1 emu10k1-gp
|
||||
fm801 fm801-gp
|
||||
======= =================
|
||||
|
||||
Note: the "pcigame" and "cs461x" modules are for the OSS drivers only.
|
||||
These ALSA drivers (cs46xx, trident and au88x0) have the
|
||||
built-in gameport support.
|
||||
These ALSA drivers (cs46xx, trident and au88x0) have the
|
||||
built-in gameport support.
|
||||
|
||||
As mentioned above, ALSA PCI drivers have the built-in gameport
|
||||
support, so you don't have to load ns558 module. Just load "joydev"
|
||||
|
|
@ -1,10 +1,18 @@
|
|||
NOTE: The following is the original document of Rainer's patch that the
|
||||
current maya44 code based on. Some contents might be obsoleted, but I
|
||||
keep here as reference -- tiwai
|
||||
=================================
|
||||
Notes on Maya44 USB Audio Support
|
||||
=================================
|
||||
|
||||
----------------------------------------------------------------
|
||||
.. note::
|
||||
The following is the original document of Rainer's patch that the
|
||||
current maya44 code based on. Some contents might be obsoleted, but I
|
||||
keep here as reference -- tiwai
|
||||
|
||||
Feb 14, 2008
|
||||
|
||||
Rainer Zimmermann <mail@lightshed.de>
|
||||
|
||||
STATE OF DEVELOPMENT:
|
||||
STATE OF DEVELOPMENT
|
||||
====================
|
||||
|
||||
This driver is being developed on the initiative of Piotr Makowski (oponek@gmail.com) and financed by Lars Bergmann.
|
||||
Development is carried out by Rainer Zimmermann (mail@lightshed.de).
|
||||
|
|
@ -44,16 +52,17 @@ Things that do not seem to work:
|
|||
- Ardour 2.1 seems to work only via JACK, not using ALSA directly or via OSS. This still needs to be tracked down.
|
||||
|
||||
|
||||
DRIVER DETAILS:
|
||||
DRIVER DETAILS
|
||||
==============
|
||||
|
||||
the following files were added:
|
||||
|
||||
pci/ice1724/maya44.c - Maya44 specific code
|
||||
pci/ice1724/maya44.h
|
||||
pci/ice1724/ice1724.patch
|
||||
pci/ice1724/ice1724.h.patch - PROPOSED patch to ice1724.h (see SAMPLING RATES)
|
||||
i2c/other/wm8776.c - low-level access routines for Wolfson WM8776 codecs
|
||||
include/wm8776.h
|
||||
* pci/ice1724/maya44.c - Maya44 specific code
|
||||
* pci/ice1724/maya44.h
|
||||
* pci/ice1724/ice1724.patch
|
||||
* pci/ice1724/ice1724.h.patch - PROPOSED patch to ice1724.h (see SAMPLING RATES)
|
||||
* i2c/other/wm8776.c - low-level access routines for Wolfson WM8776 codecs
|
||||
* include/wm8776.h
|
||||
|
||||
|
||||
Note that the wm8776.c code is meant to be card-independent and does not actually register the codec with the ALSA infrastructure.
|
||||
|
|
@ -62,25 +71,26 @@ This is done in maya44.c, mainly because some of the WM8776 controls are used in
|
|||
|
||||
the following files were created in pci/ice1724, simply #including the corresponding file from the alsa-kernel tree:
|
||||
|
||||
wtm.h
|
||||
vt1720_mobo.h
|
||||
revo.h
|
||||
prodigy192.h
|
||||
pontis.h
|
||||
phase.h
|
||||
maya44.h
|
||||
juli.h
|
||||
aureon.h
|
||||
amp.h
|
||||
envy24ht.h
|
||||
se.h
|
||||
prodigy_hifi.h
|
||||
* wtm.h
|
||||
* vt1720_mobo.h
|
||||
* revo.h
|
||||
* prodigy192.h
|
||||
* pontis.h
|
||||
* phase.h
|
||||
* maya44.h
|
||||
* juli.h
|
||||
* aureon.h
|
||||
* amp.h
|
||||
* envy24ht.h
|
||||
* se.h
|
||||
* prodigy_hifi.h
|
||||
|
||||
|
||||
*I hope this is the correct way to do things.*
|
||||
|
||||
|
||||
SAMPLING RATES:
|
||||
SAMPLING RATES
|
||||
==============
|
||||
|
||||
The Maya44 card (or more exactly, the Wolfson WM8776 codecs) allow a maximum sampling rate of 192 kHz for playback and 92 kHz for capture.
|
||||
|
||||
|
|
@ -98,66 +108,79 @@ I propose some additional code for limiting the sampling rate when setting on a
|
|||
The proposed code (currently deactivated) is in ice1712.h.patch, ice1724.c and maya44.c (in pci/ice1712).
|
||||
|
||||
|
||||
SOUND DEVICES:
|
||||
SOUND DEVICES
|
||||
=============
|
||||
|
||||
PCM devices correspond to inputs/outputs as follows (assuming Maya44 is card #0):
|
||||
|
||||
hw:0,0 input - stereo, analog input 1+2
|
||||
hw:0,0 output - stereo, analog output 1+2
|
||||
hw:0,1 input - stereo, analog input 3+4 OR S/PDIF input
|
||||
hw:0,1 output - stereo, analog output 3+4 (and SPDIF out)
|
||||
* hw:0,0 input - stereo, analog input 1+2
|
||||
* hw:0,0 output - stereo, analog output 1+2
|
||||
* hw:0,1 input - stereo, analog input 3+4 OR S/PDIF input
|
||||
* hw:0,1 output - stereo, analog output 3+4 (and SPDIF out)
|
||||
|
||||
|
||||
NAMING OF MIXER CONTROLS:
|
||||
NAMING OF MIXER CONTROLS
|
||||
========================
|
||||
|
||||
(for more information about the signal flow, please refer to the block diagram on p.24 of the ESI Maya44 manual, or in the ESI windows software).
|
||||
|
||||
|
||||
PCM: (digital) output level for channel 1+2
|
||||
PCM 1: same for channel 3+4
|
||||
PCM
|
||||
(digital) output level for channel 1+2
|
||||
PCM 1
|
||||
same for channel 3+4
|
||||
|
||||
Mic Phantom+48V
|
||||
switch for +48V phantom power for electrostatic microphones on input 1/2.
|
||||
|
||||
Mic Phantom+48V: switch for +48V phantom power for electrostatic microphones on input 1/2.
|
||||
Make sure this is not turned on while any other source is connected to input 1/2.
|
||||
It might damage the source and/or the maya44 card.
|
||||
|
||||
Mic/Line input: if switch is on, input jack 1/2 is microphone input (mono), otherwise line input (stereo).
|
||||
Mic/Line input
|
||||
if switch is on, input jack 1/2 is microphone input (mono), otherwise line input (stereo).
|
||||
|
||||
Bypass: analogue bypass from ADC input to output for channel 1+2. Same as "Monitor" in the windows driver.
|
||||
Bypass 1: same for channel 3+4.
|
||||
Bypass
|
||||
analogue bypass from ADC input to output for channel 1+2. Same as "Monitor" in the windows driver.
|
||||
Bypass 1
|
||||
same for channel 3+4.
|
||||
|
||||
Crossmix: cross-mixer from channels 1+2 to channels 3+4
|
||||
Crossmix 1: cross-mixer from channels 3+4 to channels 1+2
|
||||
Crossmix
|
||||
cross-mixer from channels 1+2 to channels 3+4
|
||||
Crossmix 1
|
||||
cross-mixer from channels 3+4 to channels 1+2
|
||||
|
||||
IEC958 Output
|
||||
switch for S/PDIF output.
|
||||
|
||||
IEC958 Output: switch for S/PDIF output.
|
||||
This is not supported by the ESI windows driver.
|
||||
S/PDIF should output the same signal as channel 3+4. [untested!]
|
||||
|
||||
|
||||
Digitial output selectors:
|
||||
|
||||
Digitial output selectors
|
||||
These switches allow a direct digital routing from the ADCs to the DACs.
|
||||
Each switch determines where the digital input data to one of the DACs comes from.
|
||||
They are not supported by the ESI windows driver.
|
||||
For normal operation, they should all be set to "PCM out".
|
||||
|
||||
H/W: Output source channel 1
|
||||
H/W 1: Output source channel 2
|
||||
H/W 2: Output source channel 3
|
||||
H/W 3: Output source channel 4
|
||||
H/W
|
||||
Output source channel 1
|
||||
H/W 1
|
||||
Output source channel 2
|
||||
H/W 2
|
||||
Output source channel 3
|
||||
H/W 3
|
||||
Output source channel 4
|
||||
|
||||
H/W 4 ... H/W 9
|
||||
unknown function, left in to enable testing.
|
||||
|
||||
H/W 4 ... H/W 9: unknown function, left in to enable testing.
|
||||
Possibly some of these control S/PDIF output(s).
|
||||
If these turn out to be unused, they will go away in later driver versions.
|
||||
|
||||
Selectable values for each of the digital output selectors are:
|
||||
"PCM out" -> DAC output of the corresponding channel (default setting)
|
||||
"Input 1"...
|
||||
"Input 4" -> direct routing from ADC output of the selected input channel
|
||||
|
||||
|
||||
--------
|
||||
|
||||
Feb 14, 2008
|
||||
Rainer Zimmermann
|
||||
mail@lightshed.de
|
||||
PCM out
|
||||
DAC output of the corresponding channel (default setting)
|
||||
Input 1 ... Input 4
|
||||
direct routing from ADC output of the selected input channel
|
||||
|
||||
|
|
@ -1,5 +1,8 @@
|
|||
Alsa driver for Digigram miXart8 and miXart8AES/EBU soundcards
|
||||
Digigram <alsa@digigram.com>
|
||||
==============================================================
|
||||
Alsa driver for Digigram miXart8 and miXart8AES/EBU soundcards
|
||||
==============================================================
|
||||
|
||||
Digigram <alsa@digigram.com>
|
||||
|
||||
|
||||
GENERAL
|
||||
|
|
@ -48,11 +51,15 @@ formats are supported.
|
|||
|
||||
Mixer
|
||||
-----
|
||||
<Master> and <Master Capture> : analog volume control of playback and capture PCM.
|
||||
<PCM 0-3> and <PCM Capture> : digital volume control of each analog substream.
|
||||
<AES 0-3> and <AES Capture> : digital volume control of each AES/EBU substream.
|
||||
<Monitoring> : Loopback from 'pcm0c' to 'pcm0p' with digital volume
|
||||
and mute control.
|
||||
<Master> and <Master Capture>
|
||||
analog volume control of playback and capture PCM.
|
||||
<PCM 0-3> and <PCM Capture>
|
||||
digital volume control of each analog substream.
|
||||
<AES 0-3> and <AES Capture>
|
||||
digital volume control of each AES/EBU substream.
|
||||
<Monitoring>
|
||||
Loopback from 'pcm0c' to 'pcm0p' with digital volume
|
||||
and mute control.
|
||||
|
||||
Rem : for best audio quality try to keep a 0 attenuation on the PCM
|
||||
and AES volume controls which is set by 219 in the range from 0 to 255
|
||||
|
|
@ -79,11 +86,14 @@ FIRMWARE
|
|||
For loading the firmware automatically after the module is loaded, use a
|
||||
install command. For example, add the following entry to
|
||||
/etc/modprobe.d/mixart.conf for miXart driver:
|
||||
::
|
||||
|
||||
install snd-mixart /sbin/modprobe --first-time -i snd-mixart && \
|
||||
/usr/bin/mixartloader
|
||||
|
||||
|
||||
(for 2.2/2.4 kernels, add "post-install snd-mixart /usr/bin/vxloader" to
|
||||
/etc/modules.conf, instead.)
|
||||
/etc/modules.conf, instead.)
|
||||
|
||||
The firmware binaries are installed on /usr/share/alsa/firmware
|
||||
(or /usr/local/share/alsa/firmware, depending to the prefix option of
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
|
||||
Sound Blaster Live mixer / default DSP code
|
||||
===========================================
|
||||
===========================================
|
||||
Sound Blaster Live mixer / default DSP code
|
||||
===========================================
|
||||
|
||||
|
||||
The EMU10K1 chips have a DSP part which can be programmed to support
|
||||
|
|
@ -12,8 +12,8 @@ The ALSA driver programs this portion of chip by default code
|
|||
(can be altered later) which offers the following functionality:
|
||||
|
||||
|
||||
1) IEC958 (S/PDIF) raw PCM
|
||||
--------------------------
|
||||
IEC958 (S/PDIF) raw PCM
|
||||
=======================
|
||||
|
||||
This PCM device (it's the 4th PCM device (index 3!) and first subdevice
|
||||
(index 0) for a given card) allows to forward 48kHz, stereo, 16-bit
|
||||
|
|
@ -27,8 +27,8 @@ at the time.
|
|||
Look to tram_poke routines in lowlevel/emu10k1/emufx.c for more details.
|
||||
|
||||
|
||||
2) Digital mixer controls
|
||||
-------------------------
|
||||
Digital mixer controls
|
||||
======================
|
||||
|
||||
These controls are built using the DSP instructions. They offer extended
|
||||
functionality. Only the default build-in code in the ALSA driver is described
|
||||
|
|
@ -40,317 +40,334 @@ is mentioned in multiple controls, the signal is accumulated and can be wrapped
|
|||
|
||||
Explanation of used abbreviations:
|
||||
|
||||
DAC - digital to analog converter
|
||||
ADC - analog to digital converter
|
||||
I2S - one-way three wire serial bus for digital sound by Philips Semiconductors
|
||||
(this standard is used for connecting standalone DAC and ADC converters)
|
||||
LFE - low frequency effects (subwoofer signal)
|
||||
AC97 - a chip containing an analog mixer, DAC and ADC converters
|
||||
IEC958 - S/PDIF
|
||||
FX-bus - the EMU10K1 chip has an effect bus containing 16 accumulators.
|
||||
Each of the synthesizer voices can feed its output to these accumulators
|
||||
and the DSP microcontroller can operate with the resulting sum.
|
||||
DAC
|
||||
digital to analog converter
|
||||
ADC
|
||||
analog to digital converter
|
||||
I2S
|
||||
one-way three wire serial bus for digital sound by Philips Semiconductors
|
||||
(this standard is used for connecting standalone DAC and ADC converters)
|
||||
LFE
|
||||
low frequency effects (subwoofer signal)
|
||||
AC97
|
||||
a chip containing an analog mixer, DAC and ADC converters
|
||||
IEC958
|
||||
S/PDIF
|
||||
FX-bus
|
||||
the EMU10K1 chip has an effect bus containing 16 accumulators.
|
||||
Each of the synthesizer voices can feed its output to these accumulators
|
||||
and the DSP microcontroller can operate with the resulting sum.
|
||||
|
||||
|
||||
name='Wave Playback Volume',index=0
|
||||
|
||||
``name='Wave Playback Volume',index=0``
|
||||
---------------------------------------
|
||||
This control is used to attenuate samples for left and right PCM FX-bus
|
||||
accumulators. ALSA uses accumulators 0 and 1 for left and right PCM samples.
|
||||
The result samples are forwarded to the front DAC PCM slots of the AC97 codec.
|
||||
|
||||
name='Wave Surround Playback Volume',index=0
|
||||
|
||||
``name='Wave Surround Playback Volume',index=0``
|
||||
------------------------------------------------
|
||||
This control is used to attenuate samples for left and right PCM FX-bus
|
||||
accumulators. ALSA uses accumulators 0 and 1 for left and right PCM samples.
|
||||
The result samples are forwarded to the rear I2S DACs. These DACs operates
|
||||
separately (they are not inside the AC97 codec).
|
||||
|
||||
name='Wave Center Playback Volume',index=0
|
||||
|
||||
``name='Wave Center Playback Volume',index=0``
|
||||
----------------------------------------------
|
||||
This control is used to attenuate samples for left and right PCM FX-bus
|
||||
accumulators. ALSA uses accumulators 0 and 1 for left and right PCM samples.
|
||||
The result is mixed to mono signal (single channel) and forwarded to
|
||||
the ??rear?? right DAC PCM slot of the AC97 codec.
|
||||
|
||||
name='Wave LFE Playback Volume',index=0
|
||||
|
||||
``name='Wave LFE Playback Volume',index=0``
|
||||
-------------------------------------------
|
||||
This control is used to attenuate samples for left and right PCM FX-bus
|
||||
accumulators. ALSA uses accumulators 0 and 1 for left and right PCM.
|
||||
The result is mixed to mono signal (single channel) and forwarded to
|
||||
the ??rear?? left DAC PCM slot of the AC97 codec.
|
||||
|
||||
name='Wave Capture Volume',index=0
|
||||
name='Wave Capture Switch',index=0
|
||||
|
||||
``name='Wave Capture Volume',index=0``, ``name='Wave Capture Switch',index=0``
|
||||
------------------------------------------------------------------------------
|
||||
These controls are used to attenuate samples for left and right PCM FX-bus
|
||||
accumulator. ALSA uses accumulators 0 and 1 for left and right PCM.
|
||||
The result is forwarded to the ADC capture FIFO (thus to the standard capture
|
||||
PCM device).
|
||||
|
||||
name='Synth Playback Volume',index=0
|
||||
|
||||
``name='Synth Playback Volume',index=0``
|
||||
----------------------------------------
|
||||
This control is used to attenuate samples for left and right MIDI FX-bus
|
||||
accumulators. ALSA uses accumulators 4 and 5 for left and right MIDI samples.
|
||||
The result samples are forwarded to the front DAC PCM slots of the AC97 codec.
|
||||
|
||||
name='Synth Capture Volume',index=0
|
||||
name='Synth Capture Switch',index=0
|
||||
|
||||
``name='Synth Capture Volume',index=0``, ``name='Synth Capture Switch',index=0``
|
||||
--------------------------------------------------------------------------------
|
||||
These controls are used to attenuate samples for left and right MIDI FX-bus
|
||||
accumulator. ALSA uses accumulators 4 and 5 for left and right PCM.
|
||||
The result is forwarded to the ADC capture FIFO (thus to the standard capture
|
||||
PCM device).
|
||||
|
||||
name='Surround Playback Volume',index=0
|
||||
|
||||
``name='Surround Playback Volume',index=0``
|
||||
-------------------------------------------
|
||||
This control is used to attenuate samples for left and right rear PCM FX-bus
|
||||
accumulators. ALSA uses accumulators 2 and 3 for left and right rear PCM samples.
|
||||
The result samples are forwarded to the rear I2S DACs. These DACs operate
|
||||
separately (they are not inside the AC97 codec).
|
||||
|
||||
name='Surround Capture Volume',index=0
|
||||
name='Surround Capture Switch',index=0
|
||||
|
||||
``name='Surround Capture Volume',index=0``, ``name='Surround Capture Switch',index=0``
|
||||
--------------------------------------------------------------------------------------
|
||||
These controls are used to attenuate samples for left and right rear PCM FX-bus
|
||||
accumulators. ALSA uses accumulators 2 and 3 for left and right rear PCM samples.
|
||||
The result is forwarded to the ADC capture FIFO (thus to the standard capture
|
||||
PCM device).
|
||||
|
||||
name='Center Playback Volume',index=0
|
||||
|
||||
``name='Center Playback Volume',index=0``
|
||||
-----------------------------------------
|
||||
This control is used to attenuate sample for center PCM FX-bus accumulator.
|
||||
ALSA uses accumulator 6 for center PCM sample. The result sample is forwarded
|
||||
to the ??rear?? right DAC PCM slot of the AC97 codec.
|
||||
|
||||
name='LFE Playback Volume',index=0
|
||||
|
||||
``name='LFE Playback Volume',index=0``
|
||||
--------------------------------------
|
||||
This control is used to attenuate sample for center PCM FX-bus accumulator.
|
||||
ALSA uses accumulator 6 for center PCM sample. The result sample is forwarded
|
||||
to the ??rear?? left DAC PCM slot of the AC97 codec.
|
||||
|
||||
name='AC97 Playback Volume',index=0
|
||||
|
||||
``name='AC97 Playback Volume',index=0``
|
||||
---------------------------------------
|
||||
This control is used to attenuate samples for left and right front ADC PCM slots
|
||||
of the AC97 codec. The result samples are forwarded to the front DAC PCM
|
||||
slots of the AC97 codec.
|
||||
********************************************************************************
|
||||
*** Note: This control should be zero for the standard operations, otherwise ***
|
||||
*** a digital loopback is activated. ***
|
||||
********************************************************************************
|
||||
|
||||
name='AC97 Capture Volume',index=0
|
||||
.. note::
|
||||
This control should be zero for the standard operations, otherwise
|
||||
a digital loopback is activated.
|
||||
|
||||
|
||||
``name='AC97 Capture Volume',index=0``
|
||||
--------------------------------------
|
||||
This control is used to attenuate samples for left and right front ADC PCM slots
|
||||
of the AC97 codec. The result is forwarded to the ADC capture FIFO (thus to
|
||||
the standard capture PCM device).
|
||||
********************************************************************************
|
||||
*** Note: This control should be 100 (maximal value), otherwise no analog ***
|
||||
*** inputs of the AC97 codec can be captured (recorded). ***
|
||||
********************************************************************************
|
||||
|
||||
name='IEC958 TTL Playback Volume',index=0
|
||||
.. note::
|
||||
This control should be 100 (maximal value), otherwise no analog
|
||||
inputs of the AC97 codec can be captured (recorded).
|
||||
|
||||
``name='IEC958 TTL Playback Volume',index=0``
|
||||
---------------------------------------------
|
||||
This control is used to attenuate samples from left and right IEC958 TTL
|
||||
digital inputs (usually used by a CDROM drive). The result samples are
|
||||
forwarded to the front DAC PCM slots of the AC97 codec.
|
||||
|
||||
name='IEC958 TTL Capture Volume',index=0
|
||||
|
||||
``name='IEC958 TTL Capture Volume',index=0``
|
||||
--------------------------------------------
|
||||
This control is used to attenuate samples from left and right IEC958 TTL
|
||||
digital inputs (usually used by a CDROM drive). The result samples are
|
||||
forwarded to the ADC capture FIFO (thus to the standard capture PCM device).
|
||||
|
||||
name='Zoom Video Playback Volume',index=0
|
||||
|
||||
``name='Zoom Video Playback Volume',index=0``
|
||||
---------------------------------------------
|
||||
This control is used to attenuate samples from left and right zoom video
|
||||
digital inputs (usually used by a CDROM drive). The result samples are
|
||||
forwarded to the front DAC PCM slots of the AC97 codec.
|
||||
|
||||
name='Zoom Video Capture Volume',index=0
|
||||
|
||||
``name='Zoom Video Capture Volume',index=0``
|
||||
--------------------------------------------
|
||||
This control is used to attenuate samples from left and right zoom video
|
||||
digital inputs (usually used by a CDROM drive). The result samples are
|
||||
forwarded to the ADC capture FIFO (thus to the standard capture PCM device).
|
||||
|
||||
name='IEC958 LiveDrive Playback Volume',index=0
|
||||
|
||||
``name='IEC958 LiveDrive Playback Volume',index=0``
|
||||
---------------------------------------------------
|
||||
This control is used to attenuate samples from left and right IEC958 optical
|
||||
digital input. The result samples are forwarded to the front DAC PCM slots
|
||||
of the AC97 codec.
|
||||
|
||||
name='IEC958 LiveDrive Capture Volume',index=0
|
||||
|
||||
``name='IEC958 LiveDrive Capture Volume',index=0``
|
||||
--------------------------------------------------
|
||||
This control is used to attenuate samples from left and right IEC958 optical
|
||||
digital inputs. The result samples are forwarded to the ADC capture FIFO
|
||||
(thus to the standard capture PCM device).
|
||||
|
||||
name='IEC958 Coaxial Playback Volume',index=0
|
||||
|
||||
``name='IEC958 Coaxial Playback Volume',index=0``
|
||||
-------------------------------------------------
|
||||
This control is used to attenuate samples from left and right IEC958 coaxial
|
||||
digital inputs. The result samples are forwarded to the front DAC PCM slots
|
||||
of the AC97 codec.
|
||||
|
||||
name='IEC958 Coaxial Capture Volume',index=0
|
||||
|
||||
``name='IEC958 Coaxial Capture Volume',index=0``
|
||||
------------------------------------------------
|
||||
This control is used to attenuate samples from left and right IEC958 coaxial
|
||||
digital inputs. The result samples are forwarded to the ADC capture FIFO
|
||||
(thus to the standard capture PCM device).
|
||||
|
||||
name='Line LiveDrive Playback Volume',index=0
|
||||
name='Line LiveDrive Playback Volume',index=1
|
||||
|
||||
``name='Line LiveDrive Playback Volume',index=0``, ``name='Line LiveDrive Playback Volume',index=1``
|
||||
----------------------------------------------------------------------------------------------------
|
||||
This control is used to attenuate samples from left and right I2S ADC
|
||||
inputs (on the LiveDrive). The result samples are forwarded to the front
|
||||
DAC PCM slots of the AC97 codec.
|
||||
|
||||
name='Line LiveDrive Capture Volume',index=1
|
||||
name='Line LiveDrive Capture Volume',index=1
|
||||
|
||||
``name='Line LiveDrive Capture Volume',index=1``, ``name='Line LiveDrive Capture Volume',index=1``
|
||||
--------------------------------------------------------------------------------------------------
|
||||
This control is used to attenuate samples from left and right I2S ADC
|
||||
inputs (on the LiveDrive). The result samples are forwarded to the ADC
|
||||
capture FIFO (thus to the standard capture PCM device).
|
||||
|
||||
name='Tone Control - Switch',index=0
|
||||
|
||||
``name='Tone Control - Switch',index=0``
|
||||
----------------------------------------
|
||||
This control turns the tone control on or off. The samples for front, rear
|
||||
and center / LFE outputs are affected.
|
||||
|
||||
name='Tone Control - Bass',index=0
|
||||
|
||||
``name='Tone Control - Bass',index=0``
|
||||
--------------------------------------
|
||||
This control sets the bass intensity. There is no neutral value!!
|
||||
When the tone control code is activated, the samples are always modified.
|
||||
The closest value to pure signal is 20.
|
||||
|
||||
name='Tone Control - Treble',index=0
|
||||
|
||||
``name='Tone Control - Treble',index=0``
|
||||
----------------------------------------
|
||||
This control sets the treble intensity. There is no neutral value!!
|
||||
When the tone control code is activated, the samples are always modified.
|
||||
The closest value to pure signal is 20.
|
||||
|
||||
name='IEC958 Optical Raw Playback Switch',index=0
|
||||
|
||||
``name='IEC958 Optical Raw Playback Switch',index=0``
|
||||
-----------------------------------------------------
|
||||
If this switch is on, then the samples for the IEC958 (S/PDIF) digital
|
||||
output are taken only from the raw FX8010 PCM, otherwise standard front
|
||||
PCM samples are taken.
|
||||
|
||||
name='Headphone Playback Volume',index=1
|
||||
|
||||
``name='Headphone Playback Volume',index=1``
|
||||
--------------------------------------------
|
||||
This control attenuates the samples for the headphone output.
|
||||
|
||||
name='Headphone Center Playback Switch',index=1
|
||||
|
||||
``name='Headphone Center Playback Switch',index=1``
|
||||
---------------------------------------------------
|
||||
If this switch is on, then the sample for the center PCM is put to the
|
||||
left headphone output (useful for SB Live cards without separate center/LFE
|
||||
output).
|
||||
|
||||
name='Headphone LFE Playback Switch',index=1
|
||||
|
||||
``name='Headphone LFE Playback Switch',index=1``
|
||||
------------------------------------------------
|
||||
If this switch is on, then the sample for the center PCM is put to the
|
||||
right headphone output (useful for SB Live cards without separate center/LFE
|
||||
output).
|
||||
|
||||
|
||||
3) PCM stream related controls
|
||||
------------------------------
|
||||
|
||||
name='EMU10K1 PCM Volume',index 0-31
|
||||
PCM stream related controls
|
||||
===========================
|
||||
|
||||
``name='EMU10K1 PCM Volume',index 0-31``
|
||||
----------------------------------------
|
||||
Channel volume attenuation in range 0-0xffff. The maximum value (no
|
||||
attenuation) is default. The channel mapping for three values is
|
||||
as follows:
|
||||
|
||||
0 - mono, default 0xffff (no attenuation)
|
||||
1 - left, default 0xffff (no attenuation)
|
||||
2 - right, default 0xffff (no attenuation)
|
||||
|
||||
name='EMU10K1 PCM Send Routing',index 0-31
|
||||
* 0 - mono, default 0xffff (no attenuation)
|
||||
* 1 - left, default 0xffff (no attenuation)
|
||||
* 2 - right, default 0xffff (no attenuation)
|
||||
|
||||
``name='EMU10K1 PCM Send Routing',index 0-31``
|
||||
----------------------------------------------
|
||||
This control specifies the destination - FX-bus accumulators. There are
|
||||
twelve values with this mapping:
|
||||
|
||||
0 - mono, A destination (FX-bus 0-15), default 0
|
||||
1 - mono, B destination (FX-bus 0-15), default 1
|
||||
2 - mono, C destination (FX-bus 0-15), default 2
|
||||
3 - mono, D destination (FX-bus 0-15), default 3
|
||||
4 - left, A destination (FX-bus 0-15), default 0
|
||||
5 - left, B destination (FX-bus 0-15), default 1
|
||||
6 - left, C destination (FX-bus 0-15), default 2
|
||||
7 - left, D destination (FX-bus 0-15), default 3
|
||||
8 - right, A destination (FX-bus 0-15), default 0
|
||||
9 - right, B destination (FX-bus 0-15), default 1
|
||||
10 - right, C destination (FX-bus 0-15), default 2
|
||||
11 - right, D destination (FX-bus 0-15), default 3
|
||||
* 0 - mono, A destination (FX-bus 0-15), default 0
|
||||
* 1 - mono, B destination (FX-bus 0-15), default 1
|
||||
* 2 - mono, C destination (FX-bus 0-15), default 2
|
||||
* 3 - mono, D destination (FX-bus 0-15), default 3
|
||||
* 4 - left, A destination (FX-bus 0-15), default 0
|
||||
* 5 - left, B destination (FX-bus 0-15), default 1
|
||||
* 6 - left, C destination (FX-bus 0-15), default 2
|
||||
* 7 - left, D destination (FX-bus 0-15), default 3
|
||||
* 8 - right, A destination (FX-bus 0-15), default 0
|
||||
* 9 - right, B destination (FX-bus 0-15), default 1
|
||||
* 10 - right, C destination (FX-bus 0-15), default 2
|
||||
* 11 - right, D destination (FX-bus 0-15), default 3
|
||||
|
||||
Don't forget that it's illegal to assign a channel to the same FX-bus accumulator
|
||||
more than once (it means 0=0 && 1=0 is an invalid combination).
|
||||
|
||||
name='EMU10K1 PCM Send Volume',index 0-31
|
||||
|
||||
``name='EMU10K1 PCM Send Volume',index 0-31``
|
||||
---------------------------------------------
|
||||
It specifies the attenuation (amount) for given destination in range 0-255.
|
||||
The channel mapping is following:
|
||||
|
||||
0 - mono, A destination attn, default 255 (no attenuation)
|
||||
1 - mono, B destination attn, default 255 (no attenuation)
|
||||
2 - mono, C destination attn, default 0 (mute)
|
||||
3 - mono, D destination attn, default 0 (mute)
|
||||
4 - left, A destination attn, default 255 (no attenuation)
|
||||
5 - left, B destination attn, default 0 (mute)
|
||||
6 - left, C destination attn, default 0 (mute)
|
||||
7 - left, D destination attn, default 0 (mute)
|
||||
8 - right, A destination attn, default 0 (mute)
|
||||
9 - right, B destination attn, default 255 (no attenuation)
|
||||
10 - right, C destination attn, default 0 (mute)
|
||||
11 - right, D destination attn, default 0 (mute)
|
||||
* 0 - mono, A destination attn, default 255 (no attenuation)
|
||||
* 1 - mono, B destination attn, default 255 (no attenuation)
|
||||
* 2 - mono, C destination attn, default 0 (mute)
|
||||
* 3 - mono, D destination attn, default 0 (mute)
|
||||
* 4 - left, A destination attn, default 255 (no attenuation)
|
||||
* 5 - left, B destination attn, default 0 (mute)
|
||||
* 6 - left, C destination attn, default 0 (mute)
|
||||
* 7 - left, D destination attn, default 0 (mute)
|
||||
* 8 - right, A destination attn, default 0 (mute)
|
||||
* 9 - right, B destination attn, default 255 (no attenuation)
|
||||
* 10 - right, C destination attn, default 0 (mute)
|
||||
* 11 - right, D destination attn, default 0 (mute)
|
||||
|
||||
|
||||
|
||||
4) MANUALS/PATENTS:
|
||||
-------------------
|
||||
MANUALS/PATENTS
|
||||
===============
|
||||
|
||||
ftp://opensource.creative.com/pub/doc
|
||||
-------------------------------------
|
||||
|
||||
Files:
|
||||
LM4545.pdf AC97 Codec
|
||||
|
||||
m2049.pdf The EMU10K1 Digital Audio Processor
|
||||
|
||||
hog63.ps FX8010 - A DSP Chip Architecture for Audio Effects
|
||||
LM4545.pdf
|
||||
AC97 Codec
|
||||
m2049.pdf
|
||||
The EMU10K1 Digital Audio Processor
|
||||
hog63.ps
|
||||
FX8010 - A DSP Chip Architecture for Audio Effects
|
||||
|
||||
|
||||
WIPO Patents
|
||||
------------
|
||||
Patent numbers:
|
||||
WO 9901813 (A1) Audio Effects Processor with multiple asynchronous (Jan. 14, 1999)
|
||||
streams
|
||||
|
||||
WO 9901814 (A1) Processor with Instruction Set for Audio Effects (Jan. 14, 1999)
|
||||
WO 9901813 (A1)
|
||||
Audio Effects Processor with multiple asynchronous streams
|
||||
(Jan. 14, 1999)
|
||||
|
||||
WO 9901953 (A1) Audio Effects Processor having Decoupled Instruction
|
||||
Execution and Audio Data Sequencing (Jan. 14, 1999)
|
||||
WO 9901814 (A1)
|
||||
Processor with Instruction Set for Audio Effects (Jan. 14, 1999)
|
||||
|
||||
WO 9901953 (A1)
|
||||
Audio Effects Processor having Decoupled Instruction
|
||||
Execution and Audio Data Sequencing (Jan. 14, 1999)
|
||||
|
||||
|
||||
US Patents (http://www.uspto.gov/)
|
||||
----------------------------------
|
||||
|
||||
US 5925841 Digital Sampling Instrument employing cache memory (Jul. 20, 1999)
|
||||
US 5925841
|
||||
Digital Sampling Instrument employing cache memory (Jul. 20, 1999)
|
||||
|
||||
US 5928342 Audio Effects Processor integrated on a single chip (Jul. 27, 1999)
|
||||
with a multiport memory onto which multiple asynchronous
|
||||
digital sound samples can be concurrently loaded
|
||||
US 5928342
|
||||
Audio Effects Processor integrated on a single chip
|
||||
with a multiport memory onto which multiple asynchronous
|
||||
digital sound samples can be concurrently loaded
|
||||
(Jul. 27, 1999)
|
||||
|
||||
US 5930158 Processor with Instruction Set for Audio Effects (Jul. 27, 1999)
|
||||
US 5930158
|
||||
Processor with Instruction Set for Audio Effects (Jul. 27, 1999)
|
||||
|
||||
US 6032235 Memory initialization circuit (Tram) (Feb. 29, 2000)
|
||||
US 6032235
|
||||
Memory initialization circuit (Tram) (Feb. 29, 2000)
|
||||
|
||||
US 6138207 Interpolation looping of audio samples in cache connected to (Oct. 24, 2000)
|
||||
system bus with prioritization and modification of bus transfers
|
||||
in accordance with loop ends and minimum block sizes
|
||||
US 6138207
|
||||
Interpolation looping of audio samples in cache connected to
|
||||
system bus with prioritization and modification of bus transfers
|
||||
in accordance with loop ends and minimum block sizes
|
||||
(Oct. 24, 2000)
|
||||
|
||||
US 6151670 Method for conserving memory storage using a (Nov. 21, 2000)
|
||||
pool of short term memory registers
|
||||
US 6151670
|
||||
Method for conserving memory storage using a
|
||||
pool of short term memory registers
|
||||
(Nov. 21, 2000)
|
||||
|
||||
US 6195715 Interrupt control for multiple programs communicating with (Feb. 27, 2001)
|
||||
a common interrupt by associating programs to GP registers,
|
||||
defining interrupt register, polling GP registers, and invoking
|
||||
callback routine associated with defined interrupt register
|
||||
US 6195715
|
||||
Interrupt control for multiple programs communicating with
|
||||
a common interrupt by associating programs to GP registers,
|
||||
defining interrupt register, polling GP registers, and invoking
|
||||
callback routine associated with defined interrupt register
|
||||
(Feb. 27, 2001)
|
||||
|
|
@ -1,14 +1,14 @@
|
|||
|
||||
Serial UART 16450/16550 MIDI driver
|
||||
===================================
|
||||
===================================
|
||||
Serial UART 16450/16550 MIDI driver
|
||||
===================================
|
||||
|
||||
The adaptor module parameter allows you to select either:
|
||||
|
||||
0 - Roland Soundcanvas support (default)
|
||||
1 - Midiator MS-124T support (1)
|
||||
2 - Midiator MS-124W S/A mode (2)
|
||||
3 - MS-124W M/B mode support (3)
|
||||
4 - Generic device with multiple input support (4)
|
||||
* 0 - Roland Soundcanvas support (default)
|
||||
* 1 - Midiator MS-124T support (1)
|
||||
* 2 - Midiator MS-124W S/A mode (2)
|
||||
* 3 - MS-124W M/B mode support (3)
|
||||
* 4 - Generic device with multiple input support (4)
|
||||
|
||||
For the Midiator MS-124W, you must set the physical M-S and A-B
|
||||
switches on the Midiator to match the driver mode you select.
|
||||
|
|
@ -22,11 +22,13 @@ substream. The driver provides no way to send F5 00 (no selection) or to not
|
|||
send the F5 NN command sequence at all; perhaps it ought to.
|
||||
|
||||
Usage example for simple serial converter:
|
||||
::
|
||||
|
||||
/sbin/setserial /dev/ttyS0 uart none
|
||||
/sbin/modprobe snd-serial-u16550 port=0x3f8 irq=4 speed=115200
|
||||
|
||||
Usage example for Roland SoundCanvas with 4 MIDI ports:
|
||||
::
|
||||
|
||||
/sbin/setserial /dev/ttyS0 uart none
|
||||
/sbin/modprobe snd-serial-u16550 port=0x3f8 irq=4 outs=4
|
||||
|
|
@ -37,6 +39,7 @@ all four MIDI Out connectors. Set the A-B switch and the speed module
|
|||
parameter to match (A=19200, B=9600).
|
||||
|
||||
Usage example for MS-124T, with A-B switch in A position:
|
||||
::
|
||||
|
||||
/sbin/setserial /dev/ttyS0 uart none
|
||||
/sbin/modprobe snd-serial-u16550 port=0x3f8 irq=4 adaptor=1 \
|
||||
|
|
@ -47,6 +50,7 @@ the outs module parameter is automatically set to 1. The driver sends
|
|||
the same data to all four MIDI Out connectors at full MIDI speed.
|
||||
|
||||
Usage example for S/A mode:
|
||||
::
|
||||
|
||||
/sbin/setserial /dev/ttyS0 uart none
|
||||
/sbin/modprobe snd-serial-u16550 port=0x3f8 irq=4 adaptor=2
|
||||
|
|
@ -63,6 +67,7 @@ at most one byte every 520 us, as compared with the full MIDI data rate of
|
|||
one byte every 320 us per port.
|
||||
|
||||
Usage example for M/B mode:
|
||||
::
|
||||
|
||||
/sbin/setserial /dev/ttyS0 uart none
|
||||
/sbin/modprobe snd-serial-u16550 port=0x3f8 irq=4 adaptor=3
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
=============
|
||||
VIA82xx mixer
|
||||
=============
|
||||
|
||||
On many VIA82xx boards, the ``Input Source Select`` mixer control does not work.
|
||||
Setting it to ``Input2`` on such boards will cause recording to hang, or fail
|
||||
with EIO (input/output error) via OSS emulation. This control should be left
|
||||
at ``Input1`` for such cards.
|
||||
|
|
@ -1,9 +1,11 @@
|
|||
============================
|
||||
ALSA PCM channel-mapping API
|
||||
============================
|
||||
Takashi Iwai <tiwai@suse.de>
|
||||
|
||||
GENERAL
|
||||
-------
|
||||
Takashi Iwai <tiwai@suse.de>
|
||||
|
||||
General
|
||||
=======
|
||||
|
||||
The channel mapping API allows user to query the possible channel maps
|
||||
and the current channel map, also optionally to modify the channel map
|
||||
|
|
@ -11,9 +13,9 @@ of the current stream.
|
|||
|
||||
A channel map is an array of position for each PCM channel.
|
||||
Typically, a stereo PCM stream has a channel map of
|
||||
{ front_left, front_right }
|
||||
``{ front_left, front_right }``
|
||||
while a 4.0 surround PCM stream has a channel map of
|
||||
{ front left, front right, rear left, rear right }.
|
||||
``{ front left, front right, rear left, rear right }.``
|
||||
|
||||
The problem, so far, was that we had no standard channel map
|
||||
explicitly, and applications had no way to know which channel
|
||||
|
|
@ -29,8 +31,8 @@ specification. These are the main motivations for the new channel
|
|||
mapping API.
|
||||
|
||||
|
||||
DESIGN
|
||||
------
|
||||
Design
|
||||
======
|
||||
|
||||
Actually, "the channel mapping API" doesn't introduce anything new in
|
||||
the kernel/user-space ABI perspective. It uses only the existing
|
||||
|
|
@ -39,10 +41,11 @@ control element features.
|
|||
As a ground design, each PCM substream may contain a control element
|
||||
providing the channel mapping information and configuration. This
|
||||
element is specified by:
|
||||
iface = SNDRV_CTL_ELEM_IFACE_PCM
|
||||
name = "Playback Channel Map" or "Capture Channel Map"
|
||||
device = the same device number for the assigned PCM substream
|
||||
index = the same index number for the assigned PCM substream
|
||||
|
||||
* iface = SNDRV_CTL_ELEM_IFACE_PCM
|
||||
* name = "Playback Channel Map" or "Capture Channel Map"
|
||||
* device = the same device number for the assigned PCM substream
|
||||
* index = the same index number for the assigned PCM substream
|
||||
|
||||
Note the name is different depending on the PCM substream direction.
|
||||
|
||||
|
|
@ -50,32 +53,35 @@ Each control element provides at least the TLV read operation and the
|
|||
read operation. Optionally, the write operation can be provided to
|
||||
allow user to change the channel map dynamically.
|
||||
|
||||
* TLV
|
||||
TLV
|
||||
---
|
||||
|
||||
The TLV operation gives the list of available channel
|
||||
maps. A list item of a channel map is usually a TLV of
|
||||
type data-bytes ch0 ch1 ch2...
|
||||
``type data-bytes ch0 ch1 ch2...``
|
||||
where type is the TLV type value, the second argument is the total
|
||||
bytes (not the numbers) of channel values, and the rest are the
|
||||
position value for each channel.
|
||||
|
||||
As a TLV type, either SNDRV_CTL_TLVT_CHMAP_FIXED,
|
||||
SNDRV_CTL_TLV_CHMAP_VAR or SNDRV_CTL_TLVT_CHMAP_PAIRED can be used.
|
||||
The _FIXED type is for a channel map with the fixed channel position
|
||||
while the latter two are for flexible channel positions. _VAR type is
|
||||
for a channel map where all channels are freely swappable and _PAIRED
|
||||
As a TLV type, either ``SNDRV_CTL_TLVT_CHMAP_FIXED``,
|
||||
``SNDRV_CTL_TLV_CHMAP_VAR`` or ``SNDRV_CTL_TLVT_CHMAP_PAIRED`` can be used.
|
||||
The ``_FIXED`` type is for a channel map with the fixed channel position
|
||||
while the latter two are for flexible channel positions. ``_VAR`` type is
|
||||
for a channel map where all channels are freely swappable and ``_PAIRED``
|
||||
type is where pair-wise channels are swappable. For example, when you
|
||||
have {FL/FR/RL/RR} channel map, _PAIRED type would allow you to swap
|
||||
only {RL/RR/FL/FR} while _VAR type would allow even swapping FL and
|
||||
have {FL/FR/RL/RR} channel map, ``_PAIRED`` type would allow you to swap
|
||||
only {RL/RR/FL/FR} while ``_VAR`` type would allow even swapping FL and
|
||||
RR.
|
||||
|
||||
These new TLV types are defined in sound/tlv.h.
|
||||
These new TLV types are defined in ``sound/tlv.h``.
|
||||
|
||||
The available channel position values are defined in sound/asound.h,
|
||||
The available channel position values are defined in ``sound/asound.h``,
|
||||
here is a cut:
|
||||
|
||||
/* channel positions */
|
||||
enum {
|
||||
::
|
||||
|
||||
/* channel positions */
|
||||
enum {
|
||||
SNDRV_CHMAP_UNKNOWN = 0,
|
||||
SNDRV_CHMAP_NA, /* N/A, silent */
|
||||
SNDRV_CHMAP_MONO, /* mono stream */
|
||||
|
|
@ -107,11 +113,13 @@ enum {
|
|||
SNDRV_CHMAP_TRR, /* top rear right */
|
||||
SNDRV_CHMAP_TRC, /* top rear center */
|
||||
SNDRV_CHMAP_LAST = SNDRV_CHMAP_TRC,
|
||||
};
|
||||
};
|
||||
|
||||
When a PCM stream can provide more than one channel map, you can
|
||||
provide multiple channel maps in a TLV container type. The TLV data
|
||||
to be returned will contain such as:
|
||||
::
|
||||
|
||||
SNDRV_CTL_TLVT_CONTAINER 96
|
||||
SNDRV_CTL_TLVT_CHMAP_FIXED 4 SNDRV_CHMAP_FC
|
||||
SNDRV_CTL_TLVT_CHMAP_FIXED 8 SNDRV_CHMAP_FL SNDRV_CHMAP_FR
|
||||
|
|
@ -120,19 +128,21 @@ to be returned will contain such as:
|
|||
|
||||
The channel position is provided in LSB 16bits. The upper bits are
|
||||
used for bit flags.
|
||||
::
|
||||
|
||||
#define SNDRV_CHMAP_POSITION_MASK 0xffff
|
||||
#define SNDRV_CHMAP_PHASE_INVERSE (0x01 << 16)
|
||||
#define SNDRV_CHMAP_DRIVER_SPEC (0x02 << 16)
|
||||
#define SNDRV_CHMAP_POSITION_MASK 0xffff
|
||||
#define SNDRV_CHMAP_PHASE_INVERSE (0x01 << 16)
|
||||
#define SNDRV_CHMAP_DRIVER_SPEC (0x02 << 16)
|
||||
|
||||
SNDRV_CHMAP_PHASE_INVERSE indicates the channel is phase inverted,
|
||||
``SNDRV_CHMAP_PHASE_INVERSE`` indicates the channel is phase inverted,
|
||||
(thus summing left and right channels would result in almost silence).
|
||||
Some digital mic devices have this.
|
||||
|
||||
When SNDRV_CHMAP_DRIVER_SPEC is set, all the channel position values
|
||||
When ``SNDRV_CHMAP_DRIVER_SPEC`` is set, all the channel position values
|
||||
don't follow the standard definition above but driver-specific.
|
||||
|
||||
* READ OPERATION
|
||||
Read Operation
|
||||
--------------
|
||||
|
||||
The control read operation is for providing the current channel map of
|
||||
the given stream. The control element returns an integer array
|
||||
|
|
@ -140,9 +150,10 @@ containing the position of each channel.
|
|||
|
||||
When this is performed before the number of the channel is specified
|
||||
(i.e. hw_params is set), it should return all channels set to
|
||||
UNKNOWN.
|
||||
``UNKNOWN``.
|
||||
|
||||
* WRITE OPERATION
|
||||
Write Operation
|
||||
---------------
|
||||
|
||||
The control write operation is optional, and only for devices that can
|
||||
change the channel configuration on the fly, such as HDMI. User needs
|
||||
|
|
@ -1,10 +1,14 @@
|
|||
compress_offload.txt
|
||||
=====================
|
||||
Pierre-Louis.Bossart <pierre-louis.bossart@linux.intel.com>
|
||||
Vinod Koul <vinod.koul@linux.intel.com>
|
||||
=========================
|
||||
ALSA Compress-Offload API
|
||||
=========================
|
||||
|
||||
Pierre-Louis.Bossart <pierre-louis.bossart@linux.intel.com>
|
||||
|
||||
Vinod Koul <vinod.koul@linux.intel.com>
|
||||
|
||||
|
||||
Overview
|
||||
|
||||
========
|
||||
Since its early days, the ALSA API was defined with PCM support or
|
||||
constant bitrates payloads such as IEC61937 in mind. Arguments and
|
||||
returned values in frames are the norm, making it a challenge to
|
||||
|
|
@ -27,8 +31,9 @@ Intel Moorestown SOC, with many corrections required to upstream the
|
|||
API in the mainline kernel instead of the staging tree and make it
|
||||
usable by others.
|
||||
|
||||
Requirements
|
||||
|
||||
Requirements
|
||||
============
|
||||
The main requirements are:
|
||||
|
||||
- separation between byte counts and time. Compressed formats may have
|
||||
|
|
@ -63,7 +68,7 @@ The main requirements are:
|
|||
streaming compressed data to a DSP, with the assumption that the
|
||||
decoded samples are routed to a physical output or logical back-end.
|
||||
|
||||
- Complexity hiding. Existing user-space multimedia frameworks all
|
||||
- Complexity hiding. Existing user-space multimedia frameworks all
|
||||
have existing enums/structures for each compressed format. This new
|
||||
API assumes the existence of a platform-specific compatibility layer
|
||||
to expose, translate and make use of the capabilities of the audio
|
||||
|
|
@ -72,7 +77,7 @@ The main requirements are:
|
|||
|
||||
|
||||
Design
|
||||
|
||||
======
|
||||
The new API shares a number of concepts with the PCM API for flow
|
||||
control. Start, pause, resume, drain and stop commands have the same
|
||||
semantics no matter what the content is.
|
||||
|
|
@ -95,43 +100,44 @@ mandatory routines and possibly make use of optional ones.
|
|||
|
||||
The main additions are
|
||||
|
||||
- get_caps
|
||||
This routine returns the list of audio formats supported. Querying the
|
||||
codecs on a capture stream will return encoders, decoders will be
|
||||
listed for playback streams.
|
||||
get_caps
|
||||
This routine returns the list of audio formats supported. Querying the
|
||||
codecs on a capture stream will return encoders, decoders will be
|
||||
listed for playback streams.
|
||||
|
||||
- get_codec_caps For each codec, this routine returns a list of
|
||||
capabilities. The intent is to make sure all the capabilities
|
||||
correspond to valid settings, and to minimize the risks of
|
||||
configuration failures. For example, for a complex codec such as AAC,
|
||||
the number of channels supported may depend on a specific profile. If
|
||||
the capabilities were exposed with a single descriptor, it may happen
|
||||
that a specific combination of profiles/channels/formats may not be
|
||||
supported. Likewise, embedded DSPs have limited memory and cpu cycles,
|
||||
it is likely that some implementations make the list of capabilities
|
||||
dynamic and dependent on existing workloads. In addition to codec
|
||||
settings, this routine returns the minimum buffer size handled by the
|
||||
implementation. This information can be a function of the DMA buffer
|
||||
sizes, the number of bytes required to synchronize, etc, and can be
|
||||
used by userspace to define how much needs to be written in the ring
|
||||
buffer before playback can start.
|
||||
get_codec_caps
|
||||
For each codec, this routine returns a list of
|
||||
capabilities. The intent is to make sure all the capabilities
|
||||
correspond to valid settings, and to minimize the risks of
|
||||
configuration failures. For example, for a complex codec such as AAC,
|
||||
the number of channels supported may depend on a specific profile. If
|
||||
the capabilities were exposed with a single descriptor, it may happen
|
||||
that a specific combination of profiles/channels/formats may not be
|
||||
supported. Likewise, embedded DSPs have limited memory and cpu cycles,
|
||||
it is likely that some implementations make the list of capabilities
|
||||
dynamic and dependent on existing workloads. In addition to codec
|
||||
settings, this routine returns the minimum buffer size handled by the
|
||||
implementation. This information can be a function of the DMA buffer
|
||||
sizes, the number of bytes required to synchronize, etc, and can be
|
||||
used by userspace to define how much needs to be written in the ring
|
||||
buffer before playback can start.
|
||||
|
||||
- set_params
|
||||
This routine sets the configuration chosen for a specific codec. The
|
||||
most important field in the parameters is the codec type; in most
|
||||
cases decoders will ignore other fields, while encoders will strictly
|
||||
comply to the settings
|
||||
set_params
|
||||
This routine sets the configuration chosen for a specific codec. The
|
||||
most important field in the parameters is the codec type; in most
|
||||
cases decoders will ignore other fields, while encoders will strictly
|
||||
comply to the settings
|
||||
|
||||
- get_params
|
||||
This routines returns the actual settings used by the DSP. Changes to
|
||||
the settings should remain the exception.
|
||||
get_params
|
||||
This routines returns the actual settings used by the DSP. Changes to
|
||||
the settings should remain the exception.
|
||||
|
||||
- get_timestamp
|
||||
The timestamp becomes a multiple field structure. It lists the number
|
||||
of bytes transferred, the number of samples processed and the number
|
||||
of samples rendered/grabbed. All these values can be used to determine
|
||||
the average bitrate, figure out if the ring buffer needs to be
|
||||
refilled or the delay due to decoding/encoding/io on the DSP.
|
||||
get_timestamp
|
||||
The timestamp becomes a multiple field structure. It lists the number
|
||||
of bytes transferred, the number of samples processed and the number
|
||||
of samples rendered/grabbed. All these values can be used to determine
|
||||
the average bitrate, figure out if the ring buffer needs to be
|
||||
refilled or the delay due to decoding/encoding/io on the DSP.
|
||||
|
||||
Note that the list of codecs/profiles/modes was derived from the
|
||||
OpenMAX AL specification instead of reinventing the wheel.
|
||||
|
|
@ -145,6 +151,7 @@ Modifications include:
|
|||
- Addition of encoding options when required (derived from OpenMAX IL)
|
||||
- Addition of rateControlSupported (missing in OpenMAX AL)
|
||||
|
||||
|
||||
Gapless Playback
|
||||
================
|
||||
When playing thru an album, the decoders have the ability to skip the encoder
|
||||
|
|
@ -162,19 +169,19 @@ switch from one track to another and start using data for second track.
|
|||
|
||||
The main additions are:
|
||||
|
||||
- set_metadata
|
||||
This routine sets the encoder delay and encoder padding. This can be used by
|
||||
decoder to strip the silence. This needs to be set before the data in the track
|
||||
is written.
|
||||
set_metadata
|
||||
This routine sets the encoder delay and encoder padding. This can be used by
|
||||
decoder to strip the silence. This needs to be set before the data in the track
|
||||
is written.
|
||||
|
||||
- set_next_track
|
||||
This routine tells DSP that metadata and write operation sent after this would
|
||||
correspond to subsequent track
|
||||
set_next_track
|
||||
This routine tells DSP that metadata and write operation sent after this would
|
||||
correspond to subsequent track
|
||||
|
||||
- partial drain
|
||||
This is called when end of file is reached. The userspace can inform DSP that
|
||||
EOF is reached and now DSP can start skipping padding delay. Also next write
|
||||
data would belong to next track
|
||||
partial drain
|
||||
This is called when end of file is reached. The userspace can inform DSP that
|
||||
EOF is reached and now DSP can start skipping padding delay. Also next write
|
||||
data would belong to next track
|
||||
|
||||
Sequence flow for gapless would be:
|
||||
- Open
|
||||
|
|
@ -189,10 +196,12 @@ Sequence flow for gapless would be:
|
|||
- then call partial_drain to flush most of buffer in DSP
|
||||
- Fill data of the next track
|
||||
- DSP switches to second track
|
||||
|
||||
(note: order for partial_drain and write for next track can be reversed as well)
|
||||
|
||||
Not supported:
|
||||
|
||||
Not supported
|
||||
=============
|
||||
- Support for VoIP/circuit-switched calls is not the target of this
|
||||
API. Support for dynamic bit-rate changes would require a tight
|
||||
coupling between the DSP and the host stack, limiting power savings.
|
||||
|
|
@ -225,7 +234,9 @@ Not supported:
|
|||
rendered output in time, this does not deal with underrun/overrun and
|
||||
maybe dealt in user-library
|
||||
|
||||
Credits:
|
||||
|
||||
Credits
|
||||
=======
|
||||
- Mark Brown and Liam Girdwood for discussions on the need for this API
|
||||
- Harsha Priya for her work on intel_sst compressed API
|
||||
- Rakesh Ughreja for valuable feedback
|
||||
|
|
@ -0,0 +1,142 @@
|
|||
===========================
|
||||
Standard ALSA Control Names
|
||||
===========================
|
||||
|
||||
This document describes standard names of mixer controls.
|
||||
|
||||
Standard Syntax
|
||||
---------------
|
||||
Syntax: [LOCATION] SOURCE [CHANNEL] [DIRECTION] FUNCTION
|
||||
|
||||
|
||||
DIRECTION
|
||||
~~~~~~~~~
|
||||
================ ===============
|
||||
<nothing> both directions
|
||||
Playback one direction
|
||||
Capture one direction
|
||||
Bypass Playback one direction
|
||||
Bypass Capture one direction
|
||||
================ ===============
|
||||
|
||||
FUNCTION
|
||||
~~~~~~~~
|
||||
======== =================================
|
||||
Switch on/off switch
|
||||
Volume amplifier
|
||||
Route route control, hardware specific
|
||||
======== =================================
|
||||
|
||||
CHANNEL
|
||||
~~~~~~~
|
||||
============ ==================================================
|
||||
<nothing> channel independent, or applies to all channels
|
||||
Front front left/right channels
|
||||
Surround rear left/right in 4.0/5.1 surround
|
||||
CLFE C/LFE channels
|
||||
Center center cannel
|
||||
LFE LFE channel
|
||||
Side side left/right for 7.1 surround
|
||||
============ ==================================================
|
||||
|
||||
LOCATION (Physical location of source)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
============ =====================
|
||||
Front front position
|
||||
Rear rear position
|
||||
Dock on docking station
|
||||
Internal internal
|
||||
============ =====================
|
||||
|
||||
SOURCE
|
||||
~~~~~~
|
||||
=================== =================================================
|
||||
Master
|
||||
Master Mono
|
||||
Hardware Master
|
||||
Speaker internal speaker
|
||||
Bass Speaker internal LFE speaker
|
||||
Headphone
|
||||
Line Out
|
||||
Beep beep generator
|
||||
Phone
|
||||
Phone Input
|
||||
Phone Output
|
||||
Synth
|
||||
FM
|
||||
Mic
|
||||
Headset Mic mic part of combined headset jack - 4-pin
|
||||
headphone + mic
|
||||
Headphone Mic mic part of either/or - 3-pin headphone or mic
|
||||
Line input only, use "Line Out" for output
|
||||
CD
|
||||
Video
|
||||
Zoom Video
|
||||
Aux
|
||||
PCM
|
||||
PCM Pan
|
||||
Loopback
|
||||
Analog Loopback D/A -> A/D loopback
|
||||
Digital Loopback playback -> capture loopback -
|
||||
without analog path
|
||||
Mono
|
||||
Mono Output
|
||||
Multi
|
||||
ADC
|
||||
Wave
|
||||
Music
|
||||
I2S
|
||||
IEC958
|
||||
HDMI
|
||||
SPDIF output only
|
||||
SPDIF In
|
||||
Digital In
|
||||
HDMI/DP either HDMI or DisplayPort
|
||||
=================== =================================================
|
||||
|
||||
Exceptions (deprecated)
|
||||
-----------------------
|
||||
|
||||
===================================== =======================
|
||||
[Analogue|Digital] Capture Source
|
||||
[Analogue|Digital] Capture Switch aka input gain switch
|
||||
[Analogue|Digital] Capture Volume aka input gain volume
|
||||
[Analogue|Digital] Playback Switch aka output gain switch
|
||||
[Analogue|Digital] Playback Volume aka output gain volume
|
||||
Tone Control - Switch
|
||||
Tone Control - Bass
|
||||
Tone Control - Treble
|
||||
3D Control - Switch
|
||||
3D Control - Center
|
||||
3D Control - Depth
|
||||
3D Control - Wide
|
||||
3D Control - Space
|
||||
3D Control - Level
|
||||
Mic Boost [(?dB)]
|
||||
===================================== =======================
|
||||
|
||||
PCM interface
|
||||
-------------
|
||||
|
||||
=================== ========================================
|
||||
Sample Clock Source { "Word", "Internal", "AutoSync" }
|
||||
Clock Sync Status { "Lock", "Sync", "No Lock" }
|
||||
External Rate external capture rate
|
||||
Capture Rate capture rate taken from external source
|
||||
=================== ========================================
|
||||
|
||||
IEC958 (S/PDIF) interface
|
||||
-------------------------
|
||||
|
||||
============================================ ======================================
|
||||
IEC958 [...] [Playback|Capture] Switch turn on/off the IEC958 interface
|
||||
IEC958 [...] [Playback|Capture] Volume digital volume control
|
||||
IEC958 [...] [Playback|Capture] Default default or global value - read/write
|
||||
IEC958 [...] [Playback|Capture] Mask consumer and professional mask
|
||||
IEC958 [...] [Playback|Capture] Con Mask consumer mask
|
||||
IEC958 [...] [Playback|Capture] Pro Mask professional mask
|
||||
IEC958 [...] [Playback|Capture] PCM Stream the settings assigned to a PCM stream
|
||||
IEC958 Q-subcode [Playback|Capture] Default Q-subcode bits
|
||||
|
||||
IEC958 Preamble [Playback|Capture] Default burst preamble words (4*16bits)
|
||||
============================================ ======================================
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
Designs and Implementations
|
||||
===========================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
control-names
|
||||
channel-mapping-api
|
||||
compress-offload
|
||||
timestamping
|
||||
jack-controls
|
||||
procfile
|
||||
powersave
|
||||
oss-emulation
|
||||
seq-oss
|
||||
|
|
@ -1,3 +1,7 @@
|
|||
==================
|
||||
ALSA Jack Controls
|
||||
==================
|
||||
|
||||
Why we need Jack kcontrols
|
||||
==========================
|
||||
|
||||
|
|
@ -29,11 +33,12 @@ How to use jack kcontrols
|
|||
=========================
|
||||
|
||||
In order to keep compatibility, snd_jack_new() has been modified by
|
||||
adding two params :-
|
||||
adding two params:
|
||||
|
||||
- @initial_kctl: if true, create a kcontrol and add it to the jack
|
||||
list.
|
||||
- @phantom_jack: Don't create a input device for phantom jacks.
|
||||
initial_kctl
|
||||
if true, create a kcontrol and add it to the jack list.
|
||||
phantom_jack
|
||||
Don't create a input device for phantom jacks.
|
||||
|
||||
HDA jacks can set phantom_jack to true in order to create a phantom
|
||||
jack and set initial_kctl to true to create an initial kcontrol with
|
||||
|
|
@ -1,7 +1,8 @@
|
|||
NOTES ON KERNEL OSS-EMULATION
|
||||
=============================
|
||||
=============================
|
||||
Notes on Kernel OSS-Emulation
|
||||
=============================
|
||||
|
||||
Jan. 22, 2004 Takashi Iwai <tiwai@suse.de>
|
||||
Jan. 22, 2004 Takashi Iwai <tiwai@suse.de>
|
||||
|
||||
|
||||
Modules
|
||||
|
|
@ -14,18 +15,18 @@ When you need to access the OSS PCM, mixer or sequencer devices, the
|
|||
corresponding module has to be loaded.
|
||||
|
||||
These modules are loaded automatically when the corresponding service
|
||||
is called. The alias is defined sound-service-x-y, where x and y are
|
||||
is called. The alias is defined ``sound-service-x-y``, where x and y are
|
||||
the card number and the minor unit number. Usually you don't have to
|
||||
define these aliases by yourself.
|
||||
|
||||
Only necessary step for auto-loading of OSS modules is to define the
|
||||
card alias in /etc/modprobe.d/alsa.conf, such as
|
||||
card alias in ``/etc/modprobe.d/alsa.conf``, such as::
|
||||
|
||||
alias sound-slot-0 snd-emu10k1
|
||||
|
||||
As the second card, define sound-slot-1 as well.
|
||||
As the second card, define ``sound-slot-1`` as well.
|
||||
Note that you can't use the aliased name as the target name (i.e.
|
||||
"alias sound-slot-0 snd-card-0" doesn't work any more like the old
|
||||
``alias sound-slot-0 snd-card-0`` doesn't work any more like the old
|
||||
modutils).
|
||||
|
||||
The currently available OSS configuration is shown in
|
||||
|
|
@ -42,6 +43,7 @@ Device Mapping
|
|||
==============
|
||||
|
||||
ALSA supports the following OSS device files:
|
||||
::
|
||||
|
||||
PCM:
|
||||
/dev/dspX
|
||||
|
|
@ -61,48 +63,55 @@ ALSA supports the following OSS device files:
|
|||
where X is the card number from 0 to 7.
|
||||
|
||||
(NOTE: Some distributions have the device files like /dev/midi0 and
|
||||
/dev/midi1. They are NOT for OSS but for tclmidi, which is
|
||||
a totally different thing.)
|
||||
/dev/midi1. They are NOT for OSS but for tclmidi, which is
|
||||
a totally different thing.)
|
||||
|
||||
Unlike the real OSS, ALSA cannot use the device files more than the
|
||||
assigned ones. For example, the first card cannot use /dev/dsp1 or
|
||||
/dev/dsp2, but only /dev/dsp0 and /dev/adsp0.
|
||||
|
||||
As seen above, PCM and MIDI may have two devices. Usually, the first
|
||||
PCM device (hw:0,0 in ALSA) is mapped to /dev/dsp and the secondary
|
||||
device (hw:0,1) to /dev/adsp (if available). For MIDI, /dev/midi and
|
||||
PCM device (``hw:0,0`` in ALSA) is mapped to /dev/dsp and the secondary
|
||||
device (``hw:0,1``) to /dev/adsp (if available). For MIDI, /dev/midi and
|
||||
/dev/amidi, respectively.
|
||||
|
||||
You can change this device mapping via the module options of
|
||||
snd-pcm-oss and snd-rawmidi. In the case of PCM, the following
|
||||
options are available for snd-pcm-oss:
|
||||
|
||||
dsp_map PCM device number assigned to /dev/dspX
|
||||
(default = 0)
|
||||
adsp_map PCM device number assigned to /dev/adspX
|
||||
(default = 1)
|
||||
dsp_map
|
||||
PCM device number assigned to /dev/dspX
|
||||
(default = 0)
|
||||
adsp_map
|
||||
PCM device number assigned to /dev/adspX
|
||||
(default = 1)
|
||||
|
||||
For example, to map the third PCM device (hw:0,2) to /dev/adsp0,
|
||||
For example, to map the third PCM device (``hw:0,2``) to /dev/adsp0,
|
||||
define like this:
|
||||
::
|
||||
|
||||
options snd-pcm-oss adsp_map=2
|
||||
|
||||
The options take arrays. For configuring the second card, specify
|
||||
two entries separated by comma. For example, to map the third PCM
|
||||
device on the second card to /dev/adsp1, define like below:
|
||||
::
|
||||
|
||||
options snd-pcm-oss adsp_map=0,2
|
||||
|
||||
To change the mapping of MIDI devices, the following options are
|
||||
available for snd-rawmidi:
|
||||
|
||||
midi_map MIDI device number assigned to /dev/midi0X
|
||||
(default = 0)
|
||||
amidi_map MIDI device number assigned to /dev/amidi0X
|
||||
(default = 1)
|
||||
midi_map
|
||||
MIDI device number assigned to /dev/midi0X
|
||||
(default = 0)
|
||||
amidi_map
|
||||
MIDI device number assigned to /dev/amidi0X
|
||||
(default = 1)
|
||||
|
||||
For example, to assign the third MIDI device on the first card to
|
||||
/dev/midi00, define as follows:
|
||||
::
|
||||
|
||||
options snd-rawmidi midi_map=2
|
||||
|
||||
|
|
@ -118,43 +127,52 @@ wine, especially if they use the card only in the MMAP mode.
|
|||
|
||||
In such a case, you can change the behavior of PCM per application by
|
||||
writing a command to the proc file. There is a proc file for each PCM
|
||||
stream, /proc/asound/cardX/pcmY[cp]/oss, where X is the card number
|
||||
(zero-based), Y the PCM device number (zero-based), and 'p' is for
|
||||
playback and 'c' for capture, respectively. Note that this proc file
|
||||
stream, ``/proc/asound/cardX/pcmY[cp]/oss``, where X is the card number
|
||||
(zero-based), Y the PCM device number (zero-based), and ``p`` is for
|
||||
playback and ``c`` for capture, respectively. Note that this proc file
|
||||
exists only after snd-pcm-oss module is loaded.
|
||||
|
||||
The command sequence has the following syntax:
|
||||
::
|
||||
|
||||
app_name fragments fragment_size [options]
|
||||
|
||||
app_name is the name of application with (higher priority) or without
|
||||
``app_name`` is the name of application with (higher priority) or without
|
||||
path.
|
||||
fragments specifies the number of fragments or zero if no specific
|
||||
``fragments`` specifies the number of fragments or zero if no specific
|
||||
number is given.
|
||||
fragment_size is the size of fragment in bytes or zero if not given.
|
||||
options is the optional parameters. The following options are
|
||||
``fragment_size`` is the size of fragment in bytes or zero if not given.
|
||||
``options`` is the optional parameters. The following options are
|
||||
available:
|
||||
|
||||
disable the application tries to open a pcm device for
|
||||
this channel but does not want to use it.
|
||||
direct don't use plugins
|
||||
block force block open mode
|
||||
non-block force non-block open mode
|
||||
partial-frag write also partial fragments (affects playback only)
|
||||
no-silence do not fill silence ahead to avoid clicks
|
||||
disable
|
||||
the application tries to open a pcm device for
|
||||
this channel but does not want to use it.
|
||||
direct
|
||||
don't use plugins
|
||||
block
|
||||
force block open mode
|
||||
non-block
|
||||
force non-block open mode
|
||||
partial-frag
|
||||
write also partial fragments (affects playback only)
|
||||
no-silence
|
||||
do not fill silence ahead to avoid clicks
|
||||
|
||||
The disable option is useful when one stream direction (playback or
|
||||
The ``disable`` option is useful when one stream direction (playback or
|
||||
capture) is not handled correctly by the application although the
|
||||
hardware itself does support both directions.
|
||||
The direct option is used, as mentioned above, to bypass the automatic
|
||||
The ``direct`` option is used, as mentioned above, to bypass the automatic
|
||||
conversion and useful for MMAP-applications.
|
||||
For example, to playback the first PCM device without plugins for
|
||||
quake, send a command via echo like the following:
|
||||
::
|
||||
|
||||
% echo "quake 0 0 direct" > /proc/asound/card0/pcm0p/oss
|
||||
|
||||
While quake wants only playback, you may append the second command
|
||||
to notify driver that only this direction is about to be allocated:
|
||||
::
|
||||
|
||||
% echo "quake 0 0 disable" > /proc/asound/card0/pcm0c/oss
|
||||
|
||||
|
|
@ -171,10 +189,11 @@ the file when it's busy. The -EBUSY error is returned in this case.
|
|||
This blocking behavior can be changed globally via nonblock_open
|
||||
module option of snd-pcm-oss. For using the blocking mode as default
|
||||
for OSS devices, define like the following:
|
||||
::
|
||||
|
||||
options snd-pcm-oss nonblock_open=0
|
||||
|
||||
The partial-frag and no-silence commands have been added recently.
|
||||
The ``partial-frag`` and ``no-silence`` commands have been added recently.
|
||||
Both commands are for optimization use only. The former command
|
||||
specifies to invoke the write transfer only when the whole fragment is
|
||||
filled. The latter stops writing the silence data ahead
|
||||
|
|
@ -183,15 +202,18 @@ automatically. Both are disabled as default.
|
|||
You can check the currently defined configuration by reading the proc
|
||||
file. The read image can be sent to the proc file again, hence you
|
||||
can save the current configuration
|
||||
::
|
||||
|
||||
% cat /proc/asound/card0/pcm0p/oss > /somewhere/oss-cfg
|
||||
|
||||
and restore it like
|
||||
::
|
||||
|
||||
% cat /somewhere/oss-cfg > /proc/asound/card0/pcm0p/oss
|
||||
|
||||
Also, for clearing all the current configuration, send "erase" command
|
||||
Also, for clearing all the current configuration, send ``erase`` command
|
||||
as below:
|
||||
::
|
||||
|
||||
% echo "erase" > /proc/asound/card0/pcm0p/oss
|
||||
|
||||
|
|
@ -211,40 +233,43 @@ automatically.
|
|||
|
||||
As default, ALSA uses the following control for OSS volumes:
|
||||
|
||||
OSS volume ALSA control Index
|
||||
-----------------------------------------------------
|
||||
SOUND_MIXER_VOLUME Master 0
|
||||
SOUND_MIXER_BASS Tone Control - Bass 0
|
||||
SOUND_MIXER_TREBLE Tone Control - Treble 0
|
||||
SOUND_MIXER_SYNTH Synth 0
|
||||
SOUND_MIXER_PCM PCM 0
|
||||
SOUND_MIXER_SPEAKER PC Speaker 0
|
||||
SOUND_MIXER_LINE Line 0
|
||||
SOUND_MIXER_MIC Mic 0
|
||||
SOUND_MIXER_CD CD 0
|
||||
SOUND_MIXER_IMIX Monitor Mix 0
|
||||
SOUND_MIXER_ALTPCM PCM 1
|
||||
SOUND_MIXER_RECLEV (not assigned)
|
||||
SOUND_MIXER_IGAIN Capture 0
|
||||
SOUND_MIXER_OGAIN Playback 0
|
||||
SOUND_MIXER_LINE1 Aux 0
|
||||
SOUND_MIXER_LINE2 Aux 1
|
||||
SOUND_MIXER_LINE3 Aux 2
|
||||
SOUND_MIXER_DIGITAL1 Digital 0
|
||||
SOUND_MIXER_DIGITAL2 Digital 1
|
||||
SOUND_MIXER_DIGITAL3 Digital 2
|
||||
SOUND_MIXER_PHONEIN Phone 0
|
||||
SOUND_MIXER_PHONEOUT Phone 1
|
||||
SOUND_MIXER_VIDEO Video 0
|
||||
SOUND_MIXER_RADIO Radio 0
|
||||
SOUND_MIXER_MONITOR Monitor 0
|
||||
==================== ===================== =====
|
||||
OSS volume ALSA control Index
|
||||
==================== ===================== =====
|
||||
SOUND_MIXER_VOLUME Master 0
|
||||
SOUND_MIXER_BASS Tone Control - Bass 0
|
||||
SOUND_MIXER_TREBLE Tone Control - Treble 0
|
||||
SOUND_MIXER_SYNTH Synth 0
|
||||
SOUND_MIXER_PCM PCM 0
|
||||
SOUND_MIXER_SPEAKER PC Speaker 0
|
||||
SOUND_MIXER_LINE Line 0
|
||||
SOUND_MIXER_MIC Mic 0
|
||||
SOUND_MIXER_CD CD 0
|
||||
SOUND_MIXER_IMIX Monitor Mix 0
|
||||
SOUND_MIXER_ALTPCM PCM 1
|
||||
SOUND_MIXER_RECLEV (not assigned)
|
||||
SOUND_MIXER_IGAIN Capture 0
|
||||
SOUND_MIXER_OGAIN Playback 0
|
||||
SOUND_MIXER_LINE1 Aux 0
|
||||
SOUND_MIXER_LINE2 Aux 1
|
||||
SOUND_MIXER_LINE3 Aux 2
|
||||
SOUND_MIXER_DIGITAL1 Digital 0
|
||||
SOUND_MIXER_DIGITAL2 Digital 1
|
||||
SOUND_MIXER_DIGITAL3 Digital 2
|
||||
SOUND_MIXER_PHONEIN Phone 0
|
||||
SOUND_MIXER_PHONEOUT Phone 1
|
||||
SOUND_MIXER_VIDEO Video 0
|
||||
SOUND_MIXER_RADIO Radio 0
|
||||
SOUND_MIXER_MONITOR Monitor 0
|
||||
==================== ===================== =====
|
||||
|
||||
The second column is the base-string of the corresponding ALSA
|
||||
control. In fact, the controls with "XXX [Playback|Capture]
|
||||
[Volume|Switch]" will be checked in addition.
|
||||
control. In fact, the controls with ``XXX [Playback|Capture]
|
||||
[Volume|Switch]`` will be checked in addition.
|
||||
|
||||
The current assignment of these mixer elements is listed in the proc
|
||||
file, /proc/asound/cardX/oss_mixer, which will be like the following
|
||||
::
|
||||
|
||||
VOLUME "Master" 0
|
||||
BASS "" 0
|
||||
|
|
@ -261,6 +286,7 @@ corresponding OSS control is not available.
|
|||
For changing the assignment, you can write the configuration to this
|
||||
proc file. For example, to map "Wave Playback" to the PCM volume,
|
||||
send the command like the following:
|
||||
::
|
||||
|
||||
% echo 'VOLUME "Wave Playback" 0' > /proc/asound/card0/oss_mixer
|
||||
|
||||
|
|
@ -284,12 +310,18 @@ Duplex Streams
|
|||
Note that when attempting to use a single device file for playback and
|
||||
capture, the OSS API provides no way to set the format, sample rate or
|
||||
number of channels different in each direction. Thus
|
||||
::
|
||||
|
||||
io_handle = open("device", O_RDWR)
|
||||
|
||||
will only function correctly if the values are the same in each direction.
|
||||
|
||||
To use different values in the two directions, use both
|
||||
::
|
||||
|
||||
input_handle = open("device", O_RDONLY)
|
||||
output_handle = open("device", O_WRONLY)
|
||||
|
||||
and set the values for the corresponding handle.
|
||||
|
||||
|
||||
|
|
@ -302,4 +334,3 @@ ICE1712 supports only the unconventional format, interleaved
|
|||
10-channels 24bit (packed in 32bit) format. Therefore you cannot mmap
|
||||
the buffer as the conventional (mono or 2-channels, 8 or 16bit) format
|
||||
on OSS.
|
||||
|
||||
|
|
@ -1,9 +1,10 @@
|
|||
==========================
|
||||
Notes on Power-Saving Mode
|
||||
==========================
|
||||
|
||||
AC97 and HD-audio drivers have the automatic power-saving mode.
|
||||
This feature is enabled via Kconfig CONFIG_SND_AC97_POWER_SAVE
|
||||
and CONFIG_SND_HDA_POWER_SAVE options, respectively.
|
||||
This feature is enabled via Kconfig ``CONFIG_SND_AC97_POWER_SAVE``
|
||||
and ``CONFIG_SND_HDA_POWER_SAVE`` options, respectively.
|
||||
|
||||
With the automatic power-saving, the driver turns off the codec power
|
||||
appropriately when no operation is required. When no applications use
|
||||
|
|
@ -11,20 +12,21 @@ the device and/or no analog loopback is set, the power disablement is
|
|||
done fully or partially. It'll save a certain power consumption, thus
|
||||
good for laptops (even for desktops).
|
||||
|
||||
The time-out for automatic power-off can be specified via power_save
|
||||
The time-out for automatic power-off can be specified via ``power_save``
|
||||
module option of snd-ac97-codec and snd-hda-intel modules. Specify
|
||||
the time-out value in seconds. 0 means to disable the automatic
|
||||
power-saving. The default value of timeout is given via
|
||||
CONFIG_SND_AC97_POWER_SAVE_DEFAULT and
|
||||
CONFIG_SND_HDA_POWER_SAVE_DEFAULT Kconfig options. Setting this to 1
|
||||
``CONFIG_SND_AC97_POWER_SAVE_DEFAULT`` and
|
||||
``CONFIG_SND_HDA_POWER_SAVE_DEFAULT`` Kconfig options. Setting this to 1
|
||||
(the minimum value) isn't recommended because many applications try to
|
||||
reopen the device frequently. 10 would be a good choice for normal
|
||||
operations.
|
||||
|
||||
The power_save option is exported as writable. This means you can
|
||||
The ``power_save`` option is exported as writable. This means you can
|
||||
adjust the value via sysfs on the fly. For example, to turn on the
|
||||
automatic power-save mode with 10 seconds, write to
|
||||
/sys/modules/snd_ac97_codec/parameters/power_save (usually as root):
|
||||
``/sys/modules/snd_ac97_codec/parameters/power_save`` (usually as root):
|
||||
::
|
||||
|
||||
# echo 10 > /sys/modules/snd_ac97_codec/parameters/power_save
|
||||
|
||||
|
|
@ -1,20 +1,22 @@
|
|||
Proc Files of ALSA Drivers
|
||||
==========================
|
||||
Takashi Iwai <tiwai@suse.de>
|
||||
==========================
|
||||
Proc Files of ALSA Drivers
|
||||
==========================
|
||||
|
||||
Takashi Iwai <tiwai@suse.de>
|
||||
|
||||
General
|
||||
-------
|
||||
=======
|
||||
|
||||
ALSA has its own proc tree, /proc/asound. Many useful information are
|
||||
found in this tree. When you encounter a problem and need debugging,
|
||||
check the files listed in the following sections.
|
||||
|
||||
Each card has its subtree cardX, where X is from 0 to 7. The
|
||||
card-specific files are stored in the card* subdirectories.
|
||||
card-specific files are stored in the ``card*`` subdirectories.
|
||||
|
||||
|
||||
Global Information
|
||||
------------------
|
||||
==================
|
||||
|
||||
cards
|
||||
Shows the list of currently configured ALSA drivers,
|
||||
|
|
@ -31,15 +33,15 @@ devices
|
|||
|
||||
meminfo
|
||||
Shows the status of allocated pages via ALSA drivers.
|
||||
Appears only when CONFIG_SND_DEBUG=y.
|
||||
Appears only when ``CONFIG_SND_DEBUG=y``.
|
||||
|
||||
hwdep
|
||||
Lists the currently available hwdep devices in format of
|
||||
<card>-<device>: <name>
|
||||
``<card>-<device>: <name>``
|
||||
|
||||
pcm
|
||||
Lists the currently available PCM devices in format of
|
||||
<card>-<device>: <id>: <name> : <sub-streams>
|
||||
``<card>-<device>: <id>: <name> : <sub-streams>``
|
||||
|
||||
timer
|
||||
Lists the currently available timer devices
|
||||
|
|
@ -54,23 +56,23 @@ oss/sndstat
|
|||
|
||||
|
||||
Card Specific Files
|
||||
-------------------
|
||||
===================
|
||||
|
||||
The card-specific files are found in /proc/asound/card* directories.
|
||||
The card-specific files are found in ``/proc/asound/card*`` directories.
|
||||
Some drivers (e.g. cmipci) have their own proc entries for the
|
||||
register dump, etc (e.g. /proc/asound/card*/cmipci shows the register
|
||||
register dump, etc (e.g. ``/proc/asound/card*/cmipci`` shows the register
|
||||
dump). These files would be really helpful for debugging.
|
||||
|
||||
When PCM devices are available on this card, you can see directories
|
||||
like pcm0p or pcm1c. They hold the PCM information for each PCM
|
||||
stream. The number after 'pcm' is the PCM device number from 0, and
|
||||
the last 'p' or 'c' means playback or capture direction. The files in
|
||||
stream. The number after ``pcm`` is the PCM device number from 0, and
|
||||
the last ``p`` or ``c`` means playback or capture direction. The files in
|
||||
this subtree is described later.
|
||||
|
||||
The status of MIDI I/O is found in midi* files. It shows the device
|
||||
The status of MIDI I/O is found in ``midi*`` files. It shows the device
|
||||
name and the received/transmitted bytes through the MIDI device.
|
||||
|
||||
When the card is equipped with AC97 codecs, there are codec97#*
|
||||
When the card is equipped with AC97 codecs, there are ``codec97#*``
|
||||
subdirectories (described later).
|
||||
|
||||
When the OSS mixer emulation is enabled (and the module is loaded),
|
||||
|
|
@ -81,26 +83,27 @@ details.
|
|||
|
||||
|
||||
PCM Proc Files
|
||||
--------------
|
||||
==============
|
||||
|
||||
card*/pcm*/info
|
||||
``card*/pcm*/info``
|
||||
The general information of this PCM device: card #, device #,
|
||||
substreams, etc.
|
||||
|
||||
card*/pcm*/xrun_debug
|
||||
This file appears when CONFIG_SND_DEBUG=y and
|
||||
CONFIG_PCM_XRUN_DEBUG=y.
|
||||
``card*/pcm*/xrun_debug``
|
||||
This file appears when ``CONFIG_SND_DEBUG=y`` and
|
||||
``CONFIG_PCM_XRUN_DEBUG=y``.
|
||||
This shows the status of xrun (= buffer overrun/xrun) and
|
||||
invalid PCM position debug/check of ALSA PCM middle layer.
|
||||
It takes an integer value, can be changed by writing to this
|
||||
file, such as
|
||||
file, such as::
|
||||
|
||||
# echo 5 > /proc/asound/card0/pcm0p/xrun_debug
|
||||
|
||||
The value consists of the following bit flags:
|
||||
bit 0 = Enable XRUN/jiffies debug messages
|
||||
bit 1 = Show stack trace at XRUN / jiffies check
|
||||
bit 2 = Enable additional jiffies check
|
||||
|
||||
* bit 0 = Enable XRUN/jiffies debug messages
|
||||
* bit 1 = Show stack trace at XRUN / jiffies check
|
||||
* bit 2 = Enable additional jiffies check
|
||||
|
||||
When the bit 0 is set, the driver will show the messages to
|
||||
kernel log when an xrun is detected. The debug message is
|
||||
|
|
@ -117,72 +120,74 @@ card*/pcm*/xrun_debug
|
|||
buggy) hardware that doesn't give smooth pointer updates.
|
||||
This feature is enabled via the bit 2.
|
||||
|
||||
card*/pcm*/sub*/info
|
||||
``card*/pcm*/sub*/info``
|
||||
The general information of this PCM sub-stream.
|
||||
|
||||
card*/pcm*/sub*/status
|
||||
``card*/pcm*/sub*/status``
|
||||
The current status of this PCM sub-stream, elapsed time,
|
||||
H/W position, etc.
|
||||
|
||||
card*/pcm*/sub*/hw_params
|
||||
``card*/pcm*/sub*/hw_params``
|
||||
The hardware parameters set for this sub-stream.
|
||||
|
||||
card*/pcm*/sub*/sw_params
|
||||
``card*/pcm*/sub*/sw_params``
|
||||
The soft parameters set for this sub-stream.
|
||||
|
||||
card*/pcm*/sub*/prealloc
|
||||
``card*/pcm*/sub*/prealloc``
|
||||
The buffer pre-allocation information.
|
||||
|
||||
card*/pcm*/sub*/xrun_injection
|
||||
``card*/pcm*/sub*/xrun_injection``
|
||||
Triggers an XRUN to the running stream when any value is
|
||||
written to this proc file. Used for fault injection.
|
||||
This entry is write-only.
|
||||
|
||||
AC97 Codec Information
|
||||
----------------------
|
||||
======================
|
||||
|
||||
card*/codec97#*/ac97#?-?
|
||||
``card*/codec97#*/ac97#?-?``
|
||||
Shows the general information of this AC97 codec chip, such as
|
||||
name, capabilities, set up.
|
||||
|
||||
card*/codec97#0/ac97#?-?+regs
|
||||
``card*/codec97#0/ac97#?-?+regs``
|
||||
Shows the AC97 register dump. Useful for debugging.
|
||||
|
||||
When CONFIG_SND_DEBUG is enabled, you can write to this file for
|
||||
changing an AC97 register directly. Pass two hex numbers.
|
||||
For example,
|
||||
|
||||
::
|
||||
|
||||
# echo 02 9f1f > /proc/asound/card0/codec97#0/ac97#0-0+regs
|
||||
|
||||
|
||||
USB Audio Streams
|
||||
-----------------
|
||||
=================
|
||||
|
||||
card*/stream*
|
||||
``card*/stream*``
|
||||
Shows the assignment and the current status of each audio stream
|
||||
of the given card. This information is very useful for debugging.
|
||||
|
||||
|
||||
HD-Audio Codecs
|
||||
---------------
|
||||
===============
|
||||
|
||||
card*/codec#*
|
||||
``card*/codec#*``
|
||||
Shows the general codec information and the attribute of each
|
||||
widget node.
|
||||
|
||||
card*/eld#*
|
||||
``card*/eld#*``
|
||||
Available for HDMI or DisplayPort interfaces.
|
||||
Shows ELD(EDID Like Data) info retrieved from the attached HDMI sink,
|
||||
and describes its audio capabilities and configurations.
|
||||
|
||||
Some ELD fields may be modified by doing `echo name hex_value > eld#*`.
|
||||
Some ELD fields may be modified by doing ``echo name hex_value > eld#*``.
|
||||
Only do this if you are sure the HDMI sink provided value is wrong.
|
||||
And if that makes your HDMI audio work, please report to us so that we
|
||||
can fix it in future kernel releases.
|
||||
|
||||
|
||||
Sequencer Information
|
||||
---------------------
|
||||
=====================
|
||||
|
||||
seq/drivers
|
||||
Lists the currently available ALSA sequencer drivers.
|
||||
|
|
@ -203,7 +208,7 @@ seq/oss
|
|||
|
||||
|
||||
Help For Debugging?
|
||||
-------------------
|
||||
===================
|
||||
|
||||
When the problem is related with PCM, first try to turn on xrun_debug
|
||||
mode. This will give you the kernel messages when and where xrun
|
||||
|
|
@ -211,24 +216,23 @@ happened.
|
|||
|
||||
If it's really a bug, report it with the following information:
|
||||
|
||||
- the name of the driver/card, show in /proc/asound/cards
|
||||
- the register dump, if available (e.g. card*/cmipci)
|
||||
- the name of the driver/card, show in ``/proc/asound/cards``
|
||||
- the register dump, if available (e.g. ``card*/cmipci``)
|
||||
|
||||
when it's a PCM problem,
|
||||
|
||||
- set-up of PCM, shown in hw_parms, sw_params, and status in the PCM
|
||||
sub-stream directory
|
||||
- set-up of PCM, shown in hw_parms, sw_params, and status in the PCM
|
||||
sub-stream directory
|
||||
|
||||
when it's a mixer problem,
|
||||
|
||||
- AC97 proc files, codec97#*/* files
|
||||
- AC97 proc files, ``codec97#*/*`` files
|
||||
|
||||
for USB audio/midi,
|
||||
|
||||
- output of lsusb -v
|
||||
- stream* files in card directory
|
||||
- output of ``lsusb -v``
|
||||
- ``stream*`` files in card directory
|
||||
|
||||
|
||||
The ALSA bug-tracking system is found at:
|
||||
|
||||
https://bugtrack.alsa-project.org/alsa-bug/
|
||||
https://bugtrack.alsa-project.org/alsa-bug/
|
||||
|
|
@ -0,0 +1,371 @@
|
|||
===============================
|
||||
OSS Sequencer Emulation on ALSA
|
||||
===============================
|
||||
|
||||
Copyright (c) 1998,1999 by Takashi Iwai
|
||||
|
||||
ver.0.1.8; Nov. 16, 1999
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
This directory contains the OSS sequencer emulation driver on ALSA. Note
|
||||
that this program is still in the development state.
|
||||
|
||||
What this does - it provides the emulation of the OSS sequencer, access
|
||||
via ``/dev/sequencer`` and ``/dev/music`` devices.
|
||||
The most of applications using OSS can run if the appropriate ALSA
|
||||
sequencer is prepared.
|
||||
|
||||
The following features are emulated by this driver:
|
||||
|
||||
* Normal sequencer and MIDI events:
|
||||
|
||||
They are converted to the ALSA sequencer events, and sent to the
|
||||
corresponding port.
|
||||
|
||||
* Timer events:
|
||||
|
||||
The timer is not selectable by ioctl. The control rate is fixed to
|
||||
100 regardless of HZ. That is, even on Alpha system, a tick is always
|
||||
1/100 second. The base rate and tempo can be changed in ``/dev/music``.
|
||||
|
||||
* Patch loading:
|
||||
|
||||
It purely depends on the synth drivers whether it's supported since
|
||||
the patch loading is realized by callback to the synth driver.
|
||||
|
||||
* I/O controls:
|
||||
|
||||
Most of controls are accepted. Some controls
|
||||
are dependent on the synth driver, as well as even on original OSS.
|
||||
|
||||
Furthermore, you can find the following advanced features:
|
||||
|
||||
* Better queue mechanism:
|
||||
|
||||
The events are queued before processing them.
|
||||
|
||||
* Multiple applications:
|
||||
|
||||
You can run two or more applications simultaneously (even for OSS
|
||||
sequencer)!
|
||||
However, each MIDI device is exclusive - that is, if a MIDI device
|
||||
is opened once by some application, other applications can't use
|
||||
it. No such a restriction in synth devices.
|
||||
|
||||
* Real-time event processing:
|
||||
|
||||
The events can be processed in real time without using out of bound
|
||||
ioctl. To switch to real-time mode, send ABSTIME 0 event. The followed
|
||||
events will be processed in real-time without queued. To switch off the
|
||||
real-time mode, send RELTIME 0 event.
|
||||
|
||||
* ``/proc`` interface:
|
||||
|
||||
The status of applications and devices can be shown via
|
||||
``/proc/asound/seq/oss`` at any time. In the later version,
|
||||
configuration will be changed via ``/proc`` interface, too.
|
||||
|
||||
|
||||
Installation
|
||||
============
|
||||
|
||||
Run configure script with both sequencer support (``--with-sequencer=yes``)
|
||||
and OSS emulation (``--with-oss=yes``) options. A module ``snd-seq-oss.o``
|
||||
will be created. If the synth module of your sound card supports for OSS
|
||||
emulation (so far, only Emu8000 driver), this module will be loaded
|
||||
automatically.
|
||||
Otherwise, you need to load this module manually.
|
||||
|
||||
At beginning, this module probes all the MIDI ports which have been
|
||||
already connected to the sequencer. Once after that, the creation and deletion
|
||||
of ports are watched by announcement mechanism of ALSA sequencer.
|
||||
|
||||
The available synth and MIDI devices can be found in proc interface.
|
||||
Run ``cat /proc/asound/seq/oss``, and check the devices. For example,
|
||||
if you use an AWE64 card, you'll see like the following:
|
||||
::
|
||||
|
||||
OSS sequencer emulation version 0.1.8
|
||||
ALSA client number 63
|
||||
ALSA receiver port 0
|
||||
|
||||
Number of applications: 0
|
||||
|
||||
Number of synth devices: 1
|
||||
synth 0: [EMU8000]
|
||||
type 0x1 : subtype 0x20 : voices 32
|
||||
capabilties : ioctl enabled / load_patch enabled
|
||||
|
||||
Number of MIDI devices: 3
|
||||
midi 0: [Emu8000 Port-0] ALSA port 65:0
|
||||
capability write / opened none
|
||||
|
||||
midi 1: [Emu8000 Port-1] ALSA port 65:1
|
||||
capability write / opened none
|
||||
|
||||
midi 2: [0: MPU-401 (UART)] ALSA port 64:0
|
||||
capability read/write / opened none
|
||||
|
||||
Note that the device number may be different from the information of
|
||||
``/proc/asound/oss-devices`` or ones of the original OSS driver.
|
||||
Use the device number listed in ``/proc/asound/seq/oss``
|
||||
to play via OSS sequencer emulation.
|
||||
|
||||
Using Synthesizer Devices
|
||||
=========================
|
||||
|
||||
Run your favorite program. I've tested playmidi-2.4, awemidi-0.4.3, gmod-3.1
|
||||
and xmp-1.1.5. You can load samples via ``/dev/sequencer`` like sfxload,
|
||||
too.
|
||||
|
||||
If the lowlevel driver supports multiple access to synth devices (like
|
||||
Emu8000 driver), two or more applications are allowed to run at the same
|
||||
time.
|
||||
|
||||
Using MIDI Devices
|
||||
==================
|
||||
|
||||
So far, only MIDI output was tested. MIDI input was not checked at all,
|
||||
but hopefully it will work. Use the device number listed in
|
||||
``/proc/asound/seq/oss``.
|
||||
Be aware that these numbers are mostly different from the list in
|
||||
``/proc/asound/oss-devices``.
|
||||
|
||||
Module Options
|
||||
==============
|
||||
|
||||
The following module options are available:
|
||||
|
||||
maxqlen
|
||||
specifies the maximum read/write queue length. This queue is private
|
||||
for OSS sequencer, so that it is independent from the queue length of ALSA
|
||||
sequencer. Default value is 1024.
|
||||
|
||||
seq_oss_debug
|
||||
specifies the debug level and accepts zero (= no debug message) or
|
||||
positive integer. Default value is 0.
|
||||
|
||||
Queue Mechanism
|
||||
===============
|
||||
|
||||
OSS sequencer emulation uses an ALSA priority queue. The
|
||||
events from ``/dev/sequencer`` are processed and put onto the queue
|
||||
specified by module option.
|
||||
|
||||
All the events from ``/dev/sequencer`` are parsed at beginning.
|
||||
The timing events are also parsed at this moment, so that the events may
|
||||
be processed in real-time. Sending an event ABSTIME 0 switches the operation
|
||||
mode to real-time mode, and sending an event RELTIME 0 switches it off.
|
||||
In the real-time mode, all events are dispatched immediately.
|
||||
|
||||
The queued events are dispatched to the corresponding ALSA sequencer
|
||||
ports after scheduled time by ALSA sequencer dispatcher.
|
||||
|
||||
If the write-queue is full, the application sleeps until a certain amount
|
||||
(as default one half) becomes empty in blocking mode. The synchronization
|
||||
to write timing was implemented, too.
|
||||
|
||||
The input from MIDI devices or echo-back events are stored on read FIFO
|
||||
queue. If application reads ``/dev/sequencer`` in blocking mode, the
|
||||
process will be awaked.
|
||||
|
||||
Interface to Synthesizer Device
|
||||
===============================
|
||||
|
||||
Registration
|
||||
------------
|
||||
|
||||
To register an OSS synthesizer device, use snd_seq_oss_synth_register()
|
||||
function:
|
||||
::
|
||||
|
||||
int snd_seq_oss_synth_register(char *name, int type, int subtype, int nvoices,
|
||||
snd_seq_oss_callback_t *oper, void *private_data)
|
||||
|
||||
The arguments ``name``, ``type``, ``subtype`` and ``nvoices``
|
||||
are used for making the appropriate synth_info structure for ioctl. The
|
||||
return value is an index number of this device. This index must be remembered
|
||||
for unregister. If registration is failed, -errno will be returned.
|
||||
|
||||
To release this device, call snd_seq_oss_synth_unregister() function:
|
||||
::
|
||||
|
||||
int snd_seq_oss_synth_unregister(int index)
|
||||
|
||||
where the ``index`` is the index number returned by register function.
|
||||
|
||||
Callbacks
|
||||
---------
|
||||
|
||||
OSS synthesizer devices have capability for sample downloading and ioctls
|
||||
like sample reset. In OSS emulation, these special features are realized
|
||||
by using callbacks. The registration argument oper is used to specify these
|
||||
callbacks. The following callback functions must be defined:
|
||||
::
|
||||
|
||||
snd_seq_oss_callback_t:
|
||||
int (*open)(snd_seq_oss_arg_t *p, void *closure);
|
||||
int (*close)(snd_seq_oss_arg_t *p);
|
||||
int (*ioctl)(snd_seq_oss_arg_t *p, unsigned int cmd, unsigned long arg);
|
||||
int (*load_patch)(snd_seq_oss_arg_t *p, int format, const char *buf, int offs, int count);
|
||||
int (*reset)(snd_seq_oss_arg_t *p);
|
||||
|
||||
Except for ``open`` and ``close`` callbacks, they are allowed to be NULL.
|
||||
|
||||
Each callback function takes the argument type ``snd_seq_oss_arg_t`` as the
|
||||
first argument.
|
||||
::
|
||||
|
||||
struct snd_seq_oss_arg_t {
|
||||
int app_index;
|
||||
int file_mode;
|
||||
int seq_mode;
|
||||
snd_seq_addr_t addr;
|
||||
void *private_data;
|
||||
int event_passing;
|
||||
};
|
||||
|
||||
The first three fields, ``app_index``, ``file_mode`` and ``seq_mode``
|
||||
are initialized by OSS sequencer. The ``app_index`` is the application
|
||||
index which is unique to each application opening OSS sequencer. The
|
||||
``file_mode`` is bit-flags indicating the file operation mode. See
|
||||
``seq_oss.h`` for its meaning. The ``seq_mode`` is sequencer operation
|
||||
mode. In the current version, only ``SND_OSSSEQ_MODE_SYNTH`` is used.
|
||||
|
||||
The next two fields, ``addr`` and ``private_data``, must be
|
||||
filled by the synth driver at open callback. The ``addr`` contains
|
||||
the address of ALSA sequencer port which is assigned to this device. If
|
||||
the driver allocates memory for ``private_data``, it must be released
|
||||
in close callback by itself.
|
||||
|
||||
The last field, ``event_passing``, indicates how to translate note-on
|
||||
/ off events. In ``PROCESS_EVENTS`` mode, the note 255 is regarded
|
||||
as velocity change, and key pressure event is passed to the port. In
|
||||
``PASS_EVENTS`` mode, all note on/off events are passed to the port
|
||||
without modified. ``PROCESS_KEYPRESS`` mode checks the note above 128
|
||||
and regards it as key pressure event (mainly for Emu8000 driver).
|
||||
|
||||
Open Callback
|
||||
-------------
|
||||
|
||||
The ``open`` is called at each time this device is opened by an application
|
||||
using OSS sequencer. This must not be NULL. Typically, the open callback
|
||||
does the following procedure:
|
||||
|
||||
#. Allocate private data record.
|
||||
#. Create an ALSA sequencer port.
|
||||
#. Set the new port address on ``arg->addr``.
|
||||
#. Set the private data record pointer on ``arg->private_data``.
|
||||
|
||||
Note that the type bit-flags in port_info of this synth port must NOT contain
|
||||
``TYPE_MIDI_GENERIC``
|
||||
bit. Instead, ``TYPE_SPECIFIC`` should be used. Also, ``CAP_SUBSCRIPTION``
|
||||
bit should NOT be included, too. This is necessary to tell it from other
|
||||
normal MIDI devices. If the open procedure succeeded, return zero. Otherwise,
|
||||
return -errno.
|
||||
|
||||
Ioctl Callback
|
||||
--------------
|
||||
|
||||
The ``ioctl`` callback is called when the sequencer receives device-specific
|
||||
ioctls. The following two ioctls should be processed by this callback:
|
||||
|
||||
IOCTL_SEQ_RESET_SAMPLES
|
||||
reset all samples on memory -- return 0
|
||||
|
||||
IOCTL_SYNTH_MEMAVL
|
||||
return the available memory size
|
||||
|
||||
FM_4OP_ENABLE
|
||||
can be ignored usually
|
||||
|
||||
The other ioctls are processed inside the sequencer without passing to
|
||||
the lowlevel driver.
|
||||
|
||||
Load_Patch Callback
|
||||
-------------------
|
||||
|
||||
The ``load_patch`` callback is used for sample-downloading. This callback
|
||||
must read the data on user-space and transfer to each device. Return 0
|
||||
if succeeded, and -errno if failed. The format argument is the patch key
|
||||
in patch_info record. The buf is user-space pointer where patch_info record
|
||||
is stored. The offs can be ignored. The count is total data size of this
|
||||
sample data.
|
||||
|
||||
Close Callback
|
||||
--------------
|
||||
|
||||
The ``close`` callback is called when this device is closed by the
|
||||
application. If any private data was allocated in open callback, it must
|
||||
be released in the close callback. The deletion of ALSA port should be
|
||||
done here, too. This callback must not be NULL.
|
||||
|
||||
Reset Callback
|
||||
--------------
|
||||
|
||||
The ``reset`` callback is called when sequencer device is reset or
|
||||
closed by applications. The callback should turn off the sounds on the
|
||||
relevant port immediately, and initialize the status of the port. If this
|
||||
callback is undefined, OSS seq sends a ``HEARTBEAT`` event to the
|
||||
port.
|
||||
|
||||
Events
|
||||
======
|
||||
|
||||
Most of the events are processed by sequencer and translated to the adequate
|
||||
ALSA sequencer events, so that each synth device can receive by input_event
|
||||
callback of ALSA sequencer port. The following ALSA events should be
|
||||
implemented by the driver:
|
||||
|
||||
============= ===================
|
||||
ALSA event Original OSS events
|
||||
============= ===================
|
||||
NOTEON SEQ_NOTEON, MIDI_NOTEON
|
||||
NOTE SEQ_NOTEOFF, MIDI_NOTEOFF
|
||||
KEYPRESS MIDI_KEY_PRESSURE
|
||||
CHANPRESS SEQ_AFTERTOUCH, MIDI_CHN_PRESSURE
|
||||
PGMCHANGE SEQ_PGMCHANGE, MIDI_PGM_CHANGE
|
||||
PITCHBEND SEQ_CONTROLLER(CTRL_PITCH_BENDER),
|
||||
MIDI_PITCH_BEND
|
||||
CONTROLLER MIDI_CTL_CHANGE,
|
||||
SEQ_BALANCE (with CTL_PAN)
|
||||
CONTROL14 SEQ_CONTROLLER
|
||||
REGPARAM SEQ_CONTROLLER(CTRL_PITCH_BENDER_RANGE)
|
||||
SYSEX SEQ_SYSEX
|
||||
============= ===================
|
||||
|
||||
The most of these behavior can be realized by MIDI emulation driver
|
||||
included in the Emu8000 lowlevel driver. In the future release, this module
|
||||
will be independent.
|
||||
|
||||
Some OSS events (``SEQ_PRIVATE`` and ``SEQ_VOLUME`` events) are passed as event
|
||||
type SND_SEQ_OSS_PRIVATE. The OSS sequencer passes these event 8 byte
|
||||
packets without any modification. The lowlevel driver should process these
|
||||
events appropriately.
|
||||
|
||||
Interface to MIDI Device
|
||||
========================
|
||||
|
||||
Since the OSS emulation probes the creation and deletion of ALSA MIDI
|
||||
sequencer ports automatically by receiving announcement from ALSA
|
||||
sequencer, the MIDI devices don't need to be registered explicitly
|
||||
like synth devices.
|
||||
However, the MIDI port_info registered to ALSA sequencer must include
|
||||
a group name ``SND_SEQ_GROUP_DEVICE`` and a capability-bit
|
||||
``CAP_READ`` or ``CAP_WRITE``. Also, subscription capabilities,
|
||||
``CAP_SUBS_READ`` or ``CAP_SUBS_WRITE``, must be defined, too. If
|
||||
these conditions are not satisfied, the port is not registered as OSS
|
||||
sequencer MIDI device.
|
||||
|
||||
The events via MIDI devices are parsed in OSS sequencer and converted
|
||||
to the corresponding ALSA sequencer events. The input from MIDI sequencer
|
||||
is also converted to MIDI byte events by OSS sequencer. This works just
|
||||
a reverse way of seq_midi module.
|
||||
|
||||
Known Problems / TODO's
|
||||
=======================
|
||||
|
||||
* Patch loading via ALSA instrument layer is not implemented yet.
|
||||
|
||||
|
|
@ -1,18 +1,22 @@
|
|||
=====================
|
||||
ALSA PCM Timestamping
|
||||
=====================
|
||||
|
||||
The ALSA API can provide two different system timestamps:
|
||||
|
||||
- Trigger_tstamp is the system time snapshot taken when the .trigger
|
||||
callback is invoked. This snapshot is taken by the ALSA core in the
|
||||
general case, but specific hardware may have synchronization
|
||||
capabilities or conversely may only be able to provide a correct
|
||||
estimate with a delay. In the latter two cases, the low-level driver
|
||||
is responsible for updating the trigger_tstamp at the most appropriate
|
||||
and precise moment. Applications should not rely solely on the first
|
||||
trigger_tstamp but update their internal calculations if the driver
|
||||
provides a refined estimate with a delay.
|
||||
callback is invoked. This snapshot is taken by the ALSA core in the
|
||||
general case, but specific hardware may have synchronization
|
||||
capabilities or conversely may only be able to provide a correct
|
||||
estimate with a delay. In the latter two cases, the low-level driver
|
||||
is responsible for updating the trigger_tstamp at the most appropriate
|
||||
and precise moment. Applications should not rely solely on the first
|
||||
trigger_tstamp but update their internal calculations if the driver
|
||||
provides a refined estimate with a delay.
|
||||
|
||||
- tstamp is the current system timestamp updated during the last
|
||||
event or application query.
|
||||
The difference (tstamp - trigger_tstamp) defines the elapsed time.
|
||||
event or application query.
|
||||
The difference (tstamp - trigger_tstamp) defines the elapsed time.
|
||||
|
||||
The ALSA API provides two basic pieces of information, avail
|
||||
and delay, which combined with the trigger and current system
|
||||
|
|
@ -22,15 +26,15 @@ the ring buffer and the amount of queued samples.
|
|||
The use of these different pointers and time information depends on
|
||||
the application needs:
|
||||
|
||||
- 'avail' reports how much can be written in the ring buffer
|
||||
- 'delay' reports the time it will take to hear a new sample after all
|
||||
queued samples have been played out.
|
||||
- ``avail`` reports how much can be written in the ring buffer
|
||||
- ``delay`` reports the time it will take to hear a new sample after all
|
||||
queued samples have been played out.
|
||||
|
||||
When timestamps are enabled, the avail/delay information is reported
|
||||
along with a snapshot of system time. Applications can select from
|
||||
CLOCK_REALTIME (NTP corrections including going backwards),
|
||||
CLOCK_MONOTONIC (NTP corrections but never going backwards),
|
||||
CLOCK_MONOTIC_RAW (without NTP corrections) and change the mode
|
||||
``CLOCK_REALTIME`` (NTP corrections including going backwards),
|
||||
``CLOCK_MONOTONIC`` (NTP corrections but never going backwards),
|
||||
``CLOCK_MONOTIC_RAW`` (without NTP corrections) and change the mode
|
||||
dynamically with sw_params
|
||||
|
||||
|
||||
|
|
@ -38,17 +42,18 @@ The ALSA API also provide an audio_tstamp which reflects the passage
|
|||
of time as measured by different components of audio hardware. In
|
||||
ascii-art, this could be represented as follows (for the playback
|
||||
case):
|
||||
::
|
||||
|
||||
--------------------------------------------------------------> time
|
||||
^ ^ ^ ^ ^
|
||||
| | | | |
|
||||
analog link dma app FullBuffer
|
||||
time time time time time
|
||||
| | | | |
|
||||
|< codec delay >|<--hw delay-->|<queued samples>|<---avail->|
|
||||
|<----------------- delay---------------------->| |
|
||||
|<----ring buffer length---->|
|
||||
|
||||
--------------------------------------------------------------> time
|
||||
^ ^ ^ ^ ^
|
||||
| | | | |
|
||||
analog link dma app FullBuffer
|
||||
time time time time time
|
||||
| | | | |
|
||||
|< codec delay >|<--hw delay-->|<queued samples>|<---avail->|
|
||||
|<----------------- delay---------------------->| |
|
||||
|<----ring buffer length---->|
|
||||
|
||||
The analog time is taken at the last stage of the playback, as close
|
||||
as possible to the actual transducer
|
||||
|
|
@ -113,11 +118,11 @@ audio applications...
|
|||
|
||||
Due to the varied nature of timestamping needs, even for a single
|
||||
application, the audio_tstamp_config can be changed dynamically. In
|
||||
the STATUS ioctl, the parameters are read-only and do not allow for
|
||||
the ``STATUS`` ioctl, the parameters are read-only and do not allow for
|
||||
any application selection. To work around this limitation without
|
||||
impacting legacy applications, a new STATUS_EXT ioctl is introduced
|
||||
impacting legacy applications, a new ``STATUS_EXT`` ioctl is introduced
|
||||
with read/write parameters. ALSA-lib will be modified to make use of
|
||||
STATUS_EXT and effectively deprecate STATUS.
|
||||
``STATUS_EXT`` and effectively deprecate ``STATUS``.
|
||||
|
||||
The ALSA API only allows for a single audio timestamp to be reported
|
||||
at a time. This is a conscious design decision, reading the audio
|
||||
|
|
@ -135,36 +140,42 @@ the hardware, there is a risk of misalignment with the avail and delay
|
|||
information. To make sure applications are not confused, a
|
||||
driver_timestamp field is added in the snd_pcm_status structure; this
|
||||
timestamp shows when the information is put together by the driver
|
||||
before returning from the STATUS and STATUS_EXT ioctl. in most cases
|
||||
before returning from the ``STATUS`` and ``STATUS_EXT`` ioctl. in most cases
|
||||
this driver_timestamp will be identical to the regular system tstamp.
|
||||
|
||||
Examples of typestamping with HDaudio:
|
||||
|
||||
1. DMA timestamp, no compensation for DMA+analog delay
|
||||
$ ./audio_time -p --ts_type=1
|
||||
playback: systime: 341121338 nsec, audio time 342000000 nsec, systime delta -878662
|
||||
playback: systime: 426236663 nsec, audio time 427187500 nsec, systime delta -950837
|
||||
playback: systime: 597080580 nsec, audio time 598000000 nsec, systime delta -919420
|
||||
playback: systime: 682059782 nsec, audio time 683020833 nsec, systime delta -961051
|
||||
playback: systime: 852896415 nsec, audio time 853854166 nsec, systime delta -957751
|
||||
playback: systime: 937903344 nsec, audio time 938854166 nsec, systime delta -950822
|
||||
::
|
||||
|
||||
$ ./audio_time -p --ts_type=1
|
||||
playback: systime: 341121338 nsec, audio time 342000000 nsec, systime delta -878662
|
||||
playback: systime: 426236663 nsec, audio time 427187500 nsec, systime delta -950837
|
||||
playback: systime: 597080580 nsec, audio time 598000000 nsec, systime delta -919420
|
||||
playback: systime: 682059782 nsec, audio time 683020833 nsec, systime delta -961051
|
||||
playback: systime: 852896415 nsec, audio time 853854166 nsec, systime delta -957751
|
||||
playback: systime: 937903344 nsec, audio time 938854166 nsec, systime delta -950822
|
||||
|
||||
2. DMA timestamp, compensation for DMA+analog delay
|
||||
$ ./audio_time -p --ts_type=1 -d
|
||||
playback: systime: 341053347 nsec, audio time 341062500 nsec, systime delta -9153
|
||||
playback: systime: 426072447 nsec, audio time 426062500 nsec, systime delta 9947
|
||||
playback: systime: 596899518 nsec, audio time 596895833 nsec, systime delta 3685
|
||||
playback: systime: 681915317 nsec, audio time 681916666 nsec, systime delta -1349
|
||||
playback: systime: 852741306 nsec, audio time 852750000 nsec, systime delta -8694
|
||||
::
|
||||
|
||||
$ ./audio_time -p --ts_type=1 -d
|
||||
playback: systime: 341053347 nsec, audio time 341062500 nsec, systime delta -9153
|
||||
playback: systime: 426072447 nsec, audio time 426062500 nsec, systime delta 9947
|
||||
playback: systime: 596899518 nsec, audio time 596895833 nsec, systime delta 3685
|
||||
playback: systime: 681915317 nsec, audio time 681916666 nsec, systime delta -1349
|
||||
playback: systime: 852741306 nsec, audio time 852750000 nsec, systime delta -8694
|
||||
|
||||
3. link timestamp, compensation for DMA+analog delay
|
||||
$ ./audio_time -p --ts_type=2 -d
|
||||
playback: systime: 341060004 nsec, audio time 341062791 nsec, systime delta -2787
|
||||
playback: systime: 426242074 nsec, audio time 426244875 nsec, systime delta -2801
|
||||
playback: systime: 597080992 nsec, audio time 597084583 nsec, systime delta -3591
|
||||
playback: systime: 682084512 nsec, audio time 682088291 nsec, systime delta -3779
|
||||
playback: systime: 852936229 nsec, audio time 852940916 nsec, systime delta -4687
|
||||
playback: systime: 938107562 nsec, audio time 938112708 nsec, systime delta -5146
|
||||
::
|
||||
|
||||
$ ./audio_time -p --ts_type=2 -d
|
||||
playback: systime: 341060004 nsec, audio time 341062791 nsec, systime delta -2787
|
||||
playback: systime: 426242074 nsec, audio time 426244875 nsec, systime delta -2801
|
||||
playback: systime: 597080992 nsec, audio time 597084583 nsec, systime delta -3591
|
||||
playback: systime: 682084512 nsec, audio time 682088291 nsec, systime delta -3779
|
||||
playback: systime: 852936229 nsec, audio time 852940916 nsec, systime delta -4687
|
||||
playback: systime: 938107562 nsec, audio time 938112708 nsec, systime delta -5146
|
||||
|
||||
Example 1 shows that the timestamp at the DMA level is close to 1ms
|
||||
ahead of the actual playback time (as a side time this sort of
|
||||
|
|
@ -181,20 +192,24 @@ shows how compensating for the delay exposes a 1ms accuracy (due to
|
|||
the use of the frame counter by the driver)
|
||||
|
||||
Example 3: DMA timestamp, no compensation for delay, delta of ~5ms
|
||||
$ ./audio_time -p -Dhw:1 -t1
|
||||
playback: systime: 120174019 nsec, audio time 125000000 nsec, systime delta -4825981
|
||||
playback: systime: 245041136 nsec, audio time 250000000 nsec, systime delta -4958864
|
||||
playback: systime: 370106088 nsec, audio time 375000000 nsec, systime delta -4893912
|
||||
playback: systime: 495040065 nsec, audio time 500000000 nsec, systime delta -4959935
|
||||
playback: systime: 620038179 nsec, audio time 625000000 nsec, systime delta -4961821
|
||||
playback: systime: 745087741 nsec, audio time 750000000 nsec, systime delta -4912259
|
||||
playback: systime: 870037336 nsec, audio time 875000000 nsec, systime delta -4962664
|
||||
::
|
||||
|
||||
$ ./audio_time -p -Dhw:1 -t1
|
||||
playback: systime: 120174019 nsec, audio time 125000000 nsec, systime delta -4825981
|
||||
playback: systime: 245041136 nsec, audio time 250000000 nsec, systime delta -4958864
|
||||
playback: systime: 370106088 nsec, audio time 375000000 nsec, systime delta -4893912
|
||||
playback: systime: 495040065 nsec, audio time 500000000 nsec, systime delta -4959935
|
||||
playback: systime: 620038179 nsec, audio time 625000000 nsec, systime delta -4961821
|
||||
playback: systime: 745087741 nsec, audio time 750000000 nsec, systime delta -4912259
|
||||
playback: systime: 870037336 nsec, audio time 875000000 nsec, systime delta -4962664
|
||||
|
||||
Example 4: DMA timestamp, compensation for delay, delay of ~1ms
|
||||
$ ./audio_time -p -Dhw:1 -t1 -d
|
||||
playback: systime: 120190520 nsec, audio time 120000000 nsec, systime delta 190520
|
||||
playback: systime: 245036740 nsec, audio time 244000000 nsec, systime delta 1036740
|
||||
playback: systime: 370034081 nsec, audio time 369000000 nsec, systime delta 1034081
|
||||
playback: systime: 495159907 nsec, audio time 494000000 nsec, systime delta 1159907
|
||||
playback: systime: 620098824 nsec, audio time 619000000 nsec, systime delta 1098824
|
||||
playback: systime: 745031847 nsec, audio time 744000000 nsec, systime delta 1031847
|
||||
::
|
||||
|
||||
$ ./audio_time -p -Dhw:1 -t1 -d
|
||||
playback: systime: 120190520 nsec, audio time 120000000 nsec, systime delta 190520
|
||||
playback: systime: 245036740 nsec, audio time 244000000 nsec, systime delta 1036740
|
||||
playback: systime: 370034081 nsec, audio time 369000000 nsec, systime delta 1034081
|
||||
playback: systime: 495159907 nsec, audio time 494000000 nsec, systime delta 1159907
|
||||
playback: systime: 620098824 nsec, audio time 619000000 nsec, systime delta 1098824
|
||||
playback: systime: 745031847 nsec, audio time 744000000 nsec, systime delta 1031847
|
||||
|
|
@ -1,16 +1,21 @@
|
|||
======================================
|
||||
HD-Audio Codec-Specific Mixer Controls
|
||||
======================================
|
||||
|
||||
|
||||
This file explains the codec-specific mixer controls.
|
||||
|
||||
Realtek codecs
|
||||
--------------
|
||||
|
||||
* Channel Mode
|
||||
Channel Mode
|
||||
This is an enum control to change the surround-channel setup,
|
||||
appears only when the surround channels are available.
|
||||
It gives the number of channels to be used, "2ch", "4ch", "6ch",
|
||||
and "8ch". According to the configuration, this also controls the
|
||||
jack-retasking of multi-I/O jacks.
|
||||
|
||||
* Auto-Mute Mode
|
||||
Auto-Mute Mode
|
||||
This is an enum control to change the auto-mute behavior of the
|
||||
headphone and line-out jacks. If built-in speakers and headphone
|
||||
and/or line-out jacks are available on a machine, this controls
|
||||
|
|
@ -30,24 +35,24 @@ Realtek codecs
|
|||
IDT/Sigmatel codecs
|
||||
-------------------
|
||||
|
||||
* Analog Loopback
|
||||
Analog Loopback
|
||||
This control enables/disables the analog-loopback circuit. This
|
||||
appears only when "loopback" is set to true in a codec hint
|
||||
(see HD-Audio.txt). Note that on some codecs the analog-loopback
|
||||
and the normal PCM playback are exclusive, i.e. when this is on, you
|
||||
won't hear any PCM stream.
|
||||
|
||||
* Swap Center/LFE
|
||||
Swap Center/LFE
|
||||
Swaps the center and LFE channel order. Normally, the left
|
||||
corresponds to the center and the right to the LFE. When this is
|
||||
ON, the left to the LFE and the right to the center.
|
||||
|
||||
* Headphone as Line Out
|
||||
Headphone as Line Out
|
||||
When this control is ON, treat the headphone jacks as line-out
|
||||
jacks. That is, the headphone won't auto-mute the other line-outs,
|
||||
and no HP-amp is set to the pins.
|
||||
|
||||
* Mic Jack Mode, Line Jack Mode, etc
|
||||
Mic Jack Mode, Line Jack Mode, etc
|
||||
These enum controls the direction and the bias of the input jack
|
||||
pins. Depending on the jack type, it can set as "Mic In" and "Line
|
||||
In", for determining the input bias, or it can be set to "Line Out"
|
||||
|
|
@ -57,19 +62,19 @@ IDT/Sigmatel codecs
|
|||
VIA codecs
|
||||
----------
|
||||
|
||||
* Smart 5.1
|
||||
Smart 5.1
|
||||
An enum control to re-task the multi-I/O jacks for surround outputs.
|
||||
When it's ON, the corresponding input jacks (usually a line-in and a
|
||||
mic-in) are switched as the surround and the CLFE output jacks.
|
||||
|
||||
* Independent HP
|
||||
Independent HP
|
||||
When this enum control is enabled, the headphone output is routed
|
||||
from an individual stream (the third PCM such as hw:0,2) instead of
|
||||
the primary stream. In the case the headphone DAC is shared with a
|
||||
side or a CLFE-channel DAC, the DAC is switched to the headphone
|
||||
automatically.
|
||||
|
||||
* Loopback Mixing
|
||||
Loopback Mixing
|
||||
An enum control to determine whether the analog-loopback route is
|
||||
enabled or not. When it's enabled, the analog-loopback is mixed to
|
||||
the front-channel. Also, the same route is used for the headphone
|
||||
|
|
@ -78,7 +83,7 @@ VIA codecs
|
|||
headphones and speakers because there is only one DAC connected to a
|
||||
mixer widget.
|
||||
|
||||
* Dynamic Power-Control
|
||||
Dynamic Power-Control
|
||||
This control determines whether the dynamic power-control per jack
|
||||
detection is enabled or not. When enabled, the widgets power state
|
||||
(D0/D3) are changed dynamically depending on the jack plugging
|
||||
|
|
@ -86,7 +91,7 @@ VIA codecs
|
|||
doesn't provide a proper jack-detection, this won't work; in such a
|
||||
case, turn this control OFF.
|
||||
|
||||
* Jack Detect
|
||||
Jack Detect
|
||||
This control is provided only for VT1708 codec which gives no proper
|
||||
unsolicited event per jack plug. When this is on, the driver polls
|
||||
the jack detection so that the headphone auto-mute can work, while
|
||||
|
|
@ -96,21 +101,21 @@ VIA codecs
|
|||
Conexant codecs
|
||||
---------------
|
||||
|
||||
* Auto-Mute Mode
|
||||
Auto-Mute Mode
|
||||
See Reatek codecs.
|
||||
|
||||
|
||||
Analog codecs
|
||||
--------------
|
||||
|
||||
* Channel Mode
|
||||
Channel Mode
|
||||
This is an enum control to change the surround-channel setup,
|
||||
appears only when the surround channels are available.
|
||||
It gives the number of channels to be used, "2ch", "4ch" and "6ch".
|
||||
According to the configuration, this also controls the
|
||||
jack-retasking of multi-I/O jacks.
|
||||
|
||||
* Independent HP
|
||||
Independent HP
|
||||
When this enum control is enabled, the headphone output is routed
|
||||
from an individual stream (the third PCM such as hw:0,2) instead of
|
||||
the primary stream.
|
||||
|
|
@ -1,3 +1,7 @@
|
|||
=======================
|
||||
HD-Audio DP-MST Support
|
||||
=======================
|
||||
|
||||
To support DP MST audio, HD Audio hdmi codec driver introduces virtual pin
|
||||
and dynamic pcm assignment.
|
||||
|
||||
|
|
@ -44,10 +48,12 @@ Build Jack
|
|||
----------
|
||||
|
||||
- dyn_pcm_assign
|
||||
Will not use hda_jack but use snd_jack in spec->pcm_rec[pcm_idx].jack directly.
|
||||
|
||||
Will not use hda_jack but use snd_jack in spec->pcm_rec[pcm_idx].jack directly.
|
||||
|
||||
- !dyn_pcm_assign
|
||||
Use hda_jack and assign spec->pcm_rec[pcm_idx].jack = jack->jack statically.
|
||||
|
||||
Use hda_jack and assign spec->pcm_rec[pcm_idx].jack = jack->jack statically.
|
||||
|
||||
|
||||
Unsolicited Event Enabling
|
||||
|
|
@ -58,16 +64,20 @@ Enable unsolicited event if !acomp.
|
|||
Monitor Hotplug Event Handling
|
||||
------------------------------
|
||||
- acomp
|
||||
pin_eld_notify() -> check_presence_and_report() -> hdmi_present_sense() ->
|
||||
sync_eld_via_acomp().
|
||||
Use directly snd_jack_report() on spec->pcm_rec[pcm_idx].jack for
|
||||
both dyn_pcm_assign and !dyn_pcm_assign
|
||||
|
||||
pin_eld_notify() -> check_presence_and_report() -> hdmi_present_sense() ->
|
||||
sync_eld_via_acomp().
|
||||
|
||||
Use directly snd_jack_report() on spec->pcm_rec[pcm_idx].jack for
|
||||
both dyn_pcm_assign and !dyn_pcm_assign
|
||||
|
||||
- !acomp
|
||||
Hdmi_unsol_event() -> hdmi_intrinsic_event() -> check_presence_and_report() ->
|
||||
hdmi_present_sense() -> hdmi_prepsent_sense_via_verbs()
|
||||
Use directly snd_jack_report() on spec->pcm_rec[pcm_idx].jack for dyn_pcm_assign.
|
||||
Use hda_jack mechanism to handle jack events.
|
||||
|
||||
hdmi_unsol_event() -> hdmi_intrinsic_event() -> check_presence_and_report() ->
|
||||
hdmi_present_sense() -> hdmi_prepsent_sense_via_verbs()
|
||||
|
||||
Use directly snd_jack_report() on spec->pcm_rec[pcm_idx].jack for dyn_pcm_assign.
|
||||
Use hda_jack mechanism to handle jack events.
|
||||
|
||||
|
||||
Others to be added later
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
HD-Audio
|
||||
========
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
notes
|
||||
models
|
||||
controls
|
||||
dp-mst
|
||||
|
|
@ -0,0 +1,518 @@
|
|||
==============================
|
||||
HD-Audio Codec-Specific Models
|
||||
==============================
|
||||
|
||||
ALC880
|
||||
======
|
||||
3stack
|
||||
3-jack in back and a headphone out
|
||||
3stack-digout
|
||||
3-jack in back, a HP out and a SPDIF out
|
||||
5stack
|
||||
5-jack in back, 2-jack in front
|
||||
5stack-digout
|
||||
5-jack in back, 2-jack in front, a SPDIF out
|
||||
6stack
|
||||
6-jack in back, 2-jack in front
|
||||
6stack-digout
|
||||
6-jack with a SPDIF out
|
||||
|
||||
ALC260
|
||||
======
|
||||
gpio1
|
||||
Enable GPIO1
|
||||
coef
|
||||
Enable EAPD via COEF table
|
||||
fujitsu
|
||||
Quirk for FSC S7020
|
||||
fujitsu-jwse
|
||||
Quirk for FSC S7020 with jack modes and HP mic support
|
||||
|
||||
ALC262
|
||||
======
|
||||
inv-dmic
|
||||
Inverted internal mic workaround
|
||||
|
||||
ALC267/268
|
||||
==========
|
||||
inv-dmic
|
||||
Inverted internal mic workaround
|
||||
hp-eapd
|
||||
Disable HP EAPD on NID 0x15
|
||||
|
||||
ALC22x/23x/25x/269/27x/28x/29x (and vendor-specific ALC3xxx models)
|
||||
===================================================================
|
||||
laptop-amic
|
||||
Laptops with analog-mic input
|
||||
laptop-dmic
|
||||
Laptops with digital-mic input
|
||||
alc269-dmic
|
||||
Enable ALC269(VA) digital mic workaround
|
||||
alc271-dmic
|
||||
Enable ALC271X digital mic workaround
|
||||
inv-dmic
|
||||
Inverted internal mic workaround
|
||||
headset-mic
|
||||
Indicates a combined headset (headphone+mic) jack
|
||||
headset-mode
|
||||
More comprehensive headset support for ALC269 & co
|
||||
headset-mode-no-hp-mic
|
||||
Headset mode support without headphone mic
|
||||
lenovo-dock
|
||||
Enables docking station I/O for some Lenovos
|
||||
hp-gpio-led
|
||||
GPIO LED support on HP laptops
|
||||
dell-headset-multi
|
||||
Headset jack, which can also be used as mic-in
|
||||
dell-headset-dock
|
||||
Headset jack (without mic-in), and also dock I/O
|
||||
alc283-dac-wcaps
|
||||
Fixups for Chromebook with ALC283
|
||||
alc283-sense-combo
|
||||
Combo jack sensing on ALC283
|
||||
tpt440-dock
|
||||
Pin configs for Lenovo Thinkpad Dock support
|
||||
|
||||
ALC66x/67x/892
|
||||
==============
|
||||
mario
|
||||
Chromebook mario model fixup
|
||||
asus-mode1
|
||||
ASUS
|
||||
asus-mode2
|
||||
ASUS
|
||||
asus-mode3
|
||||
ASUS
|
||||
asus-mode4
|
||||
ASUS
|
||||
asus-mode5
|
||||
ASUS
|
||||
asus-mode6
|
||||
ASUS
|
||||
asus-mode7
|
||||
ASUS
|
||||
asus-mode8
|
||||
ASUS
|
||||
inv-dmic
|
||||
Inverted internal mic workaround
|
||||
dell-headset-multi
|
||||
Headset jack, which can also be used as mic-in
|
||||
|
||||
ALC680
|
||||
======
|
||||
N/A
|
||||
|
||||
ALC88x/898/1150
|
||||
======================
|
||||
acer-aspire-4930g
|
||||
Acer Aspire 4930G/5930G/6530G/6930G/7730G
|
||||
acer-aspire-8930g
|
||||
Acer Aspire 8330G/6935G
|
||||
acer-aspire
|
||||
Acer Aspire others
|
||||
inv-dmic
|
||||
Inverted internal mic workaround
|
||||
no-primary-hp
|
||||
VAIO Z/VGC-LN51JGB workaround (for fixed speaker DAC)
|
||||
|
||||
ALC861/660
|
||||
==========
|
||||
N/A
|
||||
|
||||
ALC861VD/660VD
|
||||
==============
|
||||
N/A
|
||||
|
||||
CMI9880
|
||||
=======
|
||||
minimal
|
||||
3-jack in back
|
||||
min_fp
|
||||
3-jack in back, 2-jack in front
|
||||
full
|
||||
6-jack in back, 2-jack in front
|
||||
full_dig
|
||||
6-jack in back, 2-jack in front, SPDIF I/O
|
||||
allout
|
||||
5-jack in back, 2-jack in front, SPDIF out
|
||||
auto
|
||||
auto-config reading BIOS (default)
|
||||
|
||||
AD1882 / AD1882A
|
||||
================
|
||||
3stack
|
||||
3-stack mode
|
||||
3stack-automute
|
||||
3-stack with automute front HP (default)
|
||||
6stack
|
||||
6-stack mode
|
||||
|
||||
AD1884A / AD1883 / AD1984A / AD1984B
|
||||
====================================
|
||||
desktop 3-stack desktop (default)
|
||||
laptop laptop with HP jack sensing
|
||||
mobile mobile devices with HP jack sensing
|
||||
thinkpad Lenovo Thinkpad X300
|
||||
touchsmart HP Touchsmart
|
||||
|
||||
AD1884
|
||||
======
|
||||
N/A
|
||||
|
||||
AD1981
|
||||
======
|
||||
basic 3-jack (default)
|
||||
hp HP nx6320
|
||||
thinkpad Lenovo Thinkpad T60/X60/Z60
|
||||
toshiba Toshiba U205
|
||||
|
||||
AD1983
|
||||
======
|
||||
N/A
|
||||
|
||||
AD1984
|
||||
======
|
||||
basic default configuration
|
||||
thinkpad Lenovo Thinkpad T61/X61
|
||||
dell_desktop Dell T3400
|
||||
|
||||
AD1986A
|
||||
=======
|
||||
3stack
|
||||
3-stack, shared surrounds
|
||||
laptop
|
||||
2-channel only (FSC V2060, Samsung M50)
|
||||
laptop-imic
|
||||
2-channel with built-in mic
|
||||
eapd
|
||||
Turn on EAPD constantly
|
||||
|
||||
AD1988/AD1988B/AD1989A/AD1989B
|
||||
==============================
|
||||
6stack
|
||||
6-jack
|
||||
6stack-dig
|
||||
ditto with SPDIF
|
||||
3stack
|
||||
3-jack
|
||||
3stack-dig
|
||||
ditto with SPDIF
|
||||
laptop
|
||||
3-jack with hp-jack automute
|
||||
laptop-dig
|
||||
ditto with SPDIF
|
||||
auto
|
||||
auto-config reading BIOS (default)
|
||||
|
||||
Conexant 5045
|
||||
=============
|
||||
laptop-hpsense
|
||||
Laptop with HP sense (old model laptop)
|
||||
laptop-micsense
|
||||
Laptop with Mic sense (old model fujitsu)
|
||||
laptop-hpmicsense
|
||||
Laptop with HP and Mic senses
|
||||
benq
|
||||
Benq R55E
|
||||
laptop-hp530
|
||||
HP 530 laptop
|
||||
test
|
||||
for testing/debugging purpose, almost all controls can be
|
||||
adjusted. Appearing only when compiled with $CONFIG_SND_DEBUG=y
|
||||
|
||||
Conexant 5047
|
||||
=============
|
||||
laptop
|
||||
Basic Laptop config
|
||||
laptop-hp
|
||||
Laptop config for some HP models (subdevice 30A5)
|
||||
laptop-eapd
|
||||
Laptop config with EAPD support
|
||||
test
|
||||
for testing/debugging purpose, almost all controls can be
|
||||
adjusted. Appearing only when compiled with $CONFIG_SND_DEBUG=y
|
||||
|
||||
Conexant 5051
|
||||
=============
|
||||
laptop
|
||||
Basic Laptop config (default)
|
||||
hp
|
||||
HP Spartan laptop
|
||||
hp-dv6736
|
||||
HP dv6736
|
||||
hp-f700
|
||||
HP Compaq Presario F700
|
||||
ideapad
|
||||
Lenovo IdeaPad laptop
|
||||
toshiba
|
||||
Toshiba Satellite M300
|
||||
|
||||
Conexant 5066
|
||||
=============
|
||||
laptop
|
||||
Basic Laptop config (default)
|
||||
hp-laptop
|
||||
HP laptops, e g G60
|
||||
asus
|
||||
Asus K52JU, Lenovo G560
|
||||
dell-laptop
|
||||
Dell laptops
|
||||
dell-vostro
|
||||
Dell Vostro
|
||||
olpc-xo-1_5
|
||||
OLPC XO 1.5
|
||||
ideapad
|
||||
Lenovo IdeaPad U150
|
||||
thinkpad
|
||||
Lenovo Thinkpad
|
||||
|
||||
STAC9200
|
||||
========
|
||||
ref
|
||||
Reference board
|
||||
oqo
|
||||
OQO Model 2
|
||||
dell-d21
|
||||
Dell (unknown)
|
||||
dell-d22
|
||||
Dell (unknown)
|
||||
dell-d23
|
||||
Dell (unknown)
|
||||
dell-m21
|
||||
Dell Inspiron 630m, Dell Inspiron 640m
|
||||
dell-m22
|
||||
Dell Latitude D620, Dell Latitude D820
|
||||
dell-m23
|
||||
Dell XPS M1710, Dell Precision M90
|
||||
dell-m24
|
||||
Dell Latitude 120L
|
||||
dell-m25
|
||||
Dell Inspiron E1505n
|
||||
dell-m26
|
||||
Dell Inspiron 1501
|
||||
dell-m27
|
||||
Dell Inspiron E1705/9400
|
||||
gateway-m4
|
||||
Gateway laptops with EAPD control
|
||||
gateway-m4-2
|
||||
Gateway laptops with EAPD control
|
||||
panasonic
|
||||
Panasonic CF-74
|
||||
auto
|
||||
BIOS setup (default)
|
||||
|
||||
STAC9205/9254
|
||||
=============
|
||||
ref
|
||||
Reference board
|
||||
dell-m42
|
||||
Dell (unknown)
|
||||
dell-m43
|
||||
Dell Precision
|
||||
dell-m44
|
||||
Dell Inspiron
|
||||
eapd
|
||||
Keep EAPD on (e.g. Gateway T1616)
|
||||
auto
|
||||
BIOS setup (default)
|
||||
|
||||
STAC9220/9221
|
||||
=============
|
||||
ref
|
||||
Reference board
|
||||
3stack
|
||||
D945 3stack
|
||||
5stack
|
||||
D945 5stack + SPDIF
|
||||
intel-mac-v1
|
||||
Intel Mac Type 1
|
||||
intel-mac-v2
|
||||
Intel Mac Type 2
|
||||
intel-mac-v3
|
||||
Intel Mac Type 3
|
||||
intel-mac-v4
|
||||
Intel Mac Type 4
|
||||
intel-mac-v5
|
||||
Intel Mac Type 5
|
||||
intel-mac-auto
|
||||
Intel Mac (detect type according to subsystem id)
|
||||
macmini
|
||||
Intel Mac Mini (equivalent with type 3)
|
||||
macbook
|
||||
Intel Mac Book (eq. type 5)
|
||||
macbook-pro-v1
|
||||
Intel Mac Book Pro 1st generation (eq. type 3)
|
||||
macbook-pro
|
||||
Intel Mac Book Pro 2nd generation (eq. type 3)
|
||||
imac-intel
|
||||
Intel iMac (eq. type 2)
|
||||
imac-intel-20
|
||||
Intel iMac (newer version) (eq. type 3)
|
||||
ecs202
|
||||
ECS/PC chips
|
||||
dell-d81
|
||||
Dell (unknown)
|
||||
dell-d82
|
||||
Dell (unknown)
|
||||
dell-m81
|
||||
Dell (unknown)
|
||||
dell-m82
|
||||
Dell XPS M1210
|
||||
auto
|
||||
BIOS setup (default)
|
||||
|
||||
STAC9202/9250/9251
|
||||
==================
|
||||
ref
|
||||
Reference board, base config
|
||||
m1
|
||||
Some Gateway MX series laptops (NX560XL)
|
||||
m1-2
|
||||
Some Gateway MX series laptops (MX6453)
|
||||
m2
|
||||
Some Gateway MX series laptops (M255)
|
||||
m2-2
|
||||
Some Gateway MX series laptops
|
||||
m3
|
||||
Some Gateway MX series laptops
|
||||
m5
|
||||
Some Gateway MX series laptops (MP6954)
|
||||
m6
|
||||
Some Gateway NX series laptops
|
||||
auto
|
||||
BIOS setup (default)
|
||||
|
||||
STAC9227/9228/9229/927x
|
||||
=======================
|
||||
ref
|
||||
Reference board
|
||||
ref-no-jd
|
||||
Reference board without HP/Mic jack detection
|
||||
3stack
|
||||
D965 3stack
|
||||
5stack
|
||||
D965 5stack + SPDIF
|
||||
5stack-no-fp
|
||||
D965 5stack without front panel
|
||||
dell-3stack
|
||||
Dell Dimension E520
|
||||
dell-bios
|
||||
Fixes with Dell BIOS setup
|
||||
dell-bios-amic
|
||||
Fixes with Dell BIOS setup including analog mic
|
||||
volknob
|
||||
Fixes with volume-knob widget 0x24
|
||||
auto
|
||||
BIOS setup (default)
|
||||
|
||||
STAC92HD71B*
|
||||
============
|
||||
ref
|
||||
Reference board
|
||||
dell-m4-1
|
||||
Dell desktops
|
||||
dell-m4-2
|
||||
Dell desktops
|
||||
dell-m4-3
|
||||
Dell desktops
|
||||
hp-m4
|
||||
HP mini 1000
|
||||
hp-dv5
|
||||
HP dv series
|
||||
hp-hdx
|
||||
HP HDX series
|
||||
hp-dv4-1222nr
|
||||
HP dv4-1222nr (with LED support)
|
||||
auto
|
||||
BIOS setup (default)
|
||||
|
||||
STAC92HD73*
|
||||
===========
|
||||
ref
|
||||
Reference board
|
||||
no-jd
|
||||
BIOS setup but without jack-detection
|
||||
intel
|
||||
Intel DG45* mobos
|
||||
dell-m6-amic
|
||||
Dell desktops/laptops with analog mics
|
||||
dell-m6-dmic
|
||||
Dell desktops/laptops with digital mics
|
||||
dell-m6
|
||||
Dell desktops/laptops with both type of mics
|
||||
dell-eq
|
||||
Dell desktops/laptops
|
||||
alienware
|
||||
Alienware M17x
|
||||
auto
|
||||
BIOS setup (default)
|
||||
|
||||
STAC92HD83*
|
||||
===========
|
||||
ref
|
||||
Reference board
|
||||
mic-ref
|
||||
Reference board with power management for ports
|
||||
dell-s14
|
||||
Dell laptop
|
||||
dell-vostro-3500
|
||||
Dell Vostro 3500 laptop
|
||||
hp-dv7-4000
|
||||
HP dv-7 4000
|
||||
hp_cNB11_intquad
|
||||
HP CNB models with 4 speakers
|
||||
hp-zephyr
|
||||
HP Zephyr
|
||||
hp-led
|
||||
HP with broken BIOS for mute LED
|
||||
hp-inv-led
|
||||
HP with broken BIOS for inverted mute LED
|
||||
hp-mic-led
|
||||
HP with mic-mute LED
|
||||
headset-jack
|
||||
Dell Latitude with a 4-pin headset jack
|
||||
hp-envy-bass
|
||||
Pin fixup for HP Envy bass speaker (NID 0x0f)
|
||||
hp-envy-ts-bass
|
||||
Pin fixup for HP Envy TS bass speaker (NID 0x10)
|
||||
hp-bnb13-eq
|
||||
Hardware equalizer setup for HP laptops
|
||||
auto
|
||||
BIOS setup (default)
|
||||
|
||||
STAC92HD95
|
||||
==========
|
||||
hp-led
|
||||
LED support for HP laptops
|
||||
hp-bass
|
||||
Bass HPF setup for HP Spectre 13
|
||||
|
||||
STAC9872
|
||||
========
|
||||
vaio
|
||||
VAIO laptop without SPDIF
|
||||
auto
|
||||
BIOS setup (default)
|
||||
|
||||
Cirrus Logic CS4206/4207
|
||||
========================
|
||||
mbp55
|
||||
MacBook Pro 5,5
|
||||
imac27
|
||||
IMac 27 Inch
|
||||
auto
|
||||
BIOS setup (default)
|
||||
|
||||
Cirrus Logic CS4208
|
||||
===================
|
||||
mba6
|
||||
MacBook Air 6,1 and 6,2
|
||||
gpio0
|
||||
Enable GPIO 0 amp
|
||||
auto
|
||||
BIOS setup (default)
|
||||
|
||||
VIA VT17xx/VT18xx/VT20xx
|
||||
========================
|
||||
auto
|
||||
BIOS setup (default)
|
||||
Разница между файлами не показана из-за своего большого размера
Загрузить разницу
|
|
@ -0,0 +1,20 @@
|
|||
===================================
|
||||
Linux Sound Subsystem Documentation
|
||||
===================================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
kernel-api/index
|
||||
designs/index
|
||||
soc/index
|
||||
alsa-configuration
|
||||
hd-audio/index
|
||||
cards/index
|
||||
|
||||
.. only:: subproject
|
||||
|
||||
Indices
|
||||
=======
|
||||
|
||||
* :ref:`genindex`
|
||||
|
|
@ -0,0 +1,134 @@
|
|||
===================
|
||||
The ALSA Driver API
|
||||
===================
|
||||
|
||||
Management of Cards and Devices
|
||||
===============================
|
||||
|
||||
Card Management
|
||||
---------------
|
||||
.. kernel-doc:: sound/core/init.c
|
||||
|
||||
Device Components
|
||||
-----------------
|
||||
.. kernel-doc:: sound/core/device.c
|
||||
|
||||
Module requests and Device File Entries
|
||||
---------------------------------------
|
||||
.. kernel-doc:: sound/core/sound.c
|
||||
|
||||
Memory Management Helpers
|
||||
-------------------------
|
||||
.. kernel-doc:: sound/core/memory.c
|
||||
.. kernel-doc:: sound/core/memalloc.c
|
||||
|
||||
|
||||
PCM API
|
||||
=======
|
||||
|
||||
PCM Core
|
||||
--------
|
||||
.. kernel-doc:: sound/core/pcm.c
|
||||
.. kernel-doc:: sound/core/pcm_lib.c
|
||||
.. kernel-doc:: sound/core/pcm_native.c
|
||||
.. kernel-doc:: include/sound/pcm.h
|
||||
|
||||
PCM Format Helpers
|
||||
------------------
|
||||
.. kernel-doc:: sound/core/pcm_misc.c
|
||||
|
||||
PCM Memory Management
|
||||
---------------------
|
||||
.. kernel-doc:: sound/core/pcm_memory.c
|
||||
|
||||
PCM DMA Engine API
|
||||
------------------
|
||||
.. kernel-doc:: sound/core/pcm_dmaengine.c
|
||||
.. kernel-doc:: include/sound/dmaengine_pcm.h
|
||||
|
||||
Control/Mixer API
|
||||
=================
|
||||
|
||||
General Control Interface
|
||||
-------------------------
|
||||
.. kernel-doc:: sound/core/control.c
|
||||
|
||||
AC97 Codec API
|
||||
--------------
|
||||
.. kernel-doc:: sound/pci/ac97/ac97_codec.c
|
||||
.. kernel-doc:: sound/pci/ac97/ac97_pcm.c
|
||||
|
||||
Virtual Master Control API
|
||||
--------------------------
|
||||
.. kernel-doc:: sound/core/vmaster.c
|
||||
.. kernel-doc:: include/sound/control.h
|
||||
|
||||
MIDI API
|
||||
========
|
||||
|
||||
Raw MIDI API
|
||||
------------
|
||||
.. kernel-doc:: sound/core/rawmidi.c
|
||||
|
||||
MPU401-UART API
|
||||
---------------
|
||||
.. kernel-doc:: sound/drivers/mpu401/mpu401_uart.c
|
||||
|
||||
Proc Info API
|
||||
=============
|
||||
|
||||
Proc Info Interface
|
||||
-------------------
|
||||
.. kernel-doc:: sound/core/info.c
|
||||
|
||||
Compress Offload
|
||||
================
|
||||
|
||||
Compress Offload API
|
||||
--------------------
|
||||
.. kernel-doc:: sound/core/compress_offload.c
|
||||
.. kernel-doc:: include/uapi/sound/compress_offload.h
|
||||
.. kernel-doc:: include/uapi/sound/compress_params.h
|
||||
.. kernel-doc:: include/sound/compress_driver.h
|
||||
|
||||
ASoC
|
||||
====
|
||||
|
||||
ASoC Core API
|
||||
-------------
|
||||
.. kernel-doc:: include/sound/soc.h
|
||||
.. kernel-doc:: sound/soc/soc-core.c
|
||||
.. kernel-doc:: sound/soc/soc-devres.c
|
||||
.. kernel-doc:: sound/soc/soc-io.c
|
||||
.. kernel-doc:: sound/soc/soc-pcm.c
|
||||
.. kernel-doc:: sound/soc/soc-ops.c
|
||||
.. kernel-doc:: sound/soc/soc-compress.c
|
||||
|
||||
ASoC DAPM API
|
||||
-------------
|
||||
.. kernel-doc:: sound/soc/soc-dapm.c
|
||||
|
||||
ASoC DMA Engine API
|
||||
-------------------
|
||||
.. kernel-doc:: sound/soc/soc-generic-dmaengine-pcm.c
|
||||
|
||||
Miscellaneous Functions
|
||||
=======================
|
||||
|
||||
Hardware-Dependent Devices API
|
||||
------------------------------
|
||||
.. kernel-doc:: sound/core/hwdep.c
|
||||
|
||||
Jack Abstraction Layer API
|
||||
--------------------------
|
||||
.. kernel-doc:: include/sound/jack.h
|
||||
.. kernel-doc:: sound/core/jack.c
|
||||
.. kernel-doc:: sound/soc/soc-jack.c
|
||||
|
||||
ISA DMA Helpers
|
||||
---------------
|
||||
.. kernel-doc:: sound/core/isadma.c
|
||||
|
||||
Other Helper Macros
|
||||
-------------------
|
||||
.. kernel-doc:: include/sound/core.h
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
ALSA Kernel API Documentation
|
||||
=============================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
alsa-driver-api
|
||||
writing-an-alsa-driver
|
||||
Разница между файлами не показана из-за своего большого размера
Загрузить разницу
|
|
@ -1,3 +1,4 @@
|
|||
==============
|
||||
Audio Clocking
|
||||
==============
|
||||
|
||||
|
|
@ -30,15 +31,9 @@ runs at exactly the sample rate (LRC = Rate).
|
|||
|
||||
Bit Clock can be generated as follows:-
|
||||
|
||||
BCLK = MCLK / x
|
||||
|
||||
or
|
||||
|
||||
BCLK = LRC * x
|
||||
|
||||
or
|
||||
|
||||
BCLK = LRC * Channels * Word Size
|
||||
- BCLK = MCLK / x, or
|
||||
- BCLK = LRC * x, or
|
||||
- BCLK = LRC * Channels * Word Size
|
||||
|
||||
This relationship depends on the codec or SoC CPU in particular. In general
|
||||
it is best to configure BCLK to the lowest possible speed (depending on your
|
||||
|
|
@ -0,0 +1,108 @@
|
|||
==============================================
|
||||
Creating codec to codec dai link for ALSA dapm
|
||||
==============================================
|
||||
|
||||
Mostly the flow of audio is always from CPU to codec so your system
|
||||
will look as below:
|
||||
::
|
||||
|
||||
--------- ---------
|
||||
| | dai | |
|
||||
CPU -------> codec
|
||||
| | | |
|
||||
--------- ---------
|
||||
|
||||
In case your system looks as below:
|
||||
::
|
||||
|
||||
---------
|
||||
| |
|
||||
codec-2
|
||||
| |
|
||||
---------
|
||||
|
|
||||
dai-2
|
||||
|
|
||||
---------- ---------
|
||||
| | dai-1 | |
|
||||
CPU -------> codec-1
|
||||
| | | |
|
||||
---------- ---------
|
||||
|
|
||||
dai-3
|
||||
|
|
||||
---------
|
||||
| |
|
||||
codec-3
|
||||
| |
|
||||
---------
|
||||
|
||||
Suppose codec-2 is a bluetooth chip and codec-3 is connected to
|
||||
a speaker and you have a below scenario:
|
||||
codec-2 will receive the audio data and the user wants to play that
|
||||
audio through codec-3 without involving the CPU.This
|
||||
aforementioned case is the ideal case when codec to codec
|
||||
connection should be used.
|
||||
|
||||
Your dai_link should appear as below in your machine
|
||||
file:
|
||||
::
|
||||
|
||||
/*
|
||||
* this pcm stream only supports 24 bit, 2 channel and
|
||||
* 48k sampling rate.
|
||||
*/
|
||||
static const struct snd_soc_pcm_stream dsp_codec_params = {
|
||||
.formats = SNDRV_PCM_FMTBIT_S24_LE,
|
||||
.rate_min = 48000,
|
||||
.rate_max = 48000,
|
||||
.channels_min = 2,
|
||||
.channels_max = 2,
|
||||
};
|
||||
|
||||
{
|
||||
.name = "CPU-DSP",
|
||||
.stream_name = "CPU-DSP",
|
||||
.cpu_dai_name = "samsung-i2s.0",
|
||||
.codec_name = "codec-2,
|
||||
.codec_dai_name = "codec-2-dai_name",
|
||||
.platform_name = "samsung-i2s.0",
|
||||
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
|
||||
| SND_SOC_DAIFMT_CBM_CFM,
|
||||
.ignore_suspend = 1,
|
||||
.params = &dsp_codec_params,
|
||||
},
|
||||
{
|
||||
.name = "DSP-CODEC",
|
||||
.stream_name = "DSP-CODEC",
|
||||
.cpu_dai_name = "wm0010-sdi2",
|
||||
.codec_name = "codec-3,
|
||||
.codec_dai_name = "codec-3-dai_name",
|
||||
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
|
||||
| SND_SOC_DAIFMT_CBM_CFM,
|
||||
.ignore_suspend = 1,
|
||||
.params = &dsp_codec_params,
|
||||
},
|
||||
|
||||
Above code snippet is motivated from sound/soc/samsung/speyside.c.
|
||||
|
||||
Note the "params" callback which lets the dapm know that this
|
||||
dai_link is a codec to codec connection.
|
||||
|
||||
In dapm core a route is created between cpu_dai playback widget
|
||||
and codec_dai capture widget for playback path and vice-versa is
|
||||
true for capture path. In order for this aforementioned route to get
|
||||
triggered, DAPM needs to find a valid endpoint which could be either
|
||||
a sink or source widget corresponding to playback and capture path
|
||||
respectively.
|
||||
|
||||
In order to trigger this dai_link widget, a thin codec driver for
|
||||
the speaker amp can be created as demonstrated in wm8727.c file, it
|
||||
sets appropriate constraints for the device even if it needs no control.
|
||||
|
||||
Make sure to name your corresponding cpu and codec playback and capture
|
||||
dai names ending with "Playback" and "Capture" respectively as dapm core
|
||||
will link and power those dais based on the name.
|
||||
|
||||
Note that in current device tree there is no way to mark a dai_link
|
||||
as codec to codec. However, it may change in future.
|
||||
|
|
@ -1,3 +1,4 @@
|
|||
=======================
|
||||
ASoC Codec Class Driver
|
||||
=======================
|
||||
|
||||
|
|
@ -9,16 +10,16 @@ machine drivers respectively.
|
|||
|
||||
Each codec class driver *must* provide the following features:-
|
||||
|
||||
1) Codec DAI and PCM configuration
|
||||
2) Codec control IO - using RegMap API
|
||||
3) Mixers and audio controls
|
||||
4) Codec audio operations
|
||||
5) DAPM description.
|
||||
6) DAPM event handler.
|
||||
1. Codec DAI and PCM configuration
|
||||
2. Codec control IO - using RegMap API
|
||||
3. Mixers and audio controls
|
||||
4. Codec audio operations
|
||||
5. DAPM description.
|
||||
6. DAPM event handler.
|
||||
|
||||
Optionally, codec drivers can also provide:-
|
||||
|
||||
7) DAC Digital mute control.
|
||||
7. DAC Digital mute control.
|
||||
|
||||
Its probably best to use this guide in conjunction with the existing codec
|
||||
driver code in sound/soc/codecs/
|
||||
|
|
@ -26,24 +27,25 @@ driver code in sound/soc/codecs/
|
|||
ASoC Codec driver breakdown
|
||||
===========================
|
||||
|
||||
1 - Codec DAI and PCM configuration
|
||||
-----------------------------------
|
||||
Codec DAI and PCM configuration
|
||||
-------------------------------
|
||||
Each codec driver must have a struct snd_soc_dai_driver to define its DAI and
|
||||
PCM capabilities and operations. This struct is exported so that it can be
|
||||
registered with the core by your machine driver.
|
||||
|
||||
e.g.
|
||||
::
|
||||
|
||||
static struct snd_soc_dai_ops wm8731_dai_ops = {
|
||||
static struct snd_soc_dai_ops wm8731_dai_ops = {
|
||||
.prepare = wm8731_pcm_prepare,
|
||||
.hw_params = wm8731_hw_params,
|
||||
.shutdown = wm8731_shutdown,
|
||||
.digital_mute = wm8731_mute,
|
||||
.set_sysclk = wm8731_set_dai_sysclk,
|
||||
.set_fmt = wm8731_set_dai_fmt,
|
||||
};
|
||||
|
||||
struct snd_soc_dai_driver wm8731_dai = {
|
||||
};
|
||||
|
||||
struct snd_soc_dai_driver wm8731_dai = {
|
||||
.name = "wm8731-hifi",
|
||||
.playback = {
|
||||
.stream_name = "Playback",
|
||||
|
|
@ -59,25 +61,27 @@ struct snd_soc_dai_driver wm8731_dai = {
|
|||
.formats = WM8731_FORMATS,},
|
||||
.ops = &wm8731_dai_ops,
|
||||
.symmetric_rates = 1,
|
||||
};
|
||||
};
|
||||
|
||||
|
||||
2 - Codec control IO
|
||||
--------------------
|
||||
Codec control IO
|
||||
----------------
|
||||
The codec can usually be controlled via an I2C or SPI style interface
|
||||
(AC97 combines control with data in the DAI). The codec driver should use the
|
||||
Regmap API for all codec IO. Please see include/linux/regmap.h and existing
|
||||
codec drivers for example regmap usage.
|
||||
|
||||
|
||||
3 - Mixers and audio controls
|
||||
-----------------------------
|
||||
Mixers and audio controls
|
||||
-------------------------
|
||||
All the codec mixers and audio controls can be defined using the convenience
|
||||
macros defined in soc.h.
|
||||
::
|
||||
|
||||
#define SOC_SINGLE(xname, reg, shift, mask, invert)
|
||||
|
||||
Defines a single control as follows:-
|
||||
::
|
||||
|
||||
xname = Control name e.g. "Playback Volume"
|
||||
reg = codec register
|
||||
|
|
@ -86,18 +90,22 @@ Defines a single control as follows:-
|
|||
invert = the control is inverted
|
||||
|
||||
Other macros include:-
|
||||
::
|
||||
|
||||
#define SOC_DOUBLE(xname, reg, shift_left, shift_right, mask, invert)
|
||||
|
||||
A stereo control
|
||||
::
|
||||
|
||||
#define SOC_DOUBLE_R(xname, reg_left, reg_right, shift, mask, invert)
|
||||
|
||||
A stereo control spanning 2 registers
|
||||
::
|
||||
|
||||
#define SOC_ENUM_SINGLE(xreg, xshift, xmask, xtexts)
|
||||
|
||||
Defines an single enumerated control as follows:-
|
||||
::
|
||||
|
||||
xreg = register
|
||||
xshift = control bit(s) offset in register
|
||||
|
|
@ -109,25 +117,26 @@ Defines an single enumerated control as follows:-
|
|||
Defines a stereo enumerated control
|
||||
|
||||
|
||||
4 - Codec Audio Operations
|
||||
--------------------------
|
||||
Codec Audio Operations
|
||||
----------------------
|
||||
The codec driver also supports the following ALSA PCM operations:-
|
||||
::
|
||||
|
||||
/* SoC audio ops */
|
||||
struct snd_soc_ops {
|
||||
/* SoC audio ops */
|
||||
struct snd_soc_ops {
|
||||
int (*startup)(struct snd_pcm_substream *);
|
||||
void (*shutdown)(struct snd_pcm_substream *);
|
||||
int (*hw_params)(struct snd_pcm_substream *, struct snd_pcm_hw_params *);
|
||||
int (*hw_free)(struct snd_pcm_substream *);
|
||||
int (*prepare)(struct snd_pcm_substream *);
|
||||
};
|
||||
};
|
||||
|
||||
Please refer to the ALSA driver PCM documentation for details.
|
||||
http://www.alsa-project.org/~iwai/writing-an-alsa-driver/
|
||||
|
||||
|
||||
5 - DAPM description.
|
||||
---------------------
|
||||
DAPM description
|
||||
----------------
|
||||
The Dynamic Audio Power Management description describes the codec power
|
||||
components and their relationships and registers to the ASoC core.
|
||||
Please read dapm.txt for details of building the description.
|
||||
|
|
@ -135,13 +144,14 @@ Please read dapm.txt for details of building the description.
|
|||
Please also see the examples in other codec drivers.
|
||||
|
||||
|
||||
6 - DAPM event handler
|
||||
----------------------
|
||||
DAPM event handler
|
||||
------------------
|
||||
This function is a callback that handles codec domain PM calls and system
|
||||
domain PM calls (e.g. suspend and resume). It is used to put the codec
|
||||
to sleep when not in use.
|
||||
|
||||
Power states:-
|
||||
::
|
||||
|
||||
SNDRV_CTL_POWER_D0: /* full On */
|
||||
/* vref/mid, clk and osc on, active */
|
||||
|
|
@ -155,8 +165,8 @@ Power states:-
|
|||
SNDRV_CTL_POWER_D3cold: /* Everything Off, without power */
|
||||
|
||||
|
||||
7 - Codec DAC digital mute control
|
||||
----------------------------------
|
||||
Codec DAC digital mute control
|
||||
------------------------------
|
||||
Most codecs have a digital mute before the DACs that can be used to
|
||||
minimise any system noise. The mute stops any digital data from
|
||||
entering the DAC.
|
||||
|
|
@ -165,9 +175,10 @@ A callback can be created that is called by the core for each codec DAI
|
|||
when the mute is applied or freed.
|
||||
|
||||
i.e.
|
||||
::
|
||||
|
||||
static int wm8974_mute(struct snd_soc_dai *dai, int mute)
|
||||
{
|
||||
static int wm8974_mute(struct snd_soc_dai *dai, int mute)
|
||||
{
|
||||
struct snd_soc_codec *codec = dai->codec;
|
||||
u16 mute_reg = snd_soc_read(codec, WM8974_DAC) & 0xffbf;
|
||||
|
||||
|
|
@ -176,4 +187,4 @@ static int wm8974_mute(struct snd_soc_dai *dai, int mute)
|
|||
else
|
||||
snd_soc_write(codec, WM8974_DAC, mute_reg);
|
||||
return 0;
|
||||
}
|
||||
}
|
||||
|
|
@ -1,3 +1,7 @@
|
|||
==================================
|
||||
ASoC Digital Audio Interface (DAI)
|
||||
==================================
|
||||
|
||||
ASoC currently supports the three main Digital Audio Interfaces (DAI) found on
|
||||
SoC controllers and portable audio CODECs today, namely AC97, I2S and PCM.
|
||||
|
||||
|
|
@ -5,21 +9,21 @@ SoC controllers and portable audio CODECs today, namely AC97, I2S and PCM.
|
|||
AC97
|
||||
====
|
||||
|
||||
AC97 is a five wire interface commonly found on many PC sound cards. It is
|
||||
AC97 is a five wire interface commonly found on many PC sound cards. It is
|
||||
now also popular in many portable devices. This DAI has a reset line and time
|
||||
multiplexes its data on its SDATA_OUT (playback) and SDATA_IN (capture) lines.
|
||||
The bit clock (BCLK) is always driven by the CODEC (usually 12.288MHz) and the
|
||||
frame (FRAME) (usually 48kHz) is always driven by the controller. Each AC97
|
||||
frame is 21uS long and is divided into 13 time slots.
|
||||
|
||||
The AC97 specification can be found at :-
|
||||
The AC97 specification can be found at :
|
||||
http://www.intel.com/p/en_US/business/design
|
||||
|
||||
|
||||
I2S
|
||||
===
|
||||
|
||||
I2S is a common 4 wire DAI used in HiFi, STB and portable devices. The Tx and
|
||||
I2S is a common 4 wire DAI used in HiFi, STB and portable devices. The Tx and
|
||||
Rx lines are used for audio transmission, whilst the bit clock (BCLK) and
|
||||
left/right clock (LRC) synchronise the link. I2S is flexible in that either the
|
||||
controller or CODEC can drive (master) the BCLK and LRC clock lines. Bit clock
|
||||
|
|
@ -30,13 +34,15 @@ different sample rates.
|
|||
|
||||
I2S has several different operating modes:-
|
||||
|
||||
o I2S - MSB is transmitted on the falling edge of the first BCLK after LRC
|
||||
transition.
|
||||
I2S
|
||||
MSB is transmitted on the falling edge of the first BCLK after LRC
|
||||
transition.
|
||||
|
||||
o Left Justified - MSB is transmitted on transition of LRC.
|
||||
Left Justified
|
||||
MSB is transmitted on transition of LRC.
|
||||
|
||||
o Right Justified - MSB is transmitted sample size BCLKs before LRC
|
||||
transition.
|
||||
Right Justified
|
||||
MSB is transmitted sample size BCLKs before LRC transition.
|
||||
|
||||
PCM
|
||||
===
|
||||
|
|
@ -51,6 +57,8 @@ is sometimes referred to as network mode).
|
|||
|
||||
Common PCM operating modes:-
|
||||
|
||||
o Mode A - MSB is transmitted on falling edge of first BCLK after FRAME/SYNC.
|
||||
Mode A
|
||||
MSB is transmitted on falling edge of first BCLK after FRAME/SYNC.
|
||||
|
||||
o Mode B - MSB is transmitted on rising edge of FRAME/SYNC.
|
||||
Mode B
|
||||
MSB is transmitted on rising edge of FRAME/SYNC.
|
||||
|
|
@ -1,8 +1,9 @@
|
|||
===================================================
|
||||
Dynamic Audio Power Management for Portable Devices
|
||||
===================================================
|
||||
|
||||
1. Description
|
||||
==============
|
||||
Description
|
||||
===========
|
||||
|
||||
Dynamic Audio Power Management (DAPM) is designed to allow portable
|
||||
Linux devices to use the minimum amount of power within the audio
|
||||
|
|
@ -21,20 +22,28 @@ level power systems.
|
|||
|
||||
There are 4 power domains within DAPM
|
||||
|
||||
1. Codec bias domain - VREF, VMID (core codec and audio power)
|
||||
Codec bias domain
|
||||
VREF, VMID (core codec and audio power)
|
||||
|
||||
Usually controlled at codec probe/remove and suspend/resume, although
|
||||
can be set at stream time if power is not needed for sidetone, etc.
|
||||
|
||||
2. Platform/Machine domain - physically connected inputs and outputs
|
||||
Platform/Machine domain
|
||||
physically connected inputs and outputs
|
||||
|
||||
Is platform/machine and user action specific, is configured by the
|
||||
machine driver and responds to asynchronous events e.g when HP
|
||||
are inserted
|
||||
|
||||
3. Path domain - audio subsystem signal paths
|
||||
Path domain
|
||||
audio subsystem signal paths
|
||||
|
||||
Automatically set when mixer and mux settings are changed by the user.
|
||||
e.g. alsamixer, amixer.
|
||||
|
||||
4. Stream domain - DACs and ADCs.
|
||||
Stream domain
|
||||
DACs and ADCs.
|
||||
|
||||
Enabled and disabled when stream playback/capture is started and
|
||||
stopped respectively. e.g. aplay, arecord.
|
||||
|
||||
|
|
@ -45,34 +54,57 @@ internal codec components). All audio components that effect power are called
|
|||
widgets hereafter.
|
||||
|
||||
|
||||
2. DAPM Widgets
|
||||
===============
|
||||
DAPM Widgets
|
||||
============
|
||||
|
||||
Audio DAPM widgets fall into a number of types:-
|
||||
|
||||
o Mixer - Mixes several analog signals into a single analog signal.
|
||||
o Mux - An analog switch that outputs only one of many inputs.
|
||||
o PGA - A programmable gain amplifier or attenuation widget.
|
||||
o ADC - Analog to Digital Converter
|
||||
o DAC - Digital to Analog Converter
|
||||
o Switch - An analog switch
|
||||
o Input - A codec input pin
|
||||
o Output - A codec output pin
|
||||
o Headphone - Headphone (and optional Jack)
|
||||
o Mic - Mic (and optional Jack)
|
||||
o Line - Line Input/Output (and optional Jack)
|
||||
o Speaker - Speaker
|
||||
o Supply - Power or clock supply widget used by other widgets.
|
||||
o Regulator - External regulator that supplies power to audio components.
|
||||
o Clock - External clock that supplies clock to audio components.
|
||||
o AIF IN - Audio Interface Input (with TDM slot mask).
|
||||
o AIF OUT - Audio Interface Output (with TDM slot mask).
|
||||
o Siggen - Signal Generator.
|
||||
o DAI IN - Digital Audio Interface Input.
|
||||
o DAI OUT - Digital Audio Interface Output.
|
||||
o DAI Link - DAI Link between two DAI structures */
|
||||
o Pre - Special PRE widget (exec before all others)
|
||||
o Post - Special POST widget (exec after all others)
|
||||
Mixer
|
||||
Mixes several analog signals into a single analog signal.
|
||||
Mux
|
||||
An analog switch that outputs only one of many inputs.
|
||||
PGA
|
||||
A programmable gain amplifier or attenuation widget.
|
||||
ADC
|
||||
Analog to Digital Converter
|
||||
DAC
|
||||
Digital to Analog Converter
|
||||
Switch
|
||||
An analog switch
|
||||
Input
|
||||
A codec input pin
|
||||
Output
|
||||
A codec output pin
|
||||
Headphone
|
||||
Headphone (and optional Jack)
|
||||
Mic
|
||||
Mic (and optional Jack)
|
||||
Line
|
||||
Line Input/Output (and optional Jack)
|
||||
Speaker
|
||||
Speaker
|
||||
Supply
|
||||
Power or clock supply widget used by other widgets.
|
||||
Regulator
|
||||
External regulator that supplies power to audio components.
|
||||
Clock
|
||||
External clock that supplies clock to audio components.
|
||||
AIF IN
|
||||
Audio Interface Input (with TDM slot mask).
|
||||
AIF OUT
|
||||
Audio Interface Output (with TDM slot mask).
|
||||
Siggen
|
||||
Signal Generator.
|
||||
DAI IN
|
||||
Digital Audio Interface Input.
|
||||
DAI OUT
|
||||
Digital Audio Interface Output.
|
||||
DAI Link
|
||||
DAI Link between two DAI structures
|
||||
Pre
|
||||
Special PRE widget (exec before all others)
|
||||
Post
|
||||
Special POST widget (exec after all others)
|
||||
|
||||
(Widgets are defined in include/sound/soc-dapm.h)
|
||||
|
||||
|
|
@ -84,52 +116,57 @@ Most widgets have a name, register, shift and invert. Some widgets have extra
|
|||
parameters for stream name and kcontrols.
|
||||
|
||||
|
||||
2.1 Stream Domain Widgets
|
||||
-------------------------
|
||||
Stream Domain Widgets
|
||||
---------------------
|
||||
|
||||
Stream Widgets relate to the stream power domain and only consist of ADCs
|
||||
(analog to digital converters), DACs (digital to analog converters),
|
||||
AIF IN and AIF OUT.
|
||||
|
||||
Stream widgets have the following format:-
|
||||
::
|
||||
|
||||
SND_SOC_DAPM_DAC(name, stream name, reg, shift, invert),
|
||||
SND_SOC_DAPM_AIF_IN(name, stream, slot, reg, shift, invert)
|
||||
SND_SOC_DAPM_DAC(name, stream name, reg, shift, invert),
|
||||
SND_SOC_DAPM_AIF_IN(name, stream, slot, reg, shift, invert)
|
||||
|
||||
NOTE: the stream name must match the corresponding stream name in your codec
|
||||
snd_soc_codec_dai.
|
||||
|
||||
e.g. stream widgets for HiFi playback and capture
|
||||
::
|
||||
|
||||
SND_SOC_DAPM_DAC("HiFi DAC", "HiFi Playback", REG, 3, 1),
|
||||
SND_SOC_DAPM_ADC("HiFi ADC", "HiFi Capture", REG, 2, 1),
|
||||
SND_SOC_DAPM_DAC("HiFi DAC", "HiFi Playback", REG, 3, 1),
|
||||
SND_SOC_DAPM_ADC("HiFi ADC", "HiFi Capture", REG, 2, 1),
|
||||
|
||||
e.g. stream widgets for AIF
|
||||
::
|
||||
|
||||
SND_SOC_DAPM_AIF_IN("AIF1RX", "AIF1 Playback", 0, SND_SOC_NOPM, 0, 0),
|
||||
SND_SOC_DAPM_AIF_OUT("AIF1TX", "AIF1 Capture", 0, SND_SOC_NOPM, 0, 0),
|
||||
SND_SOC_DAPM_AIF_IN("AIF1RX", "AIF1 Playback", 0, SND_SOC_NOPM, 0, 0),
|
||||
SND_SOC_DAPM_AIF_OUT("AIF1TX", "AIF1 Capture", 0, SND_SOC_NOPM, 0, 0),
|
||||
|
||||
|
||||
2.2 Path Domain Widgets
|
||||
-----------------------
|
||||
Path Domain Widgets
|
||||
-------------------
|
||||
|
||||
Path domain widgets have a ability to control or affect the audio signal or
|
||||
audio paths within the audio subsystem. They have the following form:-
|
||||
::
|
||||
|
||||
SND_SOC_DAPM_PGA(name, reg, shift, invert, controls, num_controls)
|
||||
SND_SOC_DAPM_PGA(name, reg, shift, invert, controls, num_controls)
|
||||
|
||||
Any widget kcontrols can be set using the controls and num_controls members.
|
||||
|
||||
e.g. Mixer widget (the kcontrols are declared first)
|
||||
::
|
||||
|
||||
/* Output Mixer */
|
||||
static const snd_kcontrol_new_t wm8731_output_mixer_controls[] = {
|
||||
SOC_DAPM_SINGLE("Line Bypass Switch", WM8731_APANA, 3, 1, 0),
|
||||
SOC_DAPM_SINGLE("Mic Sidetone Switch", WM8731_APANA, 5, 1, 0),
|
||||
SOC_DAPM_SINGLE("HiFi Playback Switch", WM8731_APANA, 4, 1, 0),
|
||||
};
|
||||
/* Output Mixer */
|
||||
static const snd_kcontrol_new_t wm8731_output_mixer_controls[] = {
|
||||
SOC_DAPM_SINGLE("Line Bypass Switch", WM8731_APANA, 3, 1, 0),
|
||||
SOC_DAPM_SINGLE("Mic Sidetone Switch", WM8731_APANA, 5, 1, 0),
|
||||
SOC_DAPM_SINGLE("HiFi Playback Switch", WM8731_APANA, 4, 1, 0),
|
||||
};
|
||||
|
||||
SND_SOC_DAPM_MIXER("Output Mixer", WM8731_PWR, 4, 1, wm8731_output_mixer_controls,
|
||||
SND_SOC_DAPM_MIXER("Output Mixer", WM8731_PWR, 4, 1, wm8731_output_mixer_controls,
|
||||
ARRAY_SIZE(wm8731_output_mixer_controls)),
|
||||
|
||||
If you don't want the mixer elements prefixed with the name of the mixer widget,
|
||||
|
|
@ -137,48 +174,49 @@ you can use SND_SOC_DAPM_MIXER_NAMED_CTL instead. the parameters are the same
|
|||
as for SND_SOC_DAPM_MIXER.
|
||||
|
||||
|
||||
2.3 Machine domain Widgets
|
||||
--------------------------
|
||||
Machine domain Widgets
|
||||
----------------------
|
||||
|
||||
Machine widgets are different from codec widgets in that they don't have a
|
||||
codec register bit associated with them. A machine widget is assigned to each
|
||||
machine audio component (non codec or DSP) that can be independently
|
||||
powered. e.g.
|
||||
|
||||
o Speaker Amp
|
||||
o Microphone Bias
|
||||
o Jack connectors
|
||||
* Speaker Amp
|
||||
* Microphone Bias
|
||||
* Jack connectors
|
||||
|
||||
A machine widget can have an optional call back.
|
||||
|
||||
e.g. Jack connector widget for an external Mic that enables Mic Bias
|
||||
when the Mic is inserted:-
|
||||
when the Mic is inserted:-::
|
||||
|
||||
static int spitz_mic_bias(struct snd_soc_dapm_widget* w, int event)
|
||||
{
|
||||
static int spitz_mic_bias(struct snd_soc_dapm_widget* w, int event)
|
||||
{
|
||||
gpio_set_value(SPITZ_GPIO_MIC_BIAS, SND_SOC_DAPM_EVENT_ON(event));
|
||||
return 0;
|
||||
}
|
||||
}
|
||||
|
||||
SND_SOC_DAPM_MIC("Mic Jack", spitz_mic_bias),
|
||||
SND_SOC_DAPM_MIC("Mic Jack", spitz_mic_bias),
|
||||
|
||||
|
||||
2.4 Codec (BIAS) Domain
|
||||
-----------------------
|
||||
Codec (BIAS) Domain
|
||||
-------------------
|
||||
|
||||
The codec bias power domain has no widgets and is handled by the codecs DAPM
|
||||
event handler. This handler is called when the codec powerstate is changed wrt
|
||||
to any stream event or by kernel PM events.
|
||||
|
||||
|
||||
2.5 Virtual Widgets
|
||||
-------------------
|
||||
Virtual Widgets
|
||||
---------------
|
||||
|
||||
Sometimes widgets exist in the codec or machine audio map that don't have any
|
||||
corresponding soft power control. In this case it is necessary to create
|
||||
a virtual widget - a widget with no control bits e.g.
|
||||
::
|
||||
|
||||
SND_SOC_DAPM_MIXER("AC97 Mixer", SND_SOC_DAPM_NOPM, 0, 0, NULL, 0),
|
||||
SND_SOC_DAPM_MIXER("AC97 Mixer", SND_SOC_DAPM_NOPM, 0, 0, NULL, 0),
|
||||
|
||||
This can be used to merge to signal paths together in software.
|
||||
|
||||
|
|
@ -186,8 +224,8 @@ After all the widgets have been defined, they can then be added to the DAPM
|
|||
subsystem individually with a call to snd_soc_dapm_new_control().
|
||||
|
||||
|
||||
3. Codec/DSP Widget Interconnections
|
||||
====================================
|
||||
Codec/DSP Widget Interconnections
|
||||
=================================
|
||||
|
||||
Widgets are connected to each other within the codec, platform and machine by
|
||||
audio paths (called interconnections). Each interconnection must be defined in
|
||||
|
|
@ -201,13 +239,14 @@ e.g., from the WM8731 output mixer (wm8731.c)
|
|||
|
||||
The WM8731 output mixer has 3 inputs (sources)
|
||||
|
||||
1. Line Bypass Input
|
||||
2. DAC (HiFi playback)
|
||||
3. Mic Sidetone Input
|
||||
1. Line Bypass Input
|
||||
2. DAC (HiFi playback)
|
||||
3. Mic Sidetone Input
|
||||
|
||||
Each input in this example has a kcontrol associated with it (defined in example
|
||||
above) and is connected to the output mixer via its kcontrol name. We can now
|
||||
connect the destination widget (wrt audio signal) with its source widgets.
|
||||
::
|
||||
|
||||
/* output mixer */
|
||||
{"Output Mixer", "Line Bypass Switch", "Line Input"},
|
||||
|
|
@ -216,22 +255,17 @@ connect the destination widget (wrt audio signal) with its source widgets.
|
|||
|
||||
So we have :-
|
||||
|
||||
Destination Widget <=== Path Name <=== Source Widget
|
||||
|
||||
Or:-
|
||||
|
||||
Sink, Path, Source
|
||||
|
||||
Or :-
|
||||
|
||||
"Output Mixer" is connected to the "DAC" via the "HiFi Playback Switch".
|
||||
* Destination Widget <=== Path Name <=== Source Widget, or
|
||||
* Sink, Path, Source, or
|
||||
* ``Output Mixer`` is connected to the ``DAC`` via the ``HiFi Playback Switch``.
|
||||
|
||||
When there is no path name connecting widgets (e.g. a direct connection) we
|
||||
pass NULL for the path name.
|
||||
|
||||
Interconnections are created with a call to:-
|
||||
::
|
||||
|
||||
snd_soc_dapm_connect_input(codec, sink, path, source);
|
||||
snd_soc_dapm_connect_input(codec, sink, path, source);
|
||||
|
||||
Finally, snd_soc_dapm_new_widgets(codec) must be called after all widgets and
|
||||
interconnections have been registered with the core. This causes the core to
|
||||
|
|
@ -239,12 +273,13 @@ scan the codec and machine so that the internal DAPM state matches the
|
|||
physical state of the machine.
|
||||
|
||||
|
||||
3.1 Machine Widget Interconnections
|
||||
-----------------------------------
|
||||
Machine Widget Interconnections
|
||||
-------------------------------
|
||||
Machine widget interconnections are created in the same way as codec ones and
|
||||
directly connect the codec pins to machine level widgets.
|
||||
|
||||
e.g. connects the speaker out codec pins to the internal speaker.
|
||||
::
|
||||
|
||||
/* ext speaker connected to codec pins LOUT2, ROUT2 */
|
||||
{"Ext Spk", NULL , "ROUT2"},
|
||||
|
|
@ -254,52 +289,54 @@ This allows the DAPM to power on and off pins that are connected (and in use)
|
|||
and pins that are NC respectively.
|
||||
|
||||
|
||||
4 Endpoint Widgets
|
||||
===================
|
||||
Endpoint Widgets
|
||||
================
|
||||
An endpoint is a start or end point (widget) of an audio signal within the
|
||||
machine and includes the codec. e.g.
|
||||
|
||||
o Headphone Jack
|
||||
o Internal Speaker
|
||||
o Internal Mic
|
||||
o Mic Jack
|
||||
o Codec Pins
|
||||
* Headphone Jack
|
||||
* Internal Speaker
|
||||
* Internal Mic
|
||||
* Mic Jack
|
||||
* Codec Pins
|
||||
|
||||
Endpoints are added to the DAPM graph so that their usage can be determined in
|
||||
order to save power. e.g. NC codecs pins will be switched OFF, unconnected
|
||||
jacks can also be switched OFF.
|
||||
|
||||
|
||||
5 DAPM Widget Events
|
||||
====================
|
||||
DAPM Widget Events
|
||||
==================
|
||||
|
||||
Some widgets can register their interest with the DAPM core in PM events.
|
||||
e.g. A Speaker with an amplifier registers a widget so the amplifier can be
|
||||
powered only when the spk is in use.
|
||||
::
|
||||
|
||||
/* turn speaker amplifier on/off depending on use */
|
||||
static int corgi_amp_event(struct snd_soc_dapm_widget *w, int event)
|
||||
{
|
||||
/* turn speaker amplifier on/off depending on use */
|
||||
static int corgi_amp_event(struct snd_soc_dapm_widget *w, int event)
|
||||
{
|
||||
gpio_set_value(CORGI_GPIO_APM_ON, SND_SOC_DAPM_EVENT_ON(event));
|
||||
return 0;
|
||||
}
|
||||
}
|
||||
|
||||
/* corgi machine dapm widgets */
|
||||
static const struct snd_soc_dapm_widget wm8731_dapm_widgets =
|
||||
/* corgi machine dapm widgets */
|
||||
static const struct snd_soc_dapm_widget wm8731_dapm_widgets =
|
||||
SND_SOC_DAPM_SPK("Ext Spk", corgi_amp_event);
|
||||
|
||||
Please see soc-dapm.h for all other widgets that support events.
|
||||
|
||||
|
||||
5.1 Event types
|
||||
---------------
|
||||
Event types
|
||||
-----------
|
||||
|
||||
The following event types are supported by event widgets.
|
||||
::
|
||||
|
||||
/* dapm event types */
|
||||
#define SND_SOC_DAPM_PRE_PMU 0x1 /* before widget power up */
|
||||
#define SND_SOC_DAPM_POST_PMU 0x2 /* after widget power up */
|
||||
#define SND_SOC_DAPM_PRE_PMD 0x4 /* before widget power down */
|
||||
#define SND_SOC_DAPM_POST_PMD 0x8 /* after widget power down */
|
||||
#define SND_SOC_DAPM_PRE_REG 0x10 /* before audio path setup */
|
||||
#define SND_SOC_DAPM_POST_REG 0x20 /* after audio path setup */
|
||||
/* dapm event types */
|
||||
#define SND_SOC_DAPM_PRE_PMU 0x1 /* before widget power up */
|
||||
#define SND_SOC_DAPM_POST_PMU 0x2 /* after widget power up */
|
||||
#define SND_SOC_DAPM_PRE_PMD 0x4 /* before widget power down */
|
||||
#define SND_SOC_DAPM_POST_PMD 0x8 /* after widget power down */
|
||||
#define SND_SOC_DAPM_PRE_REG 0x10 /* before audio path setup */
|
||||
#define SND_SOC_DAPM_POST_REG 0x20 /* after audio path setup */
|
||||
|
|
@ -1,8 +1,9 @@
|
|||
===========
|
||||
Dynamic PCM
|
||||
===========
|
||||
|
||||
1. Description
|
||||
==============
|
||||
Description
|
||||
===========
|
||||
|
||||
Dynamic PCM allows an ALSA PCM device to digitally route its PCM audio to
|
||||
various digital endpoints during the PCM stream runtime. e.g. PCM0 can route
|
||||
|
|
@ -23,22 +24,23 @@ Phone Audio System with SoC based DSP
|
|||
|
||||
Consider the following phone audio subsystem. This will be used in this
|
||||
document for all examples :-
|
||||
::
|
||||
|
||||
| Front End PCMs | SoC DSP | Back End DAIs | Audio devices |
|
||||
|
||||
*************
|
||||
PCM0 <------------> * * <----DAI0-----> Codec Headset
|
||||
* *
|
||||
PCM1 <------------> * * <----DAI1-----> Codec Speakers
|
||||
* DSP *
|
||||
PCM2 <------------> * * <----DAI2-----> MODEM
|
||||
* *
|
||||
PCM3 <------------> * * <----DAI3-----> BT
|
||||
* *
|
||||
* * <----DAI4-----> DMIC
|
||||
* *
|
||||
* * <----DAI5-----> FM
|
||||
*************
|
||||
| Front End PCMs | SoC DSP | Back End DAIs | Audio devices |
|
||||
|
||||
*************
|
||||
PCM0 <------------> * * <----DAI0-----> Codec Headset
|
||||
* *
|
||||
PCM1 <------------> * * <----DAI1-----> Codec Speakers
|
||||
* DSP *
|
||||
PCM2 <------------> * * <----DAI2-----> MODEM
|
||||
* *
|
||||
PCM3 <------------> * * <----DAI3-----> BT
|
||||
* *
|
||||
* * <----DAI4-----> DMIC
|
||||
* *
|
||||
* * <----DAI5-----> FM
|
||||
*************
|
||||
|
||||
This diagram shows a simple smart phone audio subsystem. It supports Bluetooth,
|
||||
FM digital radio, Speakers, Headset Jack, digital microphones and cellular
|
||||
|
|
@ -55,50 +57,52 @@ Audio is being played to the Headset. After a while the user removes the headset
|
|||
and audio continues playing on the speakers.
|
||||
|
||||
Playback on PCM0 to Headset would look like :-
|
||||
::
|
||||
|
||||
*************
|
||||
PCM0 <============> * * <====DAI0=====> Codec Headset
|
||||
* *
|
||||
PCM1 <------------> * * <----DAI1-----> Codec Speakers
|
||||
* DSP *
|
||||
PCM2 <------------> * * <----DAI2-----> MODEM
|
||||
* *
|
||||
PCM3 <------------> * * <----DAI3-----> BT
|
||||
* *
|
||||
* * <----DAI4-----> DMIC
|
||||
* *
|
||||
* * <----DAI5-----> FM
|
||||
*************
|
||||
*************
|
||||
PCM0 <============> * * <====DAI0=====> Codec Headset
|
||||
* *
|
||||
PCM1 <------------> * * <----DAI1-----> Codec Speakers
|
||||
* DSP *
|
||||
PCM2 <------------> * * <----DAI2-----> MODEM
|
||||
* *
|
||||
PCM3 <------------> * * <----DAI3-----> BT
|
||||
* *
|
||||
* * <----DAI4-----> DMIC
|
||||
* *
|
||||
* * <----DAI5-----> FM
|
||||
*************
|
||||
|
||||
The headset is removed from the jack by user so the speakers must now be used :-
|
||||
::
|
||||
|
||||
*************
|
||||
PCM0 <============> * * <----DAI0-----> Codec Headset
|
||||
* *
|
||||
PCM1 <------------> * * <====DAI1=====> Codec Speakers
|
||||
* DSP *
|
||||
PCM2 <------------> * * <----DAI2-----> MODEM
|
||||
* *
|
||||
PCM3 <------------> * * <----DAI3-----> BT
|
||||
* *
|
||||
* * <----DAI4-----> DMIC
|
||||
* *
|
||||
* * <----DAI5-----> FM
|
||||
*************
|
||||
*************
|
||||
PCM0 <============> * * <----DAI0-----> Codec Headset
|
||||
* *
|
||||
PCM1 <------------> * * <====DAI1=====> Codec Speakers
|
||||
* DSP *
|
||||
PCM2 <------------> * * <----DAI2-----> MODEM
|
||||
* *
|
||||
PCM3 <------------> * * <----DAI3-----> BT
|
||||
* *
|
||||
* * <----DAI4-----> DMIC
|
||||
* *
|
||||
* * <----DAI5-----> FM
|
||||
*************
|
||||
|
||||
The audio driver processes this as follows :-
|
||||
|
||||
1) Machine driver receives Jack removal event.
|
||||
1. Machine driver receives Jack removal event.
|
||||
|
||||
2) Machine driver OR audio HAL disables the Headset path.
|
||||
2. Machine driver OR audio HAL disables the Headset path.
|
||||
|
||||
3) DPCM runs the PCM trigger(stop), hw_free(), shutdown() operations on DAI0
|
||||
for headset since the path is now disabled.
|
||||
3. DPCM runs the PCM trigger(stop), hw_free(), shutdown() operations on DAI0
|
||||
for headset since the path is now disabled.
|
||||
|
||||
4) Machine driver or audio HAL enables the speaker path.
|
||||
4. Machine driver or audio HAL enables the speaker path.
|
||||
|
||||
5) DPCM runs the PCM ops for startup(), hw_params(), prepapre() and
|
||||
trigger(start) for DAI1 Speakers since the path is enabled.
|
||||
5. DPCM runs the PCM ops for startup(), hw_params(), prepapre() and
|
||||
trigger(start) for DAI1 Speakers since the path is enabled.
|
||||
|
||||
In this example, the machine driver or userspace audio HAL can alter the routing
|
||||
and then DPCM will take care of managing the DAI PCM operations to either bring
|
||||
|
|
@ -112,36 +116,38 @@ DPCM machine driver
|
|||
The DPCM enabled ASoC machine driver is similar to normal machine drivers
|
||||
except that we also have to :-
|
||||
|
||||
1) Define the FE and BE DAI links.
|
||||
1. Define the FE and BE DAI links.
|
||||
|
||||
2) Define any FE/BE PCM operations.
|
||||
2. Define any FE/BE PCM operations.
|
||||
|
||||
3) Define widget graph connections.
|
||||
3. Define widget graph connections.
|
||||
|
||||
|
||||
1 FE and BE DAI links
|
||||
---------------------
|
||||
FE and BE DAI links
|
||||
-------------------
|
||||
::
|
||||
|
||||
| Front End PCMs | SoC DSP | Back End DAIs | Audio devices |
|
||||
|
||||
*************
|
||||
PCM0 <------------> * * <----DAI0-----> Codec Headset
|
||||
* *
|
||||
PCM1 <------------> * * <----DAI1-----> Codec Speakers
|
||||
* DSP *
|
||||
PCM2 <------------> * * <----DAI2-----> MODEM
|
||||
* *
|
||||
PCM3 <------------> * * <----DAI3-----> BT
|
||||
* *
|
||||
* * <----DAI4-----> DMIC
|
||||
* *
|
||||
* * <----DAI5-----> FM
|
||||
*************
|
||||
| Front End PCMs | SoC DSP | Back End DAIs | Audio devices |
|
||||
|
||||
*************
|
||||
PCM0 <------------> * * <----DAI0-----> Codec Headset
|
||||
* *
|
||||
PCM1 <------------> * * <----DAI1-----> Codec Speakers
|
||||
* DSP *
|
||||
PCM2 <------------> * * <----DAI2-----> MODEM
|
||||
* *
|
||||
PCM3 <------------> * * <----DAI3-----> BT
|
||||
* *
|
||||
* * <----DAI4-----> DMIC
|
||||
* *
|
||||
* * <----DAI5-----> FM
|
||||
*************
|
||||
|
||||
For the example above we have to define 4 FE DAI links and 6 BE DAI links. The
|
||||
FE DAI links are defined as follows :-
|
||||
::
|
||||
|
||||
static struct snd_soc_dai_link machine_dais[] = {
|
||||
static struct snd_soc_dai_link machine_dais[] = {
|
||||
{
|
||||
.name = "PCM0 System",
|
||||
.stream_name = "System Playback",
|
||||
|
|
@ -154,11 +160,11 @@ static struct snd_soc_dai_link machine_dais[] = {
|
|||
.dpcm_playback = 1,
|
||||
},
|
||||
.....< other FE and BE DAI links here >
|
||||
};
|
||||
};
|
||||
|
||||
This FE DAI link is pretty similar to a regular DAI link except that we also
|
||||
set the DAI link to a DPCM FE with the "dynamic = 1". The supported FE stream
|
||||
directions should also be set with the "dpcm_playback" and "dpcm_capture"
|
||||
set the DAI link to a DPCM FE with the ``dynamic = 1``. The supported FE stream
|
||||
directions should also be set with the ``dpcm_playback`` and ``dpcm_capture``
|
||||
flags. There is also an option to specify the ordering of the trigger call for
|
||||
each FE. This allows the ASoC core to trigger the DSP before or after the other
|
||||
components (as some DSPs have strong requirements for the ordering DAI/DSP
|
||||
|
|
@ -168,8 +174,9 @@ The FE DAI above sets the codec and code DAIs to dummy devices since the BE is
|
|||
dynamic and will change depending on runtime config.
|
||||
|
||||
The BE DAIs are configured as follows :-
|
||||
::
|
||||
|
||||
static struct snd_soc_dai_link machine_dais[] = {
|
||||
static struct snd_soc_dai_link machine_dais[] = {
|
||||
.....< FE DAI links here >
|
||||
{
|
||||
.name = "Codec Headset",
|
||||
|
|
@ -186,29 +193,30 @@ static struct snd_soc_dai_link machine_dais[] = {
|
|||
.dpcm_capture = 1,
|
||||
},
|
||||
.....< other BE DAI links here >
|
||||
};
|
||||
};
|
||||
|
||||
This BE DAI link connects DAI0 to the codec (in this case RT5460 AIF1). It sets
|
||||
the "no_pcm" flag to mark it has a BE and sets flags for supported stream
|
||||
directions using "dpcm_playback" and "dpcm_capture" above.
|
||||
the ``no_pcm`` flag to mark it has a BE and sets flags for supported stream
|
||||
directions using ``dpcm_playback`` and ``dpcm_capture`` above.
|
||||
|
||||
The BE has also flags set for ignoring suspend and PM down time. This allows
|
||||
the BE to work in a hostless mode where the host CPU is not transferring data
|
||||
like a BT phone call :-
|
||||
::
|
||||
|
||||
*************
|
||||
PCM0 <------------> * * <----DAI0-----> Codec Headset
|
||||
* *
|
||||
PCM1 <------------> * * <----DAI1-----> Codec Speakers
|
||||
* DSP *
|
||||
PCM2 <------------> * * <====DAI2=====> MODEM
|
||||
* *
|
||||
PCM3 <------------> * * <====DAI3=====> BT
|
||||
* *
|
||||
* * <----DAI4-----> DMIC
|
||||
* *
|
||||
* * <----DAI5-----> FM
|
||||
*************
|
||||
*************
|
||||
PCM0 <------------> * * <----DAI0-----> Codec Headset
|
||||
* *
|
||||
PCM1 <------------> * * <----DAI1-----> Codec Speakers
|
||||
* DSP *
|
||||
PCM2 <------------> * * <====DAI2=====> MODEM
|
||||
* *
|
||||
PCM3 <------------> * * <====DAI3=====> BT
|
||||
* *
|
||||
* * <----DAI4-----> DMIC
|
||||
* *
|
||||
* * <----DAI5-----> FM
|
||||
*************
|
||||
|
||||
This allows the host CPU to sleep whilst the DSP, MODEM DAI and the BT DAI are
|
||||
still in operation.
|
||||
|
|
@ -220,10 +228,10 @@ Likewise a BE DAI can also set a dummy cpu DAI if the CPU DAI is managed by the
|
|||
DSP firmware.
|
||||
|
||||
|
||||
2 FE/BE PCM operations
|
||||
----------------------
|
||||
FE/BE PCM operations
|
||||
--------------------
|
||||
|
||||
The BE above also exports some PCM operations and a "fixup" callback. The fixup
|
||||
The BE above also exports some PCM operations and a ``fixup`` callback. The fixup
|
||||
callback is used by the machine driver to (re)configure the DAI based upon the
|
||||
FE hw params. i.e. the DSP may perform SRC or ASRC from the FE to BE.
|
||||
|
||||
|
|
@ -231,10 +239,11 @@ e.g. DSP converts all FE hw params to run at fixed rate of 48k, 16bit, stereo fo
|
|||
DAI0. This means all FE hw_params have to be fixed in the machine driver for
|
||||
DAI0 so that the DAI is running at desired configuration regardless of the FE
|
||||
configuration.
|
||||
::
|
||||
|
||||
static int dai0_fixup(struct snd_soc_pcm_runtime *rtd,
|
||||
static int dai0_fixup(struct snd_soc_pcm_runtime *rtd,
|
||||
struct snd_pcm_hw_params *params)
|
||||
{
|
||||
{
|
||||
struct snd_interval *rate = hw_param_interval(params,
|
||||
SNDRV_PCM_HW_PARAM_RATE);
|
||||
struct snd_interval *channels = hw_param_interval(params,
|
||||
|
|
@ -249,21 +258,22 @@ static int dai0_fixup(struct snd_soc_pcm_runtime *rtd,
|
|||
SNDRV_PCM_HW_PARAM_FIRST_MASK],
|
||||
SNDRV_PCM_FORMAT_S16_LE);
|
||||
return 0;
|
||||
}
|
||||
}
|
||||
|
||||
The other PCM operation are the same as for regular DAI links. Use as necessary.
|
||||
|
||||
|
||||
3 Widget graph connections
|
||||
--------------------------
|
||||
Widget graph connections
|
||||
------------------------
|
||||
|
||||
The BE DAI links will normally be connected to the graph at initialisation time
|
||||
by the ASoC DAPM core. However, if the BE codec or BE DAI is a dummy then this
|
||||
has to be set explicitly in the driver :-
|
||||
::
|
||||
|
||||
/* BE for codec Headset - DAI0 is dummy and managed by DSP FW */
|
||||
{"DAI0 CODEC IN", NULL, "AIF1 Capture"},
|
||||
{"AIF1 Playback", NULL, "DAI0 CODEC OUT"},
|
||||
/* BE for codec Headset - DAI0 is dummy and managed by DSP FW */
|
||||
{"DAI0 CODEC IN", NULL, "AIF1 Capture"},
|
||||
{"AIF1 Playback", NULL, "DAI0 CODEC OUT"},
|
||||
|
||||
|
||||
Writing a DPCM DSP driver
|
||||
|
|
@ -273,24 +283,25 @@ The DPCM DSP driver looks much like a standard platform class ASoC driver
|
|||
combined with elements from a codec class driver. A DSP platform driver must
|
||||
implement :-
|
||||
|
||||
1) Front End PCM DAIs - i.e. struct snd_soc_dai_driver.
|
||||
1. Front End PCM DAIs - i.e. struct snd_soc_dai_driver.
|
||||
|
||||
2) DAPM graph showing DSP audio routing from FE DAIs to BEs.
|
||||
2. DAPM graph showing DSP audio routing from FE DAIs to BEs.
|
||||
|
||||
3) DAPM widgets from DSP graph.
|
||||
3. DAPM widgets from DSP graph.
|
||||
|
||||
4) Mixers for gains, routing, etc.
|
||||
4. Mixers for gains, routing, etc.
|
||||
|
||||
5) DMA configuration.
|
||||
5. DMA configuration.
|
||||
|
||||
6) BE AIF widgets.
|
||||
6. BE AIF widgets.
|
||||
|
||||
Items 6 is important for routing the audio outside of the DSP. AIF need to be
|
||||
defined for each BE and each stream direction. e.g for BE DAI0 above we would
|
||||
have :-
|
||||
::
|
||||
|
||||
SND_SOC_DAPM_AIF_IN("DAI0 RX", NULL, 0, SND_SOC_NOPM, 0, 0),
|
||||
SND_SOC_DAPM_AIF_OUT("DAI0 TX", NULL, 0, SND_SOC_NOPM, 0, 0),
|
||||
SND_SOC_DAPM_AIF_IN("DAI0 RX", NULL, 0, SND_SOC_NOPM, 0, 0),
|
||||
SND_SOC_DAPM_AIF_OUT("DAI0 TX", NULL, 0, SND_SOC_NOPM, 0, 0),
|
||||
|
||||
The BE AIF are used to connect the DSP graph to the graphs for the other
|
||||
component drivers (e.g. codec graph).
|
||||
|
|
@ -301,33 +312,33 @@ Hostless PCM streams
|
|||
|
||||
A hostless PCM stream is a stream that is not routed through the host CPU. An
|
||||
example of this would be a phone call from handset to modem.
|
||||
::
|
||||
|
||||
|
||||
*************
|
||||
PCM0 <------------> * * <----DAI0-----> Codec Headset
|
||||
* *
|
||||
PCM1 <------------> * * <====DAI1=====> Codec Speakers/Mic
|
||||
* DSP *
|
||||
PCM2 <------------> * * <====DAI2=====> MODEM
|
||||
* *
|
||||
PCM3 <------------> * * <----DAI3-----> BT
|
||||
* *
|
||||
* * <----DAI4-----> DMIC
|
||||
* *
|
||||
* * <----DAI5-----> FM
|
||||
*************
|
||||
*************
|
||||
PCM0 <------------> * * <----DAI0-----> Codec Headset
|
||||
* *
|
||||
PCM1 <------------> * * <====DAI1=====> Codec Speakers/Mic
|
||||
* DSP *
|
||||
PCM2 <------------> * * <====DAI2=====> MODEM
|
||||
* *
|
||||
PCM3 <------------> * * <----DAI3-----> BT
|
||||
* *
|
||||
* * <----DAI4-----> DMIC
|
||||
* *
|
||||
* * <----DAI5-----> FM
|
||||
*************
|
||||
|
||||
In this case the PCM data is routed via the DSP. The host CPU in this use case
|
||||
is only used for control and can sleep during the runtime of the stream.
|
||||
|
||||
The host can control the hostless link either by :-
|
||||
|
||||
1) Configuring the link as a CODEC <-> CODEC style link. In this case the link
|
||||
1. Configuring the link as a CODEC <-> CODEC style link. In this case the link
|
||||
is enabled or disabled by the state of the DAPM graph. This usually means
|
||||
there is a mixer control that can be used to connect or disconnect the path
|
||||
between both DAIs.
|
||||
|
||||
2) Hostless FE. This FE has a virtual connection to the BE DAI links on the DAPM
|
||||
2. Hostless FE. This FE has a virtual connection to the BE DAI links on the DAPM
|
||||
graph. Control is then carried out by the FE as regular PCM operations.
|
||||
This method gives more control over the DAI links, but requires much more
|
||||
userspace code to control the link. Its recommended to use CODEC<->CODEC
|
||||
|
|
@ -339,16 +350,17 @@ CODEC <-> CODEC link
|
|||
|
||||
This DAI link is enabled when DAPM detects a valid path within the DAPM graph.
|
||||
The machine driver sets some additional parameters to the DAI link i.e.
|
||||
::
|
||||
|
||||
static const struct snd_soc_pcm_stream dai_params = {
|
||||
static const struct snd_soc_pcm_stream dai_params = {
|
||||
.formats = SNDRV_PCM_FMTBIT_S32_LE,
|
||||
.rate_min = 8000,
|
||||
.rate_max = 8000,
|
||||
.channels_min = 2,
|
||||
.channels_max = 2,
|
||||
};
|
||||
};
|
||||
|
||||
static struct snd_soc_dai_link dais[] = {
|
||||
static struct snd_soc_dai_link dais[] = {
|
||||
< ... more DAI links above ... >
|
||||
{
|
||||
.name = "MODEM",
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
==============
|
||||
ALSA SoC Layer
|
||||
==============
|
||||
|
||||
The documentation is spilt into the following sections:-
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
overview
|
||||
codec
|
||||
dai
|
||||
dapm
|
||||
platform
|
||||
machine
|
||||
pops-clicks
|
||||
clocking
|
||||
jack
|
||||
dpcm
|
||||
codec-to-codec
|
||||
|
|
@ -1,3 +1,4 @@
|
|||
===================
|
||||
ASoC jack detection
|
||||
===================
|
||||
|
||||
|
|
@ -1,3 +1,4 @@
|
|||
===================
|
||||
ASoC Machine Driver
|
||||
===================
|
||||
|
||||
|
|
@ -9,9 +10,10 @@ interrupts, clocking, jacks and voltage regulators.
|
|||
The machine driver can contain codec and platform specific code. It registers
|
||||
the audio subsystem with the kernel as a platform device and is represented by
|
||||
the following struct:-
|
||||
::
|
||||
|
||||
/* SoC machine */
|
||||
struct snd_soc_card {
|
||||
/* SoC machine */
|
||||
struct snd_soc_card {
|
||||
char *name;
|
||||
|
||||
...
|
||||
|
|
@ -33,7 +35,7 @@ struct snd_soc_card {
|
|||
int num_links;
|
||||
|
||||
...
|
||||
};
|
||||
};
|
||||
|
||||
probe()/remove()
|
||||
----------------
|
||||
|
|
@ -55,9 +57,10 @@ initialisation e.g. the machine audio map can be connected to the codec audio
|
|||
map, unconnected codec pins can be set as such.
|
||||
|
||||
struct snd_soc_dai_link is used to set up each DAI in your machine. e.g.
|
||||
::
|
||||
|
||||
/* corgi digital audio interface glue - connects codec <--> CPU */
|
||||
static struct snd_soc_dai_link corgi_dai = {
|
||||
/* corgi digital audio interface glue - connects codec <--> CPU */
|
||||
static struct snd_soc_dai_link corgi_dai = {
|
||||
.name = "WM8731",
|
||||
.stream_name = "WM8731",
|
||||
.cpu_dai_name = "pxa-is2-dai",
|
||||
|
|
@ -66,16 +69,17 @@ static struct snd_soc_dai_link corgi_dai = {
|
|||
.codec_name = "wm8713-codec.0-001a",
|
||||
.init = corgi_wm8731_init,
|
||||
.ops = &corgi_ops,
|
||||
};
|
||||
};
|
||||
|
||||
struct snd_soc_card then sets up the machine with its DAIs. e.g.
|
||||
::
|
||||
|
||||
/* corgi audio machine driver */
|
||||
static struct snd_soc_card snd_soc_corgi = {
|
||||
/* corgi audio machine driver */
|
||||
static struct snd_soc_card snd_soc_corgi = {
|
||||
.name = "Corgi",
|
||||
.dai_link = &corgi_dai,
|
||||
.num_links = 1,
|
||||
};
|
||||
};
|
||||
|
||||
|
||||
Machine Power Map
|
||||
|
|
@ -1,5 +1,6 @@
|
|||
ALSA SoC Layer
|
||||
==============
|
||||
=======================
|
||||
ALSA SoC Layer Overview
|
||||
=======================
|
||||
|
||||
The overall project goal of the ALSA System on Chip (ASoC) layer is to
|
||||
provide better ALSA support for embedded system-on-chip processors (e.g.
|
||||
|
|
@ -66,30 +67,3 @@ multiple re-usable component drivers :-
|
|||
describes and binds the other component drivers together to form an ALSA
|
||||
"sound card device". It handles any machine specific controls and
|
||||
machine level audio events (e.g. turning on an amp at start of playback).
|
||||
|
||||
|
||||
Documentation
|
||||
=============
|
||||
|
||||
The documentation is spilt into the following sections:-
|
||||
|
||||
overview.txt: This file.
|
||||
|
||||
codec.txt: Codec driver internals.
|
||||
|
||||
DAI.txt: Description of Digital Audio Interface standards and how to configure
|
||||
a DAI within your codec and CPU DAI drivers.
|
||||
|
||||
dapm.txt: Dynamic Audio Power Management
|
||||
|
||||
platform.txt: Platform audio DMA and DAI.
|
||||
|
||||
machine.txt: Machine driver internals.
|
||||
|
||||
pop_clicks.txt: How to minimise audio artifacts.
|
||||
|
||||
clocking.txt: ASoC clocking for best power performance.
|
||||
|
||||
jack.txt: ASoC jack detection.
|
||||
|
||||
DPCM.txt: Dynamic PCM - Describes DPCM with DSP examples.
|
||||
|
|
@ -1,3 +1,4 @@
|
|||
====================
|
||||
ASoC Platform Driver
|
||||
====================
|
||||
|
||||
|
|
@ -9,21 +10,23 @@ Audio DMA
|
|||
=========
|
||||
|
||||
The platform DMA driver optionally supports the following ALSA operations:-
|
||||
::
|
||||
|
||||
/* SoC audio ops */
|
||||
struct snd_soc_ops {
|
||||
/* SoC audio ops */
|
||||
struct snd_soc_ops {
|
||||
int (*startup)(struct snd_pcm_substream *);
|
||||
void (*shutdown)(struct snd_pcm_substream *);
|
||||
int (*hw_params)(struct snd_pcm_substream *, struct snd_pcm_hw_params *);
|
||||
int (*hw_free)(struct snd_pcm_substream *);
|
||||
int (*prepare)(struct snd_pcm_substream *);
|
||||
int (*trigger)(struct snd_pcm_substream *, int);
|
||||
};
|
||||
};
|
||||
|
||||
The platform driver exports its DMA functionality via struct
|
||||
snd_soc_platform_driver:-
|
||||
::
|
||||
|
||||
struct snd_soc_platform_driver {
|
||||
struct snd_soc_platform_driver {
|
||||
char *name;
|
||||
|
||||
int (*probe)(struct platform_device *pdev);
|
||||
|
|
@ -44,7 +47,7 @@ struct snd_soc_platform_driver {
|
|||
|
||||
/* platform stream ops */
|
||||
struct snd_pcm_ops *pcm_ops;
|
||||
};
|
||||
};
|
||||
|
||||
Please refer to the ALSA driver documentation for details of audio DMA.
|
||||
http://www.alsa-project.org/~iwai/writing-an-alsa-driver/
|
||||
|
|
@ -57,11 +60,11 @@ SoC DAI Drivers
|
|||
|
||||
Each SoC DAI driver must provide the following features:-
|
||||
|
||||
1) Digital audio interface (DAI) description
|
||||
2) Digital audio interface configuration
|
||||
3) PCM's description
|
||||
4) SYSCLK configuration
|
||||
5) Suspend and resume (optional)
|
||||
1. Digital audio interface (DAI) description
|
||||
2. Digital audio interface configuration
|
||||
3. PCM's description
|
||||
4. SYSCLK configuration
|
||||
5. Suspend and resume (optional)
|
||||
|
||||
Please see codec.txt for a description of items 1 - 4.
|
||||
|
||||
|
|
@ -71,9 +74,9 @@ SoC DSP Drivers
|
|||
|
||||
Each SoC DSP driver usually supplies the following features :-
|
||||
|
||||
1) DAPM graph
|
||||
2) Mixer controls
|
||||
3) DMA IO to/from DSP buffers (if applicable)
|
||||
4) Definition of DSP front end (FE) PCM devices.
|
||||
1. DAPM graph
|
||||
2. Mixer controls
|
||||
3. DMA IO to/from DSP buffers (if applicable)
|
||||
4. Definition of DSP front end (FE) PCM devices.
|
||||
|
||||
Please see DPCM.txt for a description of item 4.
|
||||
|
|
@ -1,3 +1,4 @@
|
|||
=====================
|
||||
Audio Pops and Clicks
|
||||
=====================
|
||||
|
||||
|
|
@ -20,10 +21,11 @@ currently, however future audio codec hardware will have better pop and click
|
|||
suppression. Pops can be reduced within playback by powering the audio
|
||||
components in a specific order. This order is different for startup and
|
||||
shutdown and follows some basic rules:-
|
||||
::
|
||||
|
||||
Startup Order :- DAC --> Mixers --> Output PGA --> Digital Unmute
|
||||
|
||||
Shutdown Order :- Digital Mute --> Output PGA --> Mixers --> DAC
|
||||
Startup Order :- DAC --> Mixers --> Output PGA --> Digital Unmute
|
||||
|
||||
Shutdown Order :- Digital Mute --> Output PGA --> Mixers --> DAC
|
||||
|
||||
This assumes that the codec PCM output path from the DAC is via a mixer and then
|
||||
a PGA (programmable gain amplifier) before being output to the speakers.
|
||||
|
|
@ -36,10 +38,11 @@ Capture artifacts are somewhat easier to get rid as we can delay activating the
|
|||
ADC until all the pops have occurred. This follows similar power rules to
|
||||
playback in that components are powered in a sequence depending upon stream
|
||||
startup or shutdown.
|
||||
::
|
||||
|
||||
Startup Order - Input PGA --> Mixers --> ADC
|
||||
|
||||
Shutdown Order - ADC --> Mixers --> Input PGA
|
||||
Startup Order - Input PGA --> Mixers --> ADC
|
||||
|
||||
Shutdown Order - ADC --> Mixers --> Input PGA
|
||||
|
||||
|
||||
Zipper Noise
|
||||
Загрузка…
Ссылка в новой задаче