- Alsa-devel - mailman.alsa-project.org

Re: [alsa-devel] how do you people debug ALSA?
by mazarick＠bellsouth.net 23 Jan '08

23 Jan '08

"Mihaela Vitalariu" <admiralwolverine(a)gmail.com> wrote: > I meant what tools do you use, what Debuggers? > In my post i wasn't complaining about ALSA, i was just curios about the > debugging tools that you use, from a developer's standpoint... The group that I'm working with (to develop an alsa driver for the Gadget Labs soundcard) would be very interested in any input on this subject. The team is made up of skilled C/C++ coders, but there is very little to no experience with writing a linux hardware driver. It would be fine to say "vi is the development environment, and we sprinkle the code with printk statements and take them out when the soup's done". It would save us a lot of overhead in figuring out the best way to get on the same page with each other since it's a pretty new team. Any other words of wisdom from those who've been there would be very welcomed and appreciated. If you use KDE, Eclipse, or something else, that's fine too. Some particular questions (in no particular order): 1. Do you regularly use the "alsasound" kernel function during development so you can take the driver in and out of the kernel? If it's used, is is used from the beginning or in the last stages of development? (I'm not sure if it's alsasound, sndconfig, etc). 2. Are the process statements given in the 'How-To' (snd_printk, snd_assert, snd_BUG) the main ones or are there others that are 'pre-built' and widely useful? http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/c1696.htm 3. Are there tools that are almost always used when writing a sound card driver like gdb, ddd, etc? 4. Since it's easy to do, is an interface into the proc file system useful from the start? http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/c1493.htm 5. Is the alsa wiki on debugging the sum total of what's needed or is there more we don't know about? (and we don't know that much!!) http://www.alsa-project.org/main/index.php/Driver_Compilation Of course, I could bring up the current Hot and Burning question we have (they are more important now): http://wavepro-driver.svn.sourceforge.net/viewvc/wavepro-driver/ 1. We've having difficulty getting the Altera PLD to load. Any suggestions on how to do this, how people without cards can help, an easy way to know when you are successful, or an incremental approach to the problem? 2. The GL card is powered from an Altera PLD (FPGA) (it has similar function as the Envy ICE chip once it's loaded). For the card to function at all, the Altera PLD has to be loaded when power is applied to the computer. Should the 'load the Altera' function be part of the alsa driver, part of alsa firmware, or should we just load it up when the computer boots (not in alsa)? 3. We're planning on using FC8/PlanetCCRMA as a 'beta test' environment. I've just noticed the new FC8 specific instructions on how to overcome my many bad habits when fooling around with the kernel. I'm putting it here for reference so I don't forget it (like I just did when trying to figure out if it was alsasound, procsound, or whatever to unload the driver). http://fedoraproject.org/wiki/Docs/CustomKernel If you would like to just put your two cents worth in to the very small mailing list (for the next 5 days), send a note to: wavepro-driver-developers(a)lists.sourceforge.net (in 5 days, you'll have to be subscribed to send a note) -Mike Mazarick

4 3

[alsa-devel] alsa-lib(1.0.12) crash
by Cliff Cai 23 Jan '08

23 Jan '08

Hi all, I'm experiencing weird crash of alsa-lib. the sound card has 16/24 bit ADC. The ADC works on 24 bit mode, hw->formats= SNDRV_PCM_FMTBIT_S32_LE,and use 'copy' playback to copy DMA buffer to user space's buffer. I ran: arecord -t wav -c 2 -f U8 -r 8000 -d 5 a.wav then arecord crash with following information: Data access misaligned address violation - Attempted misaligned data memory or data cache access. RETE: /* Maybe null pointer? */ RETN: /* unknown address */ RETX: [ /usr/lib/libasound.so.2 + 0x46da8 ] RETS: [ /usr/lib/libasound.so.2 + 0x46aec ] PC : [ /usr/lib/libasound.so.2 + 0x46da8 ] DCPLB_FAULT_ADDR: [ arecord + 0x2ac ] ICPLB_FAULT_ADDR: [ /usr/lib/libasound.so.2 + 0x46da8 ] Hardware Trace: 0 Target : { _trap_c + 0x0 } Source : { _exception_to_level5 + 0xb4 } 1 Target : { _exception_to_level5 + 0x0 } Source : { _ex_trap_c + 0x5c } 2 Target : { _ex_trap_c + 0x0 } Source : { _trap + 0x28 } 3 Target : { _trap + 0x0 } Source : [ /usr/lib/libasound.so.2 + 0x46da6 ] 4 Target : [ /usr/lib/libasound.so.2 + 0x46d9a ] Source : [ /usr/lib/libasound.so.2 + 0x46b54 ] 5 Target : [ /usr/lib/libasound.so.2 + 0x46b46 ] Source : [ /usr/lib/libasound.so.2 + 0x46b12 ] 6 Target : [ /usr/lib/libasound.so.2 + 0x46aec ] Source : [ /usr/lib/libasound.so.2 + 0x4d16a ] 7 Target : [ /usr/lib/libasound.so.2 + 0x4d166 ] Source : [ /usr/lib/libasound.so.2 + 0x4d17e ] 8 Target : [ /usr/lib/libasound.so.2 + 0x4d17c ] Source : [ /usr/lib/libasound.so.2 + 0x4d0b2 ] 9 Target : [ /usr/lib/libasound.so.2 + 0x4d09c ] Source : [ /usr/lib/libasound.so.2 + 0x278ec ] 10 Target : [ /usr/lib/libasound.so.2 + 0x278e4 ] Source : [ /usr/lib/libasound.so.2 + 0x46ae8 ] 11 Target : [ /usr/lib/libasound.so.2 + 0x46a74 ] Source : [ /usr/lib/libasound.so.2 + 0x28602 ] 12 Target : [ /usr/lib/libasound.so.2 + 0x285fa ] Source : [ /usr/lib/libasound.so.2 + 0x46eac ] 13 Target : [ /usr/lib/libasound.so.2 + 0x46e94 ] Source : [ /usr/lib/libasound.so.2 + 0x46e8a ] 14 Target : [ /usr/lib/libasound.so.2 + 0x46e88 ] Source : [ /usr/lib/libasound.so.2 + 0x46e38 ] 15 Target : [ /usr/lib/libasound.so.2 + 0x46e0e ] Source : [ /usr/lib/libasound.so.2 + 0x4d16a ] Then I modified the driver ,set the ADC to 16bit mode and set hw->formats= SNDRV_PCM_FMTBIT_S16_LE no crash any more. Any idea is appreciated. Thanks a lot in advance! Cliff _________________________________________________________________ 天凉了，添衣了，心动了，“七件”了 http://get.live.cn

