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

[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

[alsa-devel] soc-cache problem
by Cliff Cai 15 Jan '10

15 Jan '10

Hi all, Nowadays, soc tries to set up standard I/O functions with same addr_bits and data_bits for a codec. My problem is some codec might have registers with different data length.i.e.ADAU1761, Most of its registers are 8 bits long except PLL register,which is a 8 bytes long one.In order to set/read PLL , a block of data(8 bytes) needs to be transfer to/from the PLL register at a time. So, if soc-cache needs to consider this kind of case, or just keep it in local driver? Thanks Cliff

2 1

Re: [alsa-devel] VGN-P11Z_G (hda-intel ALC262) internal microphone not working
by Daniel Chen 15 Jan '10

15 Jan '10

Hi, Takashi, On Wed, Jan 13, 2010 at 12:28 PM, Christian Stöveken <christian.stoeveken(a)gmail.com> wrote: > sorry to get back to you so late - I tried again 5 minutes ago and it is now > working with the false parameter removed (/etc/modules:9: snd-hda-intel > model=vaio) > > working "model=auto": > http://www.alsa-project.org/db/?f=67f6a692f0ccd70d6893665d36c8b90a51f4a577 > > also with "power_save=10 power_save_controller=N model=auto": > http://www.alsa-project.org/db/?f=618f4d4ae530957b4b6d2b66751871d4073df685 > > I hope this is how you expected it to look like. > Also the headphones now work correctly. Attached is a patch against current sound-2.6 master HEAD that: * adds Christian's SSID to the relevant quirk table, * prefers BIOS autoprobing for existing Sony VAIO models matching 0x104d90xx. The second change was made to ease backing out the change in case of regressions. Best, -Dan

3 6

Re: [alsa-devel] [PATCH 0/5] PCM mmap (temporary) fixes for non-coherent architectures
by Takashi Iwai 15 Jan '10

15 Jan '10

At Fri, 1 Jan 2010 20:31:30 +0100, Andreas Mohr wrote: > > Hi, > > I've tried this patch set (with the typo-corrected part 4) on my ASUS > WL-500gP v2 MIPSEL via a backport to 2.6.31.9, but all I get is a > small blip of the sound I wanted to play, and then the system is fubar > (I believe just the same thing as what happened without having this patch > applied). As I mentioned in the previous followup, if your device is a USB-audio, the patch doesn't help because it's for devices with buffers using dma_alloc_coherent(). For USB-audio, it uses vmalloc for an intermediate buffer. Maybe this should be changed to dma_*() stuff for such architectures. Nevertheless, I don't know whether the crash is related with the audio part... Takashi

3 8

Re: [alsa-devel] hda_intel.c patch requested for Teradici
by Maher Fahmi 15 Jan '10

15 Jan '10

ALSA Team, Sorry to bother you with this again. I haven't yet received confirmation (or rejection) from the moderator, and just wondering if there's anything else I can/should do. Best regards & Happy New Year, Maher. ________________________________ From: Maher Fahmi Sent: Friday, December 04, 2009 1:41 PM To: 'alsa-devel(a)alsa-project.org' Subject: hda_intel.c patch requested for Teradici Alsa Team, Enclosed is a patch to the hda_intel.c file from the alsa-driver-1.0.21 package. I tried to submit this using git, but ran into some problems that exceed my limited understanding of Linux. I hope this will suffice for you. Summary: Fix to a HW issue in which the 64OK register bit of the GCAP register is incorrectly asserted. Signed-off-by: Maher Fahmi mfahmi(a)teradici.com Thanks very much, Maher.

2 1

[alsa-devel] snd_pcm_avail_update returns 0
by Singaravelan Nallasellan 14 Jan '10

14 Jan '10

Hi, Our audio driver uses the indirect PCM data transfer mechanism to transfer the buffer pointers and the size of the buffer to the Audio engine which DMAs the PCM data to the sound card. The driver uses the .ack callback to receive the buffer pointer and the size. It also sends it to the audio engine. We are facing a problem when we play long wav file using our driver. The application has written the PCM data and the ring buffer is full. snd_pcm_avail_update returns 0 sporadically. But the .ack callback was not called. The playback is stuck. It is not progressing. I have tried with pulseaudio (0.9.15) and with my own player. Both gives the same result. I would appreciate if somebody could provide some pointer to identify the cause of this issue. Let me know if anybody needs more info. Thanks Sing

2 5