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

[alsa-devel] [PATCH] add atomic operations for Blackfin parts
by Mike Frysinger 18 Jan '10

18 Jan '10

Signed-off-by: Mike Frysinger <vapier(a)gentoo.org> --- include/iatomic.h | 23 +++++++++++++++++++++++ 1 files changed, 23 insertions(+), 0 deletions(-) diff --git a/include/iatomic.h b/include/iatomic.h index 8f6ec22..e92dbfd 100644 --- a/include/iatomic.h +++ b/include/iatomic.h @@ -1079,6 +1079,29 @@ static __inline__ int atomic_sub_return(int i, volatile atomic_t *v) #endif /* __sh__ */ +#ifdef __bfin__ + +#include <bfin_fixed_code.h> + +typedef struct { volatile int counter; } atomic_t; + +#define ATOMIC_INIT(i) { (i) } + +#define atomic_read(v) ((v)->counter) +#define atomic_set(v,i) (((v)->counter) = (i)) +#define atomic_add(i,v) bfin_atomic_add32(&(v)->counter, i) +#define atomic_sub(i,v) bfin_atomic_sub32(&(v)->counter, i) +#define atomic_inc(v) bfin_atomic_inc32(&(v)->counter); +#define atomic_dec(v) bfin_atomic_dec32(&(v)->counter); + +#define mb() __asm__ __volatile__ ("" : : : "memory") +#define rmb() mb() +#define wmb() mb() + +#define IATOMIC_DEFINED 1 + +#endif /* __bfin__ */ + #ifndef IATOMIC_DEFINED /* * non supported architecture. -- 1.6.6

3 4

[alsa-devel] ASoC updates for 2.6.34
by Mark Brown 18 Jan '10

18 Jan '10

The following changes since commit 735fe4cfbc3cedea41bd0ed31955054dae6beb46: Mark Brown (1): ASoC: Add missing __devexit and __devinit annotations are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.34 Daniel Mack (3): ASoC: ak4104: allow more sample rates ASoC: cs4270: allow passing freq=0 in set_dai_sysclk() ASoC: support more sample rates on raumfeld devices Mark Brown (6): ASoC: Fix i.MX audio build for i.MX3x ASoC: Convert new i.MX SSI driver to use static DAI array ASoC: i.MX SSI driver does not yet support master mode ASoC: Remove old i.MX driver code ASoC: Mark new i.MX drivers as BROKEN until arch/arm merged Merge branch 'mxc-audio' into for-2.6.34 Peter Ujfalusi (1): ASoC: TWL4030: Replace comma with semicolon in probe function Sascha Hauer (1): ASoC: Add a new imx-ssi sound driver Thomas Weber (1): ASoC: TWL4030: Fix typo in comment in header file arch/arm/plat-mxc/Makefile | 4 + arch/arm/plat-mxc/ssi-fiq-ksym.c | 20 + arch/arm/plat-mxc/ssi-fiq.S | 134 ++++++ sound/soc/codecs/ak4104.c | 4 +- sound/soc/codecs/cs4270.c | 38 ++- sound/soc/codecs/twl4030.c | 2 +- sound/soc/codecs/twl4030.h | 2 +- sound/soc/imx/Kconfig | 20 +- sound/soc/imx/Makefile | 12 +- sound/soc/imx/imx-pcm-dma-mx2.c | 313 ++++++++++++++ sound/soc/imx/imx-pcm-fiq.c | 277 ++++++++++++ sound/soc/imx/imx-ssi.c | 758 +++++++++++++++++++++++++++++++++ sound/soc/imx/imx-ssi.h | 237 +++++++++++ sound/soc/imx/mx1_mx2-pcm.c | 488 --------------------- sound/soc/imx/mx1_mx2-pcm.h | 26 -- sound/soc/imx/mx27vis_wm8974.c | 318 -------------- sound/soc/imx/mxc-ssi.c | 860 -------------------------------------- sound/soc/imx/mxc-ssi.h | 238 ----------- sound/soc/pxa/raumfeld.c | 61 ++- 19 files changed, 1823 insertions(+), 1989 deletions(-) create mode 100644 arch/arm/plat-mxc/ssi-fiq-ksym.c create mode 100644 arch/arm/plat-mxc/ssi-fiq.S create mode 100644 sound/soc/imx/imx-pcm-dma-mx2.c create mode 100644 sound/soc/imx/imx-pcm-fiq.c create mode 100644 sound/soc/imx/imx-ssi.c create mode 100644 sound/soc/imx/imx-ssi.h delete mode 100644 sound/soc/imx/mx1_mx2-pcm.c delete mode 100644 sound/soc/imx/mx1_mx2-pcm.h delete mode 100644 sound/soc/imx/mx27vis_wm8974.c delete mode 100644 sound/soc/imx/mxc-ssi.c delete mode 100644 sound/soc/imx/mxc-ssi.h