3 2

[alsa-devel] [PATCH] ASoC documentation updates
by Mark Brown 23 Jan '08

23 Jan '08

Update the ASoC documentation. Along with minor formatting and grammar cleanups it moves the ASoC overview into the present tense to reflect the fact that it has now been merged. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- Documentation/sound/alsa/soc/DAI.txt | 6 +- Documentation/sound/alsa/soc/clocking.txt | 10 ++-- Documentation/sound/alsa/soc/codec.txt | 53 +++++++++++++------------- Documentation/sound/alsa/soc/dapm.txt | 51 +++++++++++++------------ Documentation/sound/alsa/soc/machine.txt | 12 +++--- Documentation/sound/alsa/soc/overview.txt | 42 +++++++++++---------- Documentation/sound/alsa/soc/platform.txt | 6 +- Documentation/sound/alsa/soc/pops_clicks.txt | 10 ++-- 8 files changed, 97 insertions(+), 93 deletions(-) diff --git a/Documentation/sound/alsa/soc/DAI.txt b/Documentation/sound/alsa/soc/DAI.txt index 3feeb9e..0ebd7ea 100644 --- a/Documentation/sound/alsa/soc/DAI.txt +++ b/Documentation/sound/alsa/soc/DAI.txt @@ -1,5 +1,5 @@ ASoC currently supports the three main Digital Audio Interfaces (DAI) found on -SoC controllers and portable audio CODECS today, namely AC97, I2S and PCM. +SoC controllers and portable audio CODECs today, namely AC97, I2S and PCM. AC97 @@ -25,7 +25,7 @@ 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 usually varies depending on the sample rate and the master system clock (SYSCLK). LRCLK is the same as the sample rate. A few devices support separate -ADC and DAC LRCLK's, this allows for simultaneous capture and playback at +ADC and DAC LRCLKs, this allows for simultaneous capture and playback at different sample rates. I2S has several different operating modes:- @@ -35,7 +35,7 @@ I2S has several different operating modes:- o Left Justified - MSB is transmitted on transition of LRC. - o Right Justified - MSB is transmitted sample size BCLK's before LRC + o Right Justified - MSB is transmitted sample size BCLKs before LRC transition. PCM diff --git a/Documentation/sound/alsa/soc/clocking.txt b/Documentation/sound/alsa/soc/clocking.txt index 1493088..b130016 100644 --- a/Documentation/sound/alsa/soc/clocking.txt +++ b/Documentation/sound/alsa/soc/clocking.txt @@ -13,7 +13,7 @@ or SYSCLK). This audio master clock can be derived from a number of sources (e.g. crystal, PLL, CPU clock) and is responsible for producing the correct audio playback and capture sample rates. -Some master clocks (e.g. PLL's and CPU based clocks) are configurable in that +Some master clocks (e.g. PLLs and CPU based clocks) are configurable in that their speed can be altered by software (depending on the system use and to save power). Other master clocks are fixed at a set frequency (i.e. crystals). @@ -41,11 +41,11 @@ BCLK = LRC * x BCLK = LRC * Channels * Word Size This relationship depends on the codec or SoC CPU in particular. In general -it's best to configure BCLK to the lowest possible speed (depending on your -rate, number of channels and wordsize) to save on power. +it is best to configure BCLK to the lowest possible speed (depending on your +rate, number of channels and word size) to save on power. -It's also desirable to use the codec (if possible) to drive (or master) the -audio clocks as it's usually gives more accurate sample rates than the CPU. +It is also desirable to use the codec (if possible) to drive (or master) the +audio clocks as it usually gives more accurate sample rates than the CPU. diff --git a/Documentation/sound/alsa/soc/codec.txt b/Documentation/sound/alsa/soc/codec.txt index 1e766ad..1e95342 100644 --- a/Documentation/sound/alsa/soc/codec.txt +++ b/Documentation/sound/alsa/soc/codec.txt @@ -9,7 +9,7 @@ code should be added to the platform and machine drivers respectively. Each codec driver *must* provide the following features:- 1) Codec DAI and PCM configuration - 2) Codec control IO - using I2C, 3 Wire(SPI) or both API's + 2) Codec control IO - using I2C, 3 Wire(SPI) or both APIs 3) Mixers and audio controls 4) Codec audio operations @@ -19,7 +19,7 @@ Optionally, codec drivers can also provide:- 6) DAPM event handler. 7) DAC Digital mute control. -It's probably best to use this guide in conjunction with the existing codec +Its probably best to use this guide in conjunction with the existing codec driver code in sound/soc/codecs/ ASoC Codec driver breakdown @@ -27,8 +27,8 @@ ASoC Codec driver breakdown 1 - Codec DAI and PCM configuration ----------------------------------- -Each codec driver must have a struct snd_soc_codec_dai to define it's DAI and -PCM's capabilities and operations. This struct is exported so that it can be +Each codec driver must have a struct snd_soc_codec_dai 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. @@ -67,18 +67,18 @@ EXPORT_SYMBOL_GPL(wm8731_dai); 2 - 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 drivers will have to provide -functions to read and write the codec registers along with supplying a register -cache:- +The codec can usually be controlled via an I2C or SPI style interface +(AC97 combines control with data in the DAI). The codec drivers provide +functions to read and write the codec registers along with supplying a +register cache:- /* IO control data and register cache */ - void *control_data; /* codec control (i2c/3wire) data */ - void *reg_cache; + void *control_data; /* codec control (i2c/3wire) data */ + void *reg_cache; -Codec read/write should do any data formatting and call the hardware read write -below to perform the IO. These functions are called by the core and alsa when -performing DAPM or changing the mixer:- +Codec read/write should do any data formatting and call the hardware +read write below to perform the IO. These functions are called by the +core and ALSA when performing DAPM or changing the mixer:- unsigned int (*read)(struct snd_soc_codec *, unsigned int); int (*write)(struct snd_soc_codec *, unsigned int, unsigned int); @@ -131,7 +131,7 @@ Defines a stereo enumerated control 4 - Codec Audio Operations -------------------------- -The codec driver also supports the following alsa operations:- +The codec driver also supports the following ALSA operations:- /* SoC audio ops */ struct snd_soc_ops { @@ -142,15 +142,15 @@ struct snd_soc_ops { int (*prepare)(struct snd_pcm_substream *); }; -Please refer to the alsa driver PCM documentation for details. +Please refer to the ALSA driver PCM documentation for details. http://www.alsa-project.org/~iwai/writing-an-alsa-driver/c436.htm 5 - DAPM description. --------------------- -The Dynamic Audio Power Management description describes the codec's power -components, their relationships and registers to the ASoC core. Please read -dapm.txt for details of building the 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. Please also see the examples in other codec drivers. @@ -158,8 +158,8 @@ Please also see the examples in other codec drivers. 6 - 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's used to put the codec to sleep -when not in use. +domain PM calls (e.g. suspend and resume). It is used to put the codec +to sleep when not in use. Power states:- @@ -175,13 +175,14 @@ Power states:- SNDRV_CTL_POWER_D3cold: /* Everything Off, without power */ -7 - Codec DAC digital mute control. ------------------------------------- -Most codecs have a digital mute before the DAC's that can be used to minimise -any system noise. The mute stops any digital data from entering the DAC. +7 - 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. -A callback can be created that is called by the core for each codec DAI when the -mute is applied or freed. +A callback can be created that is called by the core for each codec DAI +when the mute is applied or freed. i.e. diff --git a/Documentation/sound/alsa/soc/dapm.txt b/Documentation/sound/alsa/soc/dapm.txt index ab0766f..c784a18 100644 --- a/Documentation/sound/alsa/soc/dapm.txt +++ b/Documentation/sound/alsa/soc/dapm.txt @@ -4,20 +4,20 @@ Dynamic Audio Power Management for Portable Devices 1. Description ============== -Dynamic Audio Power Management (DAPM) is designed to allow portable Linux devices -to use the minimum amount of power within the audio subsystem at all times. It -is independent of other kernel PM and as such, can easily co-exist with the -other PM systems. +Dynamic Audio Power Management (DAPM) is designed to allow portable +Linux devices to use the minimum amount of power within the audio +subsystem at all times. It is independent of other kernel PM and as +such, can easily co-exist with the other PM systems. -DAPM is also completely transparent to all user space applications as all power -switching is done within the ASoC core. No code changes or recompiling are -required for user space applications. DAPM makes power switching decisions based -upon any audio stream (capture/playback) activity and audio mixer settings -within the device. +DAPM is also completely transparent to all user space applications as +all power switching is done within the ASoC core. No code changes or +recompiling are required for user space applications. DAPM makes power +switching decisions based upon any audio stream (capture/playback) +activity and audio mixer settings within the device. -DAPM spans the whole machine. It covers power control within the entire audio -subsystem, this includes internal codec power blocks and machine level power -systems. +DAPM spans the whole machine. It covers power control within the entire +audio subsystem, this includes internal codec power blocks and machine +level power systems. There are 4 power domains within DAPM @@ -34,7 +34,7 @@ There are 4 power domains within DAPM Automatically set when mixer and mux settings are changed by the user. e.g. alsamixer, amixer. - 4. Stream domain - DAC's and ADC's. + 4. Stream domain - DACs and ADCs. Enabled and disabled when stream playback/capture is started and stopped respectively. e.g. aplay, arecord. @@ -51,7 +51,7 @@ widgets hereafter. 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 1 of it's inputs. + 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 @@ -78,14 +78,14 @@ parameters for stream name and kcontrols. 2.1 Stream Domain Widgets ------------------------- -Stream Widgets relate to the stream power domain and only consist of ADC's -(analog to digital converters) and DAC's (digital to analog converters). +Stream Widgets relate to the stream power domain and only consist of ADCs +(analog to digital converters) and DACs (digital to analog converters). Stream widgets have the following format:- SND_SOC_DAPM_DAC(name, stream name, reg, shift, invert), -NOTE: the stream name must match the corresponding stream name in your codecs +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 @@ -97,7 +97,7 @@ SND_SOC_DAPM_ADC("HiFi ADC", "HiFi Capture", REG, 2, 1), 2.2 Path Domain Widgets ----------------------- -Path domain widgets have a ability to control or effect the audio signal or +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) @@ -149,7 +149,7 @@ SND_SOC_DAPM_MIC("Mic Jack", spitz_mic_bias), 2.4 Codec Domain ---------------- -The Codec power domain has no widgets and is handled by the codecs DAPM event +The codec 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. @@ -158,8 +158,8 @@ stream event or by kernel PM events. ------------------- Sometimes widgets exist in the codec or machine audio map that don't have any -corresponding register bit for power control. In this case it's necessary to -create a virtual widget - a widget with no control bits e.g. +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), @@ -172,13 +172,14 @@ subsystem individually with a call to snd_soc_dapm_new_control(). 3. Codec Widget Interconnections ================================ -Widgets are connected to each other within the codec and machine by audio -paths (called interconnections). Each interconnection must be defined in order -to create a map of all audio paths between widgets. +Widgets are connected to each other within the codec and machine by audio paths +(called interconnections). Each interconnection must be defined in order to +create a map of all audio paths between widgets. + This is easiest with a diagram of the codec (and schematic of the machine audio system), as it requires joining widgets together via their audio signal paths. -i.e. from the WM8731 codec's output mixer (wm8731.c) +e.g., from the WM8731 output mixer (wm8731.c) The WM8731 output mixer has 3 inputs (sources) diff --git a/Documentation/sound/alsa/soc/machine.txt b/Documentation/sound/alsa/soc/machine.txt index 72bd222..f370e7d 100644 --- a/Documentation/sound/alsa/soc/machine.txt +++ b/Documentation/sound/alsa/soc/machine.txt @@ -16,7 +16,7 @@ struct snd_soc_machine { int (*remove)(struct platform_device *pdev); /* the pre and post PM functions are used to do any PM work before and - * after the codec and DAI's do any PM work. */ + * after the codec and DAIs do any PM work. */ int (*suspend_pre)(struct platform_device *pdev, pm_message_t state); int (*suspend_post)(struct platform_device *pdev, pm_message_t state); int (*resume_pre)(struct platform_device *pdev); @@ -38,7 +38,7 @@ probe/remove are optional. Do any machine specific probe here. suspend()/resume() ------------------ The machine driver has pre and post versions of suspend and resume to take care -of any machine audio tasks that have to be done before or after the codec, DAI's +of any machine audio tasks that have to be done before or after the codec, DAIs and DMA is suspended and resumed. Optional. @@ -49,10 +49,10 @@ The machine specific audio operations can be set here. Again this is optional. Machine DAI Configuration ------------------------- -The machine DAI configuration glues all the codec and CPU DAI's together. It can +The machine DAI configuration glues all the codec and CPU DAIs together. It can also be used to set up the DAI system clock and for any machine related DAI initialisation e.g. the machine audio map can be connected to the codec audio -map, unconnnected codec pins can be set as such. Please see corgi.c, spitz.c +map, unconnected codec pins can be set as such. Please see corgi.c, spitz.c for examples. struct snd_soc_dai_link is used to set up each DAI in your machine. e.g. @@ -67,7 +67,7 @@ static struct snd_soc_dai_link corgi_dai = { .ops = &corgi_ops, }; -struct snd_soc_machine then sets up the machine with it's DAI's. e.g. +struct snd_soc_machine then sets up the machine with it's DAIs. e.g. /* corgi audio machine driver */ static struct snd_soc_machine snd_soc_machine_corgi = { @@ -110,4 +110,4 @@ details. Machine Controls ---------------- -Machine specific audio mixer controls can be added in the dai init function. \ No newline at end of file +Machine specific audio mixer controls can be added in the DAI init function. diff --git a/Documentation/sound/alsa/soc/overview.txt b/Documentation/sound/alsa/soc/overview.txt index c47ce95..1e4c6d3 100644 --- a/Documentation/sound/alsa/soc/overview.txt +++ b/Documentation/sound/alsa/soc/overview.txt @@ -1,25 +1,26 @@ ALSA SoC Layer ============== -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. pxa2xx, au1x00, -iMX, etc) and portable audio codecs. Currently there is some support in the -kernel for SoC audio, however it has some limitations:- +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. +pxa2xx, au1x00, iMX, etc) and portable audio codecs. Prior to the ASoC +subsystem there was some support in the kernel for SoC audio, however it +had some limitations:- - * Currently, codec drivers are often tightly coupled to the underlying SoC - CPU. This is not ideal and leads to code duplication i.e. Linux now has 4 - different wm8731 drivers for 4 different SoC platforms. + * Codec drivers were often tightly coupled to the underlying SoC + CPU. This is not ideal and leads to code duplication - for example, + Linux had different wm8731 drivers for 4 different SoC platforms. - * There is no standard method to signal user initiated audio events (e.g. + * There was no standard method to signal user initiated audio events (e.g. Headphone/Mic insertion, Headphone/Mic detection after an insertion event). These are quite common events on portable devices and often require machine specific code to re-route audio, enable amps, etc., after such an event. - * Current drivers tend to power up the entire codec when playing - (or recording) audio. This is fine for a PC, but tends to waste a lot of - power on portable devices. There is also no support for saving power via - changing codec oversampling rates, bias currents, etc. + * Drivers tended to power up the entire codec when playing (or + recording) audio. This is fine for a PC, but tends to waste a lot of + power on portable devices. There was also no support for saving + power via changing codec oversampling rates, bias currents, etc. ASoC Design @@ -31,12 +32,13 @@ features :- * Codec independence. Allows reuse of codec drivers on other platforms and machines. - * Easy I2S/PCM audio interface setup between codec and SoC. Each SoC interface - and codec registers it's audio interface capabilities with the core and are - subsequently matched and configured when the application hw params are known. + * Easy I2S/PCM audio interface setup between codec and SoC. Each SoC + interface and codec registers it's audio interface capabilities with the + core and are subsequently matched and configured when the application + hardware parameters are known. * Dynamic Audio Power Management (DAPM). DAPM automatically sets the codec to - it's minimum power state at all times. This includes powering up/down + its minimum power state at all times. This includes powering up/down internal power blocks depending on the internal codec audio routing and any active streams. @@ -45,16 +47,16 @@ features :- signals the codec when to change power states. * Machine specific controls: Allow machines to add controls to the sound card - (e.g. volume control for speaker amp). + (e.g. volume control for speaker amplifier). To achieve all this, ASoC basically splits an embedded audio system into 3 components :- * Codec driver: The codec driver is platform independent and contains audio - controls, audio interface capabilities, codec dapm definition and codec IO + controls, audio interface capabilities, codec DAPM definition and codec IO functions. - * Platform driver: The platform driver contains the audio dma engine and audio + * Platform driver: The platform driver contains the audio DMA engine and audio interface drivers (e.g. I2S, AC97, PCM) for that platform. * Machine driver: The machine driver handles any machine specific controls and @@ -81,4 +83,4 @@ machine.txt: Machine driver internals. pop_clicks.txt: How to minimise audio artifacts. -clocking.txt: ASoC clocking for best power performance. \ No newline at end of file +clocking.txt: ASoC clocking for best power performance. diff --git a/Documentation/sound/alsa/soc/platform.txt b/Documentation/sound/alsa/soc/platform.txt index d4678b4..b681d17 100644 --- a/Documentation/sound/alsa/soc/platform.txt +++ b/Documentation/sound/alsa/soc/platform.txt @@ -8,7 +8,7 @@ specific code. Audio DMA ========= -The platform DMA driver optionally supports the following alsa operations:- +The platform DMA driver optionally supports the following ALSA operations:- /* SoC audio ops */ struct snd_soc_ops { @@ -38,7 +38,7 @@ struct snd_soc_platform { struct snd_pcm_ops *pcm_ops; }; -Please refer to the alsa driver documentation for details of audio DMA. +Please refer to the ALSA driver documentation for details of audio DMA. http://www.alsa-project.org/~iwai/writing-an-alsa-driver/c436.htm An example DMA driver is soc/pxa/pxa2xx-pcm.c @@ -52,7 +52,7 @@ 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 + 4) SYSCLK configuration 5) Suspend and resume (optional) Please see codec.txt for a description of items 1 - 4. diff --git a/Documentation/sound/alsa/soc/pops_clicks.txt b/Documentation/sound/alsa/soc/pops_clicks.txt index 3371bd9..e1e74da 100644 --- a/Documentation/sound/alsa/soc/pops_clicks.txt +++ b/Documentation/sound/alsa/soc/pops_clicks.txt @@ -15,11 +15,11 @@ click every time a component power state is changed. Minimising Playback Pops and Clicks =================================== -Playback pops in portable audio subsystems cannot be completely eliminated atm, -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:- +Playback pops in portable audio subsystems cannot be completely eliminated +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 -- 1.5.3.8

2 1

[alsa-devel] how do you people debug ALSA?
by Mihaela Vitalariu 22 Jan '08

22 Jan '08

Hello everyone! How do you ALSA developers debug the ALSA code? I am working on a large Linux project and i am using gdb which is not very helpful sometimes. I also use KDevelop to do graphical debugging(its' debugger is a frontend for gdb too), but it's not so good for multithreaded programs. If you have any hints please reply. Have a nice day!

4 4

Re: [alsa-devel] [alsa-cvslog] alsa-lib: Remove indirect control access
by Thierry Vignaud 22 Jan '08

22 Jan '08

Takashi Iwai <tiwai(a)suse.de> writes: > changeset: 2374:d0e6c6e079eb > user: tiwai > date: Tue Jan 08 18:34:36 2008 +0100 > files: include/sound/asound.h src/control/control.c > description: > Remove indirect control access > > The indirect control access is removed from the kernel. > This patch cleans the corresponding alsa-lib part. Shouldn't this be kept for compatibility with older kernels? Eg: if someone update distro foobar from version X to version Y, he usually can boot either the old kernel from X or the new one from Y. With such a change, booting the older kernel would result in missing features, wouldn't it?

2 2

[alsa-devel] [PATCH 2/2] hda: Mono mux mixer support
by Matthew Ranostay 22 Jan '08

22 Jan '08

Add support for the mono mux on several 92HD7xxx codecs. Creates a dynamic mixer for the mux selection. Signed-off-by: Matthew Ranostay <mranostay(a)embeddedalley.com> --- diff -r a035d5e4801c pci/hda/patch_sigmatel.c --- a/pci/hda/patch_sigmatel.c Fri Jan 18 15:32:32 2008 +0100 +++ b/pci/hda/patch_sigmatel.c Mon Jan 21 11:58:25 2008 -0500 @@ -131,6 +131,8 @@ struct sigmatel_spec { hda_nid_t *pwr_nids; /* playback */ + struct hda_input_mux *mono_mux; + unsigned int cur_mmux; struct hda_multi_out multiout; hda_nid_t dac_nids[5]; @@ -144,6 +146,7 @@ struct sigmatel_spec { hda_nid_t *dmux_nids; unsigned int num_dmuxes; hda_nid_t dig_in_nid; + hda_nid_t mono_nid; /* pin widgets */ hda_nid_t *pin_nids; @@ -174,6 +177,7 @@ struct sigmatel_spec { struct snd_kcontrol_new *kctl_alloc; struct hda_input_mux private_dimux; struct hda_input_mux private_imux; + struct hda_input_mux private_mono_mux; /* virtual master */ unsigned int vmaster_tlv[4]; @@ -399,6 +403,34 @@ static int stac92xx_mux_enum_put(struct return snd_hda_input_mux_put(codec, spec->input_mux, ucontrol, spec->mux_nids[adc_idx], &spec->cur_mux[adc_idx]); +} + +static int stac92xx_mono_mux_enum_info(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_info *uinfo) +{ + struct hda_codec *codec = snd_kcontrol_chip(kcontrol); + struct sigmatel_spec *spec = codec->spec; + return snd_hda_input_mux_info(spec->mono_mux, uinfo); +} + +static int stac92xx_mono_mux_enum_get(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct hda_codec *codec = snd_kcontrol_chip(kcontrol); + struct sigmatel_spec *spec = codec->spec; + + ucontrol->value.enumerated.item[0] = spec->cur_mmux; + return 0; +} + +static int stac92xx_mono_mux_enum_put(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct hda_codec *codec = snd_kcontrol_chip(kcontrol); + struct sigmatel_spec *spec = codec->spec; + + return snd_hda_input_mux_put(codec, spec->mono_mux, ucontrol, + spec->mono_nid, &spec->cur_mmux); } #define stac92xx_aloopback_info snd_ctl_boolean_mono_info @@ -603,6 +635,16 @@ static struct hda_verb stac9205_core_ini {} }; +#define STAC_MONO_MUX \ + { \ + .iface = SNDRV_CTL_ELEM_IFACE_MIXER, \ + .name = "Mono Mux", \ + .count = 1, \ + .info = stac92xx_mono_mux_enum_info, \ + .get = stac92xx_mono_mux_enum_get, \ + .put = stac92xx_mono_mux_enum_put, \ + } + #define STAC_INPUT_SOURCE(cnt) \ { \ .iface = SNDRV_CTL_ELEM_IFACE_MIXER, \ @@ -714,6 +756,7 @@ static struct snd_kcontrol_new stac92hd7 static struct snd_kcontrol_new stac92hd71bxx_analog_mixer[] = { STAC_INPUT_SOURCE(2), + STAC_MONO_MUX, HDA_CODEC_VOLUME_IDX("Capture Volume", 0x0, 0x1c, 0x0, HDA_OUTPUT), HDA_CODEC_MUTE_IDX("Capture Switch", 0x0, 0x1c, 0x0, HDA_OUTPUT), @@ -733,6 +776,7 @@ static struct snd_kcontrol_new stac92hd7 static struct snd_kcontrol_new stac92hd71bxx_mixer[] = { STAC_INPUT_SOURCE(2), STAC_ANALOG_LOOPBACK(0xFA0, 0x7A0, 2), + STAC_MONO_MUX, HDA_CODEC_VOLUME_IDX("Capture Volume", 0x0, 0x1c, 0x0, HDA_OUTPUT), HDA_CODEC_MUTE_IDX("Capture Switch", 0x0, 0x1c, 0x0, HDA_OUTPUT), @@ -1180,7 +1224,7 @@ static struct snd_pci_quirk stac92hd73xx static unsigned int ref92hd71bxx_pin_configs[10] = { 0x02214030, 0x02a19040, 0x01a19020, 0x01014010, - 0x0181302e, 0x01114010, 0x01a19020, 0x90a000f0, + 0x0181302e, 0x01114010, 0x01019020, 0x90a000f0, 0x90a000f0, 0x01452050, }; @@ -2318,6 +2362,35 @@ static int stac92xx_auto_create_hp_ctls( return 0; } +/* labels for mono mux outputs */ +static const char *stac92xx_mono_labels[3] = { + "DAC0", "DAC1", "Mixer" +}; + +/* create mono mux for mono out on capable codecs */ +static int stac92xx_auto_create_mono_output_ctls(struct hda_codec *codec) +{ + struct sigmatel_spec *spec = codec->spec; + struct hda_input_mux *mono_mux = &spec->private_mono_mux; + int i, num_cons; + hda_nid_t con_lst[HDA_MAX_NUM_INPUTS]; + + num_cons = snd_hda_get_connections(codec, + spec->mono_nid, + con_lst, + HDA_MAX_NUM_INPUTS); + if (!num_cons) + return -EINVAL; + + for (i = 0; i < num_cons; i++) { + mono_mux->items[mono_mux->num_items].label = + stac92xx_mono_labels[i]; + mono_mux->items[mono_mux->num_items].index = i; + mono_mux->num_items++; + } + return 0; +} + /* labels for dmic mux inputs */ static const char *stac92xx_dmic_labels[5] = { "Analog Inputs", "Digital Mic 1", "Digital Mic 2", @@ -2532,6 +2605,12 @@ static int stac92xx_parse_auto_config(st if (err < 0) return err; + if (spec->mono_nid > 0) { + err = stac92xx_auto_create_mono_output_ctls(codec); + if (err < 0) + return err; + } + if (spec->num_dmics > 0) if ((err = stac92xx_auto_create_dmic_input_ctls(codec, &spec->autocfg)) < 0) @@ -2552,6 +2631,7 @@ static int stac92xx_parse_auto_config(st spec->input_mux = &spec->private_imux; if (!spec->dinput_mux) spec->dinput_mux = &spec->private_dimux; + spec->mono_mux = &spec->private_mono_mux; return 1; } @@ -3237,6 +3317,7 @@ again: spec->gpio_mask = spec->gpio_data = 0x00000001; /* GPIO0 High = EAPD */ + spec->mono_nid = 0x15; spec->mux_nids = stac92hd71bxx_mux_nids; spec->adc_nids = stac92hd71bxx_adc_nids; spec->dmic_nids = stac92hd71bxx_dmic_nids;

2 4

Re: [alsa-devel] conversion of opti93x driver to use cs4231-lib
by krzysztof.h1＠poczta.fm 22 Jan '08

22 Jan '08

> On 08-01-08 15:36, Rene Herman wrote: > > >> Missed this one originally. I'll look into this in some detail but > >> will need a few days. Obviously, if it works, it's desirable. Maybe > >> Jaroslav knows why it's not that way now? > > > > Oh, and by the way, I suppose it'll be trivial but a rediff would be > > good for testing. > I'll do a new diff on weekend. Thanks, Krzysztof PS. I tested it on 931 and 933. ---------------------------------------------------------------------- Sprawdz, ktore komorki sa najmodniejsze! Kliknij >>> http://link.interia.pl/f1cd4

1 0

[alsa-devel] Support for Compaq Presario F700 - model 755US - NVidia MCP67 Audio - Codec Conexant 5051
by Philippe Paravicini 21 Jan '08

21 Jan '08

I recently purchased the laptop listed above and installed kubuntu-7.10-desktop-amd64 Feisty on it. The sound card works, but, much to my chagrin, plugging in the headphone jack does not mute the speaker. <wining> This is less than ideal for me because I use Skype quite a bit, and work in a no-walls small office with other people. Having the ability to use my headset for talking on the phone and drowning out ambient noise is important. </wining><deepbreath/> I have googled high and low and have tried various suggested solutions, including changing: options snd-hda-intel model=laptop in /etc/modprobe.d/alsa-base to various settings (laptop-hp, laptop-eahd, test). I have also downloaded, compiled and installed the 1.0.15 driver and utils according to the instructions at: https://help.ubuntu.com/community/HdaIntelSoundHowto without success. I consulted the page at: http://www.mjmwired.net/kernel/Documentation/sound/alsa/ALSA-Configuration.… dated 2007-10-11 and could note see support for the Conexant 5051 Codec or NVidia MCP67 Audio. Has anyone had experience with this soundcard/codec and gotten the headphones jack to mute the speakers correctly ? Any help would be greatly appreciated. I am a java programmer with very high reverence for linux C-programmers and would be happy to help test a patch for this device (I may need a little help to get going), or trade for java programming/consulting. Please let me know if you additional information other than the one listed below. Thank you kindly for any help. Sincerely, Philippe Paravicini lspci -v outputs: ... 00:07.0 Audio device: nVidia Corporation MCP67 High Definition Audio (rev a1) Subsystem: Hewlett-Packard Company Unknown device 30ea ... lspci -vn ... 00:07.0 0403: 10de:055c (rev a1) Subsystem: 103c:30ea Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 21 Memory at f6480000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/0 Enable- Capabilities: [6c] HyperTransport: MSI Mapping ... cat /proc/asound/card0/codec#0 Codec: Conexant ID 5051 Address: 0 Vendor Id: 0x14f15051 Subsystem Id: 0x103c30ea Revision Id: 0x100000 Modem Function Group: 0x2 Default PCM: rates [0x160]: 44100 48000 96000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: N/A Default Amp-Out caps: N/A Node 0x10 [Audio Output] wcaps 0xc1d: Stereo Amp-Out Amp-Out caps: ofs=0x4a, nsteps=0x4a, stepsize=0x03, mute=0 Amp-Out vals: [0x3a 0x3a] PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power: 0x0 Node 0x11 [Audio Output] wcaps 0xc1d: Stereo Amp-Out Amp-Out caps: ofs=0x4a, nsteps=0x4a, stepsize=0x03, mute=0 Amp-Out vals: [0x4a 0x4a] PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power: 0x0 Node 0x12 [Audio Output] wcaps 0x211: Stereo Digital PCM: rates [0x160]: 44100 48000 96000 bits [0xe]: 16 20 24 formats [0x5]: PCM AC3 Node 0x13 [Beep Generator Widget] wcaps 0x70000c: Mono Amp-Out Amp-Out caps: ofs=0x03, nsteps=0x03, stepsize=0x17, mute=0 Amp-Out vals: [0x00] Node 0x14 [Audio Input] wcaps 0x100d1b: Stereo Amp-In Amp-In caps: ofs=0x4a, nsteps=0x50, stepsize=0x03, mute=0 Amp-In vals: [0x06 0x06] [0x35 0x35] PCM: rates [0x160]: 44100 48000 96000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power: 0x0 Connection: 2 0x1d 0x17* Node 0x15 [Audio Input] wcaps 0x100d1b: Stereo Amp-In Amp-In caps: ofs=0x4a, nsteps=0x50, stepsize=0x03, mute=0 Amp-In vals: [0x4a 0x4a] PCM: rates [0x160]: 44100 48000 96000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power: 0x0 Connection: 1 0x18 Node 0x16 [Pin Complex] wcaps 0x400581: Stereo Pincap 0x081c: OUT HP Detect Pin Default 0x02211030: [Jack] HP Out at Ext Front Conn = 1/8, Color = Black Pin-ctls: 0xc0: OUT HP Power: 0x0 Connection: 2 0x10* 0x11 Node 0x17 [Pin Complex] wcaps 0x40048b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 Amp-In vals: Pincap 0x081224: IN Detect Pin Default 0x02a19020: [Jack] Mic at Ext Front Conn = 1/8, Color = Pink Pin-ctls: 0x24: IN Power: 0x0 Node 0x18 [Pin Complex] wcaps 0x40048b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 Amp-In vals: Pincap 0x081224: IN Detect Pin Default 0x400001f0: [N/A] Line Out at Ext N/A Conn = Unknown, Color = Unknown Pin-ctls: 0x00: Power: 0x0 Node 0x19 [Pin Complex] wcaps 0x400581: Stereo Pincap 0x0814: OUT Detect Pin Default 0x400001f0: [N/A] Line Out at Ext N/A Conn = Unknown, Color = Unknown Pin-ctls: 0x00: Power: 0x0 Connection: 2 0x10 0x11* Node 0x1a [Pin Complex] wcaps 0x400501: Stereo Pincap 0x0810010: OUT EAPD Pin Default 0x95170110: [Fixed] Speaker at Int Top Conn = Analog, Color = Unknown Pin-ctls: 0x40: OUT Power: 0x0 Connection: 2 0x10* 0x11 Node 0x1b [Pin Complex] wcaps 0x400500: Mono Pincap 0x0810010: OUT EAPD Pin Default 0x400001f0: [N/A] Line Out at Ext N/A Conn = Unknown, Color = Unknown Pin-ctls: 0x40: OUT Power: 0x0 Connection: 2 0x10* 0x11 Node 0x1c [Pin Complex] wcaps 0x400701: Stereo Digital Pincap 0x0810: OUT Pin Default 0x224511f0: [Jack] SPDIF Out at Sep Front Conn = Optical, Color = Black Pin-ctls: 0x00: Power: 0x0 Connection: 1 0x12 Node 0x1d [Pin Complex] wcaps 0x40040b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 Amp-In vals: Pincap 0x0820: IN Pin Default 0x400001f0: [N/A] Line Out at Ext N/A Conn = Unknown, Color = Unknown Pin-ctls: 0x00: Power: 0x0 Node 0x1e [Vendor Defined Widget] wcaps 0xf00000: Mono

5 7

[alsa-devel] Patch for ALC882
by Kip Warner 21 Jan '08

21 Jan '08

So after many months of wrestling with Realtek's technical support, I finally managed to get all four of my speakers to work in my ASUS A7J laptop. The patch was intended to replace alsa-kernel/pci/hda/patch_realtek.c in 1.0.14rc4 and that was the last version I successfully tested it on. Since then, I haven't managed to get all four speaker to work. I am not sure why Realtek never posted this patch, but I figured that perhaps some of the ALSA brains might be able to make sense of it and integrate properly into HEAD. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com

2 12

[alsa-devel] [PATCH 1/2] hda: STAC92xx mono mixer controls
by Matthew Ranostay 21 Jan '08

21 Jan '08

Added mono mixer volume/switch controls for STAC9205 and STAC925x codecs. Signed-off-by: Matthew Ranostay <mranostay(a)embeddedalley.com> --- diff -r 4177ec41bbef pci/hda/patch_sigmatel.c --- a/pci/hda/patch_sigmatel.c Mon Jan 21 14:33:37 2008 +0100 +++ b/pci/hda/patch_sigmatel.c Mon Jan 21 11:37:49 2008 -0500 @@ -572,6 +572,7 @@ static struct hda_verb stac925x_core_ini static struct hda_verb stac925x_core_init[] = { /* set dac0mux for dac converter */ { 0x06, AC_VERB_SET_CONNECT_SEL, 0x00}, + { 0x10, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT}, {} }; @@ -600,6 +601,7 @@ static struct hda_verb stac9205_core_ini static struct hda_verb stac9205_core_init[] = { /* set master volume and direct control */ { 0x24, AC_VERB_SET_VOLUME_KNOB_CONTROL, 0xff}, + { 0x14, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT}, {} }; @@ -748,6 +750,9 @@ static struct snd_kcontrol_new stac92hd7 static struct snd_kcontrol_new stac925x_mixer[] = { STAC_INPUT_SOURCE(1), + HDA_CODEC_MUTE_MONO("Mono Playback Switch", 0x10, 0x1, 0, HDA_OUTPUT), + HDA_CODEC_VOLUME_MONO("Mono Playback Volume", 0x10, 0x1, 0, HDA_OUTPUT), + HDA_CODEC_VOLUME("Capture Volume", 0x09, 0, HDA_OUTPUT), HDA_CODEC_MUTE("Capture Switch", 0x09, 0, HDA_OUTPUT), HDA_CODEC_VOLUME("Capture Mux Volume", 0x0f, 0, HDA_OUTPUT), @@ -757,6 +762,9 @@ static struct snd_kcontrol_new stac9205_ static struct snd_kcontrol_new stac9205_mixer[] = { STAC_INPUT_SOURCE(2), STAC_ANALOG_LOOPBACK(0xFE0, 0x7E0, 1), + + HDA_CODEC_MUTE_MONO("Mono Playback Switch", 0x14, 0x1, 0, HDA_OUTPUT), + HDA_CODEC_VOLUME_MONO("Mono Playback Volume", 0x14, 0x1, 0, HDA_OUTPUT), HDA_CODEC_VOLUME_IDX("Capture Volume", 0x0, 0x1b, 0x0, HDA_INPUT), HDA_CODEC_MUTE_IDX("Capture Switch", 0x0, 0x1d, 0x0, HDA_OUTPUT),

2 2