diff options
Diffstat (limited to 'Documentation/sound/alsa')
| -rw-r--r-- | Documentation/sound/alsa/ALSA-Configuration.txt | 9 | ||||
| -rw-r--r-- | Documentation/sound/alsa/HD-Audio-DP-MST-audio.txt | 74 | ||||
| -rw-r--r-- | Documentation/sound/alsa/HD-Audio.txt | 26 | ||||
| -rw-r--r-- | Documentation/sound/alsa/compress_offload.txt | 4 | ||||
| -rw-r--r-- | Documentation/sound/alsa/soc/dapm.txt | 2 | ||||
| -rw-r--r-- | Documentation/sound/alsa/soc/machine.txt | 2 | ||||
| -rw-r--r-- | Documentation/sound/alsa/soc/overview.txt | 2 | ||||
| -rw-r--r-- | Documentation/sound/alsa/timestamping.txt | 14 |
8 files changed, 103 insertions, 30 deletions
diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 5a8583abe..70095a329 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -1901,6 +1901,12 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. - Default: 0x0000 ignore_ctl_error - Ignore any USB-controller regarding mixer interface (default: no) + autoclock - Enable auto-clock selection for UAC2 devices + (default: yes) + quirk_alias - Quirk alias list, pass strings like + "0123abcd:5678beef", which applies the existing + quirk for the device 5678:beef to a new device + 0123:abcd. This module supports multiple devices, autoprobe and hotplugging. @@ -1910,6 +1916,9 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. NB: ignore_ctl_error=1 may help when you get an error at accessing the mixer element such as URB error -22. This happens on some buggy USB device or the controller. + NB: quirk_alias option is provided only for testing / development. + If you want to have a proper support, contact to upstream for + adding the matching quirk in the driver code statically. Module snd-usb-caiaq -------------------- diff --git a/Documentation/sound/alsa/HD-Audio-DP-MST-audio.txt b/Documentation/sound/alsa/HD-Audio-DP-MST-audio.txt new file mode 100644 index 000000000..82744ac35 --- /dev/null +++ b/Documentation/sound/alsa/HD-Audio-DP-MST-audio.txt @@ -0,0 +1,74 @@ +To support DP MST audio, HD Audio hdmi codec driver introduces virtual pin +and dynamic pcm assignment. + +Virtual pin is an extension of per_pin. The most difference of DP MST +from legacy is that DP MST introduces device entry. Each pin can contain +several device entries. Each device entry behaves as a pin. + +As each pin may contain several device entries and each codec may contain +several pins, if we use one pcm per per_pin, there will be many PCMs. +The new solution is to create a few PCMs and to dynamically bind pcm to +per_pin. Driver uses spec->dyn_pcm_assign flag to indicate whether to use +the new solution. + +PCM +=== +To be added + + +Jack +==== + +Presume: + - MST must be dyn_pcm_assign, and it is acomp (for Intel scenario); + - NON-MST may or may not be dyn_pcm_assign, it can be acomp or !acomp; + +So there are the following scenarios: + a. MST (&& dyn_pcm_assign && acomp) + b. NON-MST && dyn_pcm_assign && acomp + c. NON-MST && !dyn_pcm_assign && !acomp + +Below discussion will ignore MST and NON-MST difference as it doesn't +impact on jack handling too much. + +Driver uses struct hdmi_pcm pcm[] array in hdmi_spec and snd_jack is +a member of hdmi_pcm. Each pin has one struct hdmi_pcm * pcm pointer. + +For !dyn_pcm_assign, per_pin->pcm will assigned to spec->pcm[n] statically. + +For dyn_pcm_assign, per_pin->pcm will assigned to spec->pcm[n] +when monitor is hotplugged. + + +Build Jack +---------- + +- dyn_pcm_assign +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. + + +Unsolicited Event Enabling +-------------------------- +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 + +- !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. + + +Others to be added later +======================== diff --git a/Documentation/sound/alsa/HD-Audio.txt b/Documentation/sound/alsa/HD-Audio.txt index e7193aac6..d4510ebf2 100644 --- a/Documentation/sound/alsa/HD-Audio.txt +++ b/Documentation/sound/alsa/HD-Audio.txt @@ -655,17 +655,6 @@ development branches in general while the development for the current and next kernels are found in for-linus and for-next branches, respectively. -If you are using the latest Linus tree, it'd be better to pull the -above GIT tree onto it. If you are using the older kernels, an easy -way to try the latest ALSA code is to build from the snapshot -tarball. There are daily tarballs and the latest snapshot tarball. -All can be built just like normal alsa-driver release packages, that -is, installed via the usual spells: configure, make and make -install(-modules). See INSTALL in the package. The snapshot tarballs -are found at: - -- ftp://ftp.suse.com/pub/people/tiwai/snapshot/ - Sending a Bug Report ~~~~~~~~~~~~~~~~~~~~ @@ -699,7 +688,12 @@ problems. alsa-info ~~~~~~~~~ The script `alsa-info.sh` is a very useful tool to gather the audio -device information. You can fetch the latest version from: +device information. It's included in alsa-utils package. The latest +version can be found on git repository: + +- git://git.alsa-project.org/alsa-utils.git + +The script can be fetched directly from the following URL, too: - http://www.alsa-project.org/alsa-info.sh @@ -836,15 +830,11 @@ can get a proc-file dump at the current state, get a list of control (mixer) elements, set/get the control element value, simulate the PCM operation, the jack plugging simulation, etc. -The package is found in: - -- ftp://ftp.suse.com/pub/people/tiwai/misc/ - -A git repository is available: +The program is found in the git repository below: - git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/hda-emu.git -See README file in the tarball for more details about hda-emu +See README file in the repository for more details about hda-emu program. diff --git a/Documentation/sound/alsa/compress_offload.txt b/Documentation/sound/alsa/compress_offload.txt index 630c492c3..8ba556a13 100644 --- a/Documentation/sound/alsa/compress_offload.txt +++ b/Documentation/sound/alsa/compress_offload.txt @@ -149,7 +149,7 @@ Gapless Playback ================ When playing thru an album, the decoders have the ability to skip the encoder delay and padding and directly move from one track content to another. The end -user can perceive this as gapless playback as we dont have silence while +user can perceive this as gapless playback as we don't have silence while switching from one track to another Also, there might be low-intensity noises due to encoding. Perfect gapless is @@ -184,7 +184,7 @@ Sequence flow for gapless would be: - Fill data of the first track - Trigger start - User-space finished sending all, -- Indicaite next track data by sending set_next_track +- Indicate next track data by sending set_next_track - Set metadata of the next track - then call partial_drain to flush most of buffer in DSP - Fill data of the next track diff --git a/Documentation/sound/alsa/soc/dapm.txt b/Documentation/sound/alsa/soc/dapm.txt index 6faab4880..c45bd79f2 100644 --- a/Documentation/sound/alsa/soc/dapm.txt +++ b/Documentation/sound/alsa/soc/dapm.txt @@ -132,7 +132,7 @@ 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, ARRAY_SIZE(wm8731_output_mixer_controls)), -If you dont want the mixer elements prefixed with the name of the mixer widget, +If you don't want the mixer elements prefixed with the name of the mixer widget, you can use SND_SOC_DAPM_MIXER_NAMED_CTL instead. the parameters are the same as for SND_SOC_DAPM_MIXER. diff --git a/Documentation/sound/alsa/soc/machine.txt b/Documentation/sound/alsa/soc/machine.txt index 74056dba5..6bf2d2063 100644 --- a/Documentation/sound/alsa/soc/machine.txt +++ b/Documentation/sound/alsa/soc/machine.txt @@ -3,7 +3,7 @@ ASoC Machine Driver The ASoC machine (or board) driver is the code that glues together all the component drivers (e.g. codecs, platforms and DAIs). It also describes the -relationships between each componnent which include audio paths, GPIOs, +relationships between each component which include audio paths, GPIOs, interrupts, clocking, jacks and voltage regulators. The machine driver can contain codec and platform specific code. It registers diff --git a/Documentation/sound/alsa/soc/overview.txt b/Documentation/sound/alsa/soc/overview.txt index ff88f52ee..f3f28b7ae 100644 --- a/Documentation/sound/alsa/soc/overview.txt +++ b/Documentation/sound/alsa/soc/overview.txt @@ -63,7 +63,7 @@ multiple re-usable component drivers :- and any audio DSP drivers for that platform. * Machine class driver: The machine driver class acts as the glue that - decribes and binds the other component drivers together to form an ALSA + 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). diff --git a/Documentation/sound/alsa/timestamping.txt b/Documentation/sound/alsa/timestamping.txt index 0b191a23f..9d579aefb 100644 --- a/Documentation/sound/alsa/timestamping.txt +++ b/Documentation/sound/alsa/timestamping.txt @@ -14,7 +14,7 @@ provides a refined estimate with a delay. event or application query. The difference (tstamp - trigger_tstamp) defines the elapsed time. -The ALSA API provides reports two basic pieces of information, avail +The ALSA API provides two basic pieces of information, avail and delay, which combined with the trigger and current system timestamps allow for applications to keep track of the 'fullness' of the ring buffer and the amount of queued samples. @@ -53,21 +53,21 @@ case): The analog time is taken at the last stage of the playback, as close as possible to the actual transducer -The link time is taken at the output of the SOC/chipset as the samples +The link time is taken at the output of the SoC/chipset as the samples are pushed on a link. The link time can be directly measured if supported in hardware by sample counters or wallclocks (e.g. with HDAudio 24MHz or PTP clock for networked solutions) or indirectly estimated (e.g. with the frame counter in USB). The DMA time is measured using counters - typically the least reliable -of all measurements due to the bursty natured of DMA transfers. +of all measurements due to the bursty nature of DMA transfers. The app time corresponds to the time tracked by an application after writing in the ring buffer. -The application can query what the hardware supports, define which +The application can query the hardware capabilities, define which audio time it wants reported by selecting the relevant settings in -audio_tstamp_config fields, get an estimate of the timestamp +audio_tstamp_config fields, thus get an estimate of the timestamp accuracy. It can also request the delay-to-analog be included in the measurement. Direct access to the link time is very interesting on platforms that provide an embedded DSP; measuring directly the link @@ -129,7 +129,7 @@ will be required to issue multiple queries and perform an interpolation of the results In some hardware-specific configuration, the system timestamp is -latched by a low-level audio subsytem, and the information provided +latched by a low-level audio subsystem, and the information provided back to the driver. Due to potential delays in the communication with the hardware, there is a risk of misalignment with the avail and delay information. To make sure applications are not confused, a @@ -169,7 +169,7 @@ playback: systime: 938107562 nsec, audio time 938112708 nsec, systime delta -51 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 measurement can help define rewind safeguards). Compensating for the -DMA-link delay in example 2 helps remove the hardware buffering abut +DMA-link delay in example 2 helps remove the hardware buffering but the information is still very jittery, with up to one sample of error. In example 3 where the timestamps are measured with the link wallclock, the timestamps show a monotonic behavior and a lower |