2 1

[alsa-devel] MSM DSP
by GNUtoo 17 Jan '10

17 Jan '10

hi, I've bought an HTC dream,before buying I looked at the feasibility of porting GNU/Linux on it(so not Android). There is a patch(for maing the driver standard) or a standard(everything is non-standard in android) driver for most of the components. The biggest problem seems the sound. So knowing that codeaurora( https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git ) had alsa in its kenrel I first tried to compile that kernel...but due to numerous bugs(It didn't compile and needed too much fixing) in it android-msm-2.6.29 branch I decided to import alsa in the linuxtogo kernel,and I pushed the sources at a temporary htc-alsa branch at git://gitorious.org/replicant/gnulinuxkernel.git (it's called gnulinux in order to differentiate from an android kernel,I didn't find a good name for it) from the commit message available here : http://gitorious.org/replicant/gnulinuxkernel/commit/92945ccd0921e940fc2675… I had to change snd_rpc_ids.vers = 0x00020001 into snd_rpc_ids.vers = 0xaa2b1a44 ,and to make minor build system changes and I had aplay working rapidely... but only aplay... mplayer was waiting indefinitely for the following system call: ioctl(6, 0x400c4150 ls -l /proc/$(pido mplayer)/fd/6 gave /dev/snd/pcmC0D0p and 0x400c4150 gave that: SNDRV_PCM_IOCTL_WRITEI_FRAMES = _IOW('A', 0x50, struct snd_xferi) Then with printks(I had no serial cable(I've looked for a craddle/docking station with the special HTC connector for easy soldering...but I didn't found one) so I couldn't use kgdb) I went until that point: rc = wait_event_interruptible(the_locks.write_wait, (frame->used == 0)|| (prtd->stopped)); That's in the alsa_send_buffer function in /sound/soc/msm/msm-pcm.c Then I continued the tracing puting printks everywhere...and I found that: with aplay: msm_pcm_playback_copy in the /sound/soc/msm/msm7k-pcm.c was called rc = alsa_send_buffer(prtd, buf, fbytes, NULL); was called once inside alsa_send_buffer (in /sound/soc/msm/msm-pcm.c) the count loop was only executed once because count was exhausted on the first run then copy_count is incremented and the audio is configured then at second call of the alsa_send_buffer the audio is configured and works. here's an output of the aplay parameters: $ aplay -v 05\ -\ Jet\ Set.wav Playing WAVE '05 - Jet Set.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo Plug PCM: Hardware PCM card 0 'msm-audio' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 4800 period_size : 1200 period_time : 27210 tick_time : 0 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 1200 xfer_align : 1200 start_threshold : 4800 stop_threshold : 4800 silence_threshold: 0 silence_size : 0 boundary : 1258291200 note that frame = prtd->out + prtd->out_tail; makes frame->used have a bad value the first time it is run but as the count is only run once it doesn't import. the next runs prtd->out + prtd->out_tail have a good value with mplayer the story was quite different,even if the beginning was the same : msm_pcm_playback_copy in the /sound/soc/msm/msm7k-pcm.c was also called,rc = alsa_send_buffer(prtd, buf, fbytes, NULL); was also called inside alsa_send_buffer (in /sound/soc/msm/msm-pcm.c) but once in alsa_send_buffer,more precisely under the count loop the story changes: count is not exhausted the first time,because in "xfer = count > frame->size ? frame->size : count;" the smallest between count and frame->size is assigned,and so after it does "count -= xfer" and so count is not 0,because the buffer size detected by mplayer is 19200 insterad of 4800 so here what it does in detail: it passes 19200 as count here: fbytes = frames_to_bytes(runtime, frames); rc = alsa_send_buffer(prtd, buf, fbytes, NULL); that goes into that: ssize_t alsa_send_buffer(struct msm_audio *prtd, const char __user *buf, size_t count, loff_t *pos) and then the count variable is 19200 in alsa_send_buffer then there is xfer = count > frame->size ? frame->size : count; so it assigns the minimum between count and frame->size to xfer count is still 19200 frame->size is 4800 so xfer becomes 4800 then count -= xfer decrement count but only of 4800 so count is not exhausted and runs another time then : frame = prtd->out + prtd->out_tail; makes frame->used have a bad value,and then it blocks here: rc = wait_event_interruptible(the_locks.write_wait,(frame->used == 0) || (prtd->stopped)); because frame->used is not 0. here an mplayer output: Forced audio codec: mad Opening audio decoder: [pcm] Uncompressed PCM audio decoder dec_audio: Allocating 2048 + 65536 = 67584 bytes for output buffer. AUDIO: 44100 Hz, 2 ch, s16le, 1411.2 kbit/100.00% (ratio: 176400->176400) Selected audio codec: [pcm] afm: pcm (Uncompressed PCM) ========================================================================== Building audio filter chain for 44100Hz/2ch/s16le -> 0Hz/0ch/??... [libaf] Adding filter dummy [dummy] Was reinitialized: 44100Hz/2ch/s16le [dummy] Was reinitialized: 44100Hz/2ch/s16le Trying preferred audio driver 'alsa', options '[none]' alsa-init: requested format: 44100 Hz, 2 channels, 9 alsa-init: using ALSA 1.0.15 alsa-init: setup for 1/2 channel(s) alsa-init: using device default alsa-init: pcm opened in blocking mode alsa-init: got buffersize=19200 alsa-init: got period size 300 alsa: 44100 Hz/2 channels/4 bpf/19200 bytes buffer/Signed 16 bit Little Endian AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample) AO: Description: ALSA-0.9.x-1.x audio output AO: Author: Alex Beregszaszi, Zsolt Barat <joy(a)streamminister.de> AO: Comment: under developement Building audio filter chain for 44100Hz/2ch/s16le -> 44100Hz/2ch/s16le... [dummy] Was reinitialized: 44100Hz/2ch/s16le [dummy] Was reinitialized: 44100Hz/2ch/s16le Video: no video Freeing 0 unused video chunks. Starting playback... Increasing filtered audio buffer size from 0 to 21248 so the quick solution was to force mplayer to use 4800 as buffer size with something like that: diff --git a/sound/soc/msm/msm7k-pcm.c b/sound/soc/msm/msm7k-pcm.c index 38e8283..bfbc66d 100644 --- a/sound/soc/msm/msm7k-pcm.c +++ b/sound/soc/msm/msm7k-pcm.c @@ -115,7 +115,7 @@ static struct snd_pcm_hardware msm_pcm_playback_hardware = { .rate_max = USE_RATE_MAX, .channels_min = USE_CHANNELS_MIN, .channels_max = USE_CHANNELS_MAX, - .buffer_bytes_max = MAX_BUFFER_PLAYBACK_SIZE, + .buffer_bytes_max = 4800, .period_bytes_min = 64, .period_bytes_max = MAX_PERIOD_SIZE, .periods_min = USE_PERIODS_MIN, but then mplayer seem to loop on an ioctl: mplayer is frozen here and doesn't respond to other input than ctrl+c: 0.0 (00.0) of 206.0 (03:26.0) ??,?% strace shows a lot of : nanosleep followed by SNDRV_PCM_IOCTL_STATUS (ioctl(6, 0x806c4120, 0xbe8bc9c8) = 0) an analyse of the status shows a constant : status->delay is 1200,and status->avail is 0,they don't vary over time and are printed just after that code in snd_pcm_status in sound/core/pcm_native.c if (runtime->status->state == SNDRV_PCM_STATE_RUNNING || runtime->status->state == SNDRV_PCM_STATE_DRAINING) status->delay = runtime->buffer_size - status->avail; else status->delay = 0; I was told in #mplayerdev that it was because the DSP didn't play the frames...indeed I hear no sound.... So how should I fix that mess? *did the quick and dirty fix cause the second problem? *should I use the DSP directly and make a pulseaudio plugin that talks to the android driver, instead(the driver seems very buggy) The good would be support for mp3 and similar things within the DSP,and that it should be more stable. The bad is that I already spent *a lot* of time with the alsa kernel driver...and that writing that will also require some userspaces changes such as: *modification of the phone routing in the "FSO" ( http://www.freesmartphone.org/index.php/Main_Page ) dbus framework to use pulseaudio *would require changes in the build system for using pulseaudio(openembedded(http://wiki.openembedded.net/index.php/Main_Page )) *may be slow...openmoko stopped to use pulseaudio because of speed issues. Denis

7 18

[alsa-devel] Audio buffer mmap-ing on sh arch vs. cache aliasing problem
by Pawel MOLL 16 Jan '10

16 Jan '10

Hi Guys, Recently I was investigating an issue with capturing audio using USB Audio Class device on a sh4-based board. "Bad voice quality" was reported... Finally I have traced the problem to something which is (unfortunately) well known to sh developers as a D-cache aliasing (or synonym) problem. Briefly speaking: due to some MMU design decisions, one can have two different virtual address pointing to the same physical location, which is fine, but going via different cache slots! So if there was a value of "0" in the memory and user "A" will write "1" there, user "B" will still read "0"... The solution is to ensure all TLB entries (so virtual memory areas) are beginning from a 16kB-aligned virtual address. Otherwise it is necessary to flush the cache between accesses from "A" and "B" sides. And now. The USB Audio Class driver (sound/usb/usbaudio.c) is allocating the sound buffer like this... static int snd_pcm_alloc_vmalloc_buffer(struct snd_pcm_substream *subs, size_t size) { [...] runtime->dma_area = vmalloc(size); [...] } ... and vmalloc will return a page(4k)-aligned pointer, possibly not 16k-aligned one. This is the source of all evil ;-) When using RW transfers everything is fine, as data is memcopied between two independent buffers. In a case of MMAP mode we will end up with such a situation: 1. The driver will memcpy data from an URB to the buffer. It will populate several cache lines. Let's call it a "kernel cache". 2. As the library has mapped the non-16k-aligned address via different cache line ("user cache"), it will read some rubbish from the physical memory, populating the "user cache" by the way. 3. Some time later the "kernel cache" is flushed, writing the data to the memory. 4. Some new data from URB is entering "kernel cache". 5. The library will access mmap-ed area again, going via the "user cache", which may or may not reflect the correct data (depending on the fact was the "user cache" flushed or not) etc. Of course this cycle is completely not deterministic, so some of the "kernel cache" lines will be flushed before being accessed from user space, other not... The final effect is... hmm... bizarre :-) First, of course, you will get a (probably loud) glitch (rubbish from buffer's underlying memory, before the first valid data is written back), and then something that could be described as an "echo" ;-) I mean - you are capturing "1 2 3 4 5 6 7..." and the result is (G stands for Glitch ;-) "G 1 23 3 4 4 6 67..." As a quick-and-dirty work-around I have modified snd_pcm_alloc_vmalloc_buffer() to allocate always 12kB more and then use 16k-aligned pointer: static int snd_pcm_alloc_vmalloc_buffer(struct snd_pcm_substream *subs, size_t size) { struct snd_pcm_runtime *runtime = subs->runtime; if (runtime->dma_addr) { if (runtime->dma_bytes >= size) return 0; /* already large enough */ vfree((void *)runtime->dma_addr); } runtime->dma_addr = (unsigned long)vmalloc(size + 12 * 1024); if (!runtime->dma_addr) return -ENOMEM; runtime->dma_area = (void *)ALIGN(runtime->dma_addr, 16 * 1024); runtime->dma_bytes = size; return 0; } Of course it cannot be regarded as anything more as a hack. And definitely not as a solution... So my question is: Any idea how the "proper solution" should look like? I see no obvious method to get an arch-independent "mmap-compliant" buffer. This problem was found on a sh arch, using an USB Audio Class device, however out there some other architectures are suffering from this MMU "feature" as well (ie. see http://docs.hp.com/en/B3906-90006/ch07s09.html) and possibly other drivers could behave "wrongly" (quoted as the driver is actually innocent...) To be honest I just have absolutely no idea what to do with this all! :-O I hope I was clear enough in the description... Any feedback, advise, idea etc. will be more than appreciated. Cheers Paweł

3 11

[alsa-devel] [PATCH] - fix speaker output for toshiba nb205 netbooks
by Nickolas 16 Jan '10

16 Jan '10

this is a quick fix i wrote up a couple days ago to fix speaker output on the Realtek ALC272 codec present in toshiba nb205 netbooks. presently, speaker output doesn't work at all on this model, regardless of settings in the mixer. this is because the current driver thinks the speaker is at nid 0x0c instead of the correct 0x17. i'm not too familiar with this hardware, so i'm not sure that this patch won't have any negative effects for other hardware. it also seems like a messy way of fixing the problem. any comments or suggestions are welcome, as is testing for those who have this board. diffed against the latest git. Thanks, Nick -- Signed-off-by: Nickolas Lloyd <ultrageek.lloyd(a)gmail.com> --- alsa-driver/sound/pci/hda/patch_realtek.c 2010-01-12 08:03:28.000000000 -0500 +++ alsa-driver-b/sound/pci/hda/patch_realtek.c 2010-01-12 16:27:48.000000000 -0500 @@ -192,6 +192,7 @@ enum { ALC663_ASUS_MODE8, ALC272_DELL, ALC272_DELL_ZM1, + ALC272_TOSHIBA_N200, ALC272_SAMSUNG_NC10, ALC662_AUTO, ALC662_MODEL_LAST, @@ -16725,6 +16726,11 @@ static struct hda_verb alc272_dell_init_ {} }; +static struct hda_verb alc272_toshiba_init_verbs[] = { + {0x17, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT}, + {} +}; + static struct hda_verb alc663_mode7_init_verbs[] = { {0x15, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN}, {0x16, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN}, @@ -17255,6 +17261,36 @@ static void alc663_g50v_inithook(struct alc_mic_automute(codec); } +static void alc272_toshiba_speaker_automute(struct hda_codec *codec) +{ + unsigned int present; + unsigned char bits; + + present = snd_hda_jack_detect(codec, 0x21); + bits = present ? HDA_AMP_MUTE : 0; + snd_hda_codec_amp_stereo(codec, 0x17, HDA_OUTPUT, 0, + HDA_AMP_MUTE, bits); +} + +static void alc272_toshiba_unsol_event(struct hda_codec *codec, + unsigned int res) +{ + switch (res >> 26) { + case ALC880_HP_EVENT: + alc272_toshiba_speaker_automute(codec); + break; + case ALC880_MIC_EVENT: + alc_mic_automute(codec); + break; + } +} + +static void alc272_toshiba_init_hook(struct hda_codec *codec) +{ + alc272_toshiba_speaker_automute(codec); + alc_mic_automute(codec); +} + static struct snd_kcontrol_new alc662_ecs_mixer[] = { HDA_CODEC_VOLUME("Master Playback Volume", 0x02, 0x0, HDA_OUTPUT), ALC262_HIPPO_MASTER_SWITCH, @@ -17391,7 +17427,7 @@ static struct snd_pci_quirk alc662_cfg_t SND_PCI_QUIRK(0x105b, 0x0cd6, "Foxconn", ALC662_ECS), SND_PCI_QUIRK(0x105b, 0x0d47, "Foxconn 45CMX/45GMX/45CMX-K", ALC662_3ST_6ch_DIG), - SND_PCI_QUIRK(0x1179, 0xff6e, "Toshiba NB200", ALC663_ASUS_MODE4), + SND_PCI_QUIRK(0x1179, 0xff6e, "Toshiba NB200", ALC272_TOSHIBA_N200), SND_PCI_QUIRK(0x144d, 0xca00, "Samsung NC10", ALC272_SAMSUNG_NC10), SND_PCI_QUIRK(0x1458, 0xa002, "Gigabyte 945GCM-S2L", ALC662_3ST_6ch_DIG), @@ -17696,6 +17732,22 @@ static struct alc_config_preset alc662_p .setup = alc663_m51va_setup, .init_hook = alc663_m51va_inithook, }, + [ALC272_TOSHIBA_N200] = { + .mixers = { alc663_asus_21jd_clfe_mixer }, + .cap_mixer = alc662_auto_capture_mixer, + .init_verbs = { alc662_init_verbs, + alc663_21jd_amic_init_verbs, + alc272_toshiba_init_verbs }, + .num_dacs = ARRAY_SIZE(alc662_dac_nids), + .hp_nid = 0x03, + .dac_nids = alc662_dac_nids, + .dig_out_nid = ALC662_DIGOUT_NID, + .num_channel_mode = ARRAY_SIZE(alc662_3ST_2ch_modes), + .channel_mode = alc662_3ST_2ch_modes, + .unsol_event = alc272_toshiba_unsol_event, + .setup = alc663_mode4_setup, + .init_hook = alc272_toshiba_init_hook, + }, [ALC272_SAMSUNG_NC10] = { .mixers = { alc272_nc10_mixer }, .init_verbs = { alc662_init_verbs,

2 5

[alsa-devel] Audio suspend/resume status on OMAP3 based platforms
by Aggarwal, Anuj 15 Jan '10

15 Jan '10

Hi, I want to check the status of suspend/resume functionality when audio subsystem is being used. Specifically, has some one tried the following tests on their omap3 based platforms: a) echo mem > /sys/power/state, when audio playback is running in background b) same command, when audio capture is running in background b) same command, when audio loopback is running in background I am facing some issues with (b) & (c) so wanted to confirm whether someone else has faced similar problem or not. Regards, Anuj Aggarwal

5 6

[alsa-devel] [PATCH] ALSA: ASoC: support more sample rates on raumfeld devices
by Daniel Mack 15 Jan '10

15 Jan '10

Add support for sample rates other than 44100Khz on raumfeld audio devices. Force the codec's supported sample rates as the table of supported rates which is calculated at run-time does not suffice: if we call snd_soc_dai_set_sysclk() at stream startup, half of the possible rates are missing. Use the external audio clock generator to provide double data rate clocks as the PXA's internal baud generator does anything but what's described in the datasheets. Signed-off-by: Daniel Mack <daniel(a)caiaq.de> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Cc: Timur Tabi <timur(a)freescale.com> Signed-off-by: Daniel Mack <daniel(a)caiaq.de> --- sound/soc/pxa/raumfeld.c | 61 ++++++++++++++++++++++++++++++---------------- 1 files changed, 40 insertions(+), 21 deletions(-) diff --git a/sound/soc/pxa/raumfeld.c b/sound/soc/pxa/raumfeld.c index e713181..8d65a49 100644 --- a/sound/soc/pxa/raumfeld.c +++ b/sound/soc/pxa/raumfeld.c @@ -41,7 +41,9 @@ static struct i2c_board_info max9486_hwmon_info = { }; #define MAX9485_MCLK_FREQ_112896 0x22 -#define MAX9485_MCLK_FREQ_122880 0x23 +#define MAX9485_MCLK_FREQ_122880 0x23 +#define MAX9485_MCLK_FREQ_225792 0x32 +#define MAX9485_MCLK_FREQ_245760 0x33 static void set_max9485_clk(char clk) { @@ -71,9 +73,18 @@ static int raumfeld_cs4270_startup(struct snd_pcm_substream *substream) struct snd_soc_pcm_runtime *rtd = substream->private_data; struct snd_soc_dai *codec_dai = rtd->dai->codec_dai; - set_max9485_clk(MAX9485_MCLK_FREQ_112896); + codec_dai->playback.rates = SNDRV_PCM_RATE_44100 | + SNDRV_PCM_RATE_48000 | + SNDRV_PCM_RATE_88200 | + SNDRV_PCM_RATE_96000; + codec_dai->playback.rate_min = 44100; + codec_dai->playback.rate_max = 48000; - return snd_soc_dai_set_sysclk(codec_dai, 0, 11289600, 0); + codec_dai->capture.rates = codec_dai->playback.rates; + codec_dai->capture.rate_min = codec_dai->playback.rate_min; + codec_dai->capture.rate_max = codec_dai->playback.rate_max; + + return 0; } static int raumfeld_cs4270_hw_params(struct snd_pcm_substream *substream, @@ -86,20 +97,24 @@ static int raumfeld_cs4270_hw_params(struct snd_pcm_substream *substream, int ret = 0; switch (params_rate(params)) { - case 8000: - case 16000: + case 44100: + set_max9485_clk(MAX9485_MCLK_FREQ_112896); + clk = 11289600; + break; case 48000: - case 96000: set_max9485_clk(MAX9485_MCLK_FREQ_122880); clk = 12288000; break; - case 11025: - case 22050: - case 44100: case 88200: - set_max9485_clk(MAX9485_MCLK_FREQ_112896); - clk = 11289600; + set_max9485_clk(MAX9485_MCLK_FREQ_225792); + clk = 22579200; + break; + case 96000: + set_max9485_clk(MAX9485_MCLK_FREQ_245760); + clk = 24576000; break; + default: + return -EINVAL; } fmt = SND_SOC_DAIFMT_I2S | @@ -128,7 +143,7 @@ static int raumfeld_cs4270_hw_params(struct snd_pcm_substream *substream, if (ret < 0) return ret; - ret = snd_soc_dai_set_sysclk(cpu_dai, PXA_SSP_CLK_EXT, 0, 1); + ret = snd_soc_dai_set_sysclk(cpu_dai, PXA_SSP_CLK_EXT, clk, 1); if (ret < 0) return ret; @@ -181,20 +196,24 @@ static int raumfeld_ak4104_hw_params(struct snd_pcm_substream *substream, int fmt, ret = 0, clk = 0; switch (params_rate(params)) { - case 8000: - case 16000: + case 44100: + set_max9485_clk(MAX9485_MCLK_FREQ_112896); + clk = 11289600; + break; case 48000: - case 96000: set_max9485_clk(MAX9485_MCLK_FREQ_122880); clk = 12288000; break; - case 11025: - case 22050: - case 44100: case 88200: - set_max9485_clk(MAX9485_MCLK_FREQ_112896); - clk = 11289600; + set_max9485_clk(MAX9485_MCLK_FREQ_225792); + clk = 22579200; + break; + case 96000: + set_max9485_clk(MAX9485_MCLK_FREQ_245760); + clk = 24576000; break; + default: + return -EINVAL; } fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF; @@ -217,7 +236,7 @@ static int raumfeld_ak4104_hw_params(struct snd_pcm_substream *substream, if (ret < 0) return ret; - ret = snd_soc_dai_set_sysclk(cpu_dai, PXA_SSP_CLK_EXT, 0, 1); + ret = snd_soc_dai_set_sysclk(cpu_dai, PXA_SSP_CLK_EXT, clk, 1); if (ret < 0) return ret; -- 1.6.5.2

3 8

[alsa-devel] [PATCH] ALSA: Fix mute led GPIO on HP dv-series notebooks.
by Kunal Gangakhedkar 15 Jan '10

15 Jan '10

On my laptop (HP dv6-1110ax), there are no OEM strings in SMBIOS of type "HP_Mute_LED*". Hence, the GPIO for the mute button LED doesn't get set properly. I didn't find the strings in my cousin's laptop (HP dv9500t CTO) either. As per the documentation of find_mute_led_gpio(), these strings occur in HP B-series systems - so, before scanning the SMBIOS strings, we need to check if we're dealing with a B-series system. Need to get confirmation from HP if this logic takes care of all the systems. I'm trying to poke a friend there. Please let me know if this looks OK or needs changes. Signed-off-by: Kunal Gangakhedkar <kunal.gangakhedkar(a)gmail.com> --- sound/pci/hda/patch_sigmatel.c | 82 ++++++++++++++++++++++++++++++---------- 1 files changed, 62 insertions(+), 20 deletions(-) diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index 117919a..d421b3b 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -4737,6 +4737,8 @@ static void stac92xx_unsol_event(struct hda_codec *codec, unsigned int res) } } +static int hp_blike_system(u32 subsystem_id); + /* * This method searches for the mute LED GPIO configuration * provided as OEM string in SMBIOS. The format of that string @@ -4748,6 +4750,19 @@ static void stac92xx_unsol_event(struct hda_codec *codec, unsigned int res) * * So, HP B-series like systems may have HP_Mute_LED_0 (current models) * or HP_Mute_LED_0_3 (future models) OEM SMBIOS strings + * + * + * The dv-series laptops don't seem to have the HP_Mute_LED* strings in + * SMBIOS - at least the ones I have seen do not have them - which include + * my own system (HP Pavilion dv6-1110ax) and my cousin's + * HP Pavilion dv9500t CTO. + * Need more information on whether it is true across the entire series. + * + * The "else" could be converted into a conditional check for dv-series - + * say, hp_dv_series_system() - just like hp_blike_system(); however, + * I don't have all the PCI ids to identify the dv-series machines - maybe, + * we can add that later. + * -- kunal */ static int find_mute_led_gpio(struct hda_codec *codec) { @@ -4755,29 +4770,54 @@ static int find_mute_led_gpio(struct hda_codec *codec) const struct dmi_device *dev = NULL; if ((codec->subsystem_id >> 16) == PCI_VENDOR_ID_HP) { - while ((dev = dmi_find_device(DMI_DEV_TYPE_OEM_STRING, + if (hp_blike_system(codec->subsystem_id)) { + while ((dev = dmi_find_device(DMI_DEV_TYPE_OEM_STRING, NULL, dev))) { - if (sscanf(dev->name, "HP_Mute_LED_%d_%d", - &spec->gpio_led_polarity, - &spec->gpio_led) == 2) { - spec->gpio_led = 1 << spec->gpio_led; - return 1; - } - if (sscanf(dev->name, "HP_Mute_LED_%d", - &spec->gpio_led_polarity) == 1) { - switch (codec->vendor_id) { - case 0x111d7608: - /* GPIO 0 */ - spec->gpio_led = 0x01; - return 1; - case 0x111d7600: - case 0x111d7601: - case 0x111d7602: - case 0x111d7603: - /* GPIO 3 */ - spec->gpio_led = 0x08; + if (sscanf(dev->name, "HP_Mute_LED_%d_%d", + &spec->gpio_led_polarity, + &spec->gpio_led) == 2) { + spec->gpio_led = 1 << spec->gpio_led; return 1; } + if (sscanf(dev->name, "HP_Mute_LED_%d", + &spec->gpio_led_polarity) == 1) { + switch (codec->vendor_id) { + case 0x111d7608: + /* GPIO 0 */ + spec->gpio_led = 0x01; + return 1; + case 0x111d7600: + case 0x111d7601: + case 0x111d7602: + case 0x111d7603: + /* GPIO 3 */ + spec->gpio_led = 0x08; + return 1; + } + } + } + } else { + /* + * Pavilion dv series notebooks do not seem to have + * HP_Mute_LED* in SMBIOS. + * If HP decides to add it in dv series, + * we'll need to fix this part + * - or merge it with the B-like check above. + */ + switch (codec->vendor_id) { + case 0x111d7608: + /* GPIO 0 */ + spec->gpio_led = 0x01; + spec->gpio_led_polarity |= spec->gpio_led; + return 1; + case 0x111d7600: + case 0x111d7601: + case 0x111d7602: + case 0x111d7603: + /* GPIO 3 */ + spec->gpio_led = 0x08; + spec->gpio_led_polarity |= spec->gpio_led; + return 1; } } } @@ -5603,6 +5643,8 @@ again: spec->num_dmuxes = ARRAY_SIZE(stac92hd71bxx_dmux_nids); spec->num_smuxes = stac92hd71bxx_connected_smuxes(codec, 0x1e); + snd_printd("Found board config: %d\n", spec->board_config); + switch (spec->board_config) { case STAC_HP_M4: /* enable internal microphone */ -- 1.6.6.60.gc2ff1

2 8

[alsa-devel] [PATCH] alsa: use subsys_initcall for sound core instead of module_init
by Thadeu Lima de Souza Cascardo 15 Jan '10

15 Jan '10

This is needed for built-in drivers which are built before the sound directory, like thinkpad_acpi. Otherwise, registering a card fails. Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo(a)holoscopio.com> --- sound/core/sound.c | 4 ++-- sound/sound_core.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/core/sound.c b/sound/core/sound.c index 7872a02..563d196 100644 --- a/sound/core/sound.c +++ b/sound/core/sound.c @@ -468,5 +468,5 @@ static void __exit alsa_sound_exit(void) unregister_chrdev(major, "alsa"); } -module_init(alsa_sound_init) -module_exit(alsa_sound_exit) +subsys_initcall(alsa_sound_init); +module_exit(alsa_sound_exit); diff --git a/sound/sound_core.c b/sound/sound_core.c index dbca7c9..7c2d677 100644 --- a/sound/sound_core.c +++ b/sound/sound_core.c @@ -61,7 +61,7 @@ static void __exit cleanup_soundcore(void) class_destroy(sound_class); } -module_init(init_soundcore); +subsys_initcall(init_soundcore); module_exit(cleanup_soundcore); -- 1.6.6

2 6

Re: [alsa-devel] ALSA DMIX support without MMAP ?
by ANISH KUMAR 15 Jan '10

15 Jan '10

>For dmix, the stop_threshold should be equal to boundary value, thus XRUN >check should never be true. If you got xrun with dmix, something is wrong. DMIX is working now. > but when i am > playing with Plug PCM there is some noise in the song why????Is rate > conversion algoritm not able to resample it properly? >The default linear resampler is not very good quality. You may use some >sox resamplers from the alsa-plugins package, but they're more CPU >intensive. Check google. Actually i am working on soc platform(android-S3C6410) and wanted to use DMIX and some good resampler for my software mixing instead of current software mixing and resampling in upper layer(Above alsa-lib).DMIX is working fine but this resampling is causing some jitter.During rate conversion it looks for libasound_module_rate_speexrate.so which i don't have so its using default one causing the jitter. Can i build this .so file (as current way of alsa-plugin downloading will not work for me)?For sox resampler i guess i need to use differnet .so and corresponding changes in asound.conf file?? Can i get speex or sox resampler code so that i can build it for my system????? This code(speex or sox) i guess would have been integrated with alsa-lib so that alsa-lib can call corresponding functions of resampler source code. OR simply point me to url as googling is not helping.Everywhere i am getting this "you need to download plugins".This will not work in my case.

2 1