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

[alsa-devel] [patch 0/6] kirkwood openrd client audio support - v2
by apatard＠mandriva.com 17 May '10

17 May '10

[ added forgotten linux-arm-kernel cc: ] Hi, It's a new try to get merged support for openrd client audio. I've tried to fix all comments, I hope I didn't miss something. In the changes, there's : - s/kirkwood/orion/ - Added a comment about data centered around 0 in the new control entry - fixed quilt diffstat header braindamage - added dapm support to cs42l51 codec - use ASoC register cache support - modified i2s driver to be a platform driver and move resource stuff to the right place Arnaud Patard

3 13

[alsa-devel] snd_pcm_period_elapsed
by Raymond Yau 16 May '10

16 May '10

>>> do snd_pcm_period_elapsed really handle the case when more than one period >>> are elasped ? >>> >>> For au88x0 , each substream have four sets of hardware registers , it seem >>> that the driver can recover lost interrupt with no underrun when using very >>> small period size >>> >>> >>> http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/ch05s07.html#pcm-… <http://www.alsa-project.org/%7Etiwai/writing-an-alsa-driver/ch05s07.html#pc…> >>> >>> On calling snd_pcm_period_elapsed() >>> >>> In both cases, even if more than one period are elapsed, you don't have to >>> call snd_pcm_period_elapsed() many times. Call only once. And the pcm layer >>> will check the current hardware pointer and update to the latest status. >> Yes, the new code handles more alapsed periods, too. The in_interrupt >> check is mainly for situations when period count == 1 and it compares >> expected next hw_ptr for interrupt with hw_ptr computed from the hw_base >> and actual position in the ring buffer. >> Jaroslav The value "delta" returned by vortex_adbdma_bufshift() seem to be the number of sub-buffer(periods) elapsed ( the value can be 0 , 1 , 2 or 3 ) when aplay using very small period_size (e.g. 16 ) , the driver write message in system log when delta > 1 (i.e. more than 1 period have been elapsed ) but the sound is still ok since there are two more periods in the sub-buffer But I cannot see any code in snd_pcm_period_elasped() add two period size to hw_ptr

1 0

[alsa-devel] [PATCH] hdspmixer buffer overflow
by Georg Rudolph 15 May '10

15 May '10

Hello, to fix https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5006 the attached patch for alsa-tools is proposed: Summary: Fix buffer overflow in hdspmixer A one off string buffer overflow fixed by handling it properly with string stream. Signed-off-by: Georg Rudolph <georg.rudolph(a)schwaben.de <mailto:foo@bar.com>> --- alsa-tools-1.0.23/hdspmixer/src/HDSPMixerIOMixer.h 2010-04-16 13:11:09.000000000 +0200 +++ alsa-tools-1.0.23-work/hdspmixer/src/HDSPMixerIOMixer.h 2010-05-12 22:07:49.549949993 +0200 @@ -36,6 +36,7 @@ #include "HDSPMixerStripData.h" #include "HDSPMixerMeter.h" #include "pixmaps.h" +#include <sstream> class HDSPMixerWindow; class HDSPMixerSelector; @@ -52,7 +53,7 @@ private: char **p_iomixer_xpm; int channel_num, relative_num, mixer_type; - char channel_name[6]; + std::stringstream channel_name; void update_child(Fl_Widget &widget); public: HDSPMixerStripData *data[3][3][8]; /* data[card][mode(ss/ds/qs)][preset number] */ --- alsa-tools-1.0.23/hdspmixer/src/HDSPMixerIOMixer.cxx 2010-04-16 13:11:09.000000000 +0200 +++ alsa-tools-1.0.23-work/hdspmixer/src/HDSPMixerIOMixer.cxx 2010-05-12 22:00:26.754950707 +0200 @@ -25,9 +25,9 @@ { mixer_type = type; if (type) { - sprintf(channel_name, "Out %d", ch); + channel_name << "Out " << ch; } else { - sprintf(channel_name, "In %d", ch); + channel_name << "In " << ch; } channel_num = ch; if (channel_num%2) { @@ -73,7 +73,7 @@ draw_background(); fl_color(FL_BLACK); fl_font(FL_HELVETICA, 8); - fl_draw(channel_name, x()+4, y()+225, 27, 9, FL_ALIGN_CENTER); + fl_draw(channel_name.str().c_str(), x()+4, y()+225, 27, 9, FL_ALIGN_CENTER); for (int i=children(); i--;) { Fl_Widget& o = **a++; draw_child(o); Best Regards, Georg Rudolph

2 1

[alsa-devel] HDA Intel - Activating S/PDIF output on an HP laptop (8510W).
by Huw Hawkins 15 May '10

15 May '10

Hi all, I have been quite happily using the intel HDA drivers to get audio on my Compaq 8510W, everything works fine out of the box with the exception of the HDMI output. After some poking around I see that this is because the digital output is disabled by the HP model specific code. Setting the model as "basic" gives me perfect audio on the HDMI output, but jack sensing is completely messed up, the mute button status is inverted and it is not possible to get sound from the internal speakers. Setting the model as "HP" diables the digital audio on the HDMI port. It seems from a google search that there are a few people around with the same issue on HP laptops with HDMI output. I don't really have the time to dig through and understand the spec/code for the driver to try to fix the problem myself. On the other hand I probably could spend an hour or two over the next couple of weeks testing or investigating the hardware if someone else wants to have a go. Any takers? Huw

1 0

[alsa-devel] [patch -next] sound/asihpi: incorrect range check
by Dan Carpenter 14 May '10

14 May '10

The entity_type_to_size[] array has LAST_ENTITY_TYPE (11) number of elements, not LAST_ENTITY_ROLE (17). This only affects the debug output. Signed-off-by: Dan Carpenter <error27(a)gmail.com> diff --git a/sound/pci/asihpi/hpifunc.c b/sound/pci/asihpi/hpifunc.c index 254c580..eda26b3 100644 --- a/sound/pci/asihpi/hpifunc.c +++ b/sound/pci/asihpi/hpifunc.c @@ -3407,7 +3407,7 @@ u16 hpi_entity_alloc_and_pack(const enum e_entity_type type, if (hE) return hE; - HPI_DEBUG_ASSERT(role > entity_role_null && type < LAST_ENTITY_ROLE); + HPI_DEBUG_ASSERT(role > entity_role_null && type < LAST_ENTITY_TYPE); bytes_to_copy = entity_type_to_size[type] * item_count; total_size = hpi_entity_header_size(*entity) + bytes_to_copy;

1 0

[alsa-devel] [PATCH] OMAP: McBSP: Add 32-bit mode support
by Sergey Lapin 14 May '10

14 May '10

This patchs should allow to use 32-bit samples on e.g. TLV320AIC3x codec, or others. Signed-off-by: Sergey Lapin <slapin(a)ossfans.org> --- sound/soc/omap/omap-mcbsp.c | 28 ++++++++++++++++++++++++---- 1 files changed, 24 insertions(+), 4 deletions(-) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 8ad9dc9..2dead3f 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -295,8 +295,18 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, omap_mcbsp_dai_dma_params[id][substream->stream].dma_req = dma; omap_mcbsp_dai_dma_params[id][substream->stream].port_addr = port; omap_mcbsp_dai_dma_params[id][substream->stream].sync_mode = sync_mode; - omap_mcbsp_dai_dma_params[id][substream->stream].data_type = - OMAP_DMA_DATA_TYPE_S16; + switch (params_format(params)) { + case SNDRV_PCM_FORMAT_S16_LE: + omap_mcbsp_dai_dma_params[id][substream->stream].data_type = + OMAP_DMA_DATA_TYPE_S16; + break; + case SNDRV_PCM_FORMAT_S32_LE: + omap_mcbsp_dai_dma_params[id][substream->stream].data_type = + OMAP_DMA_DATA_TYPE_S32; + break; + default: + return -EINVAL; + } snd_soc_dai_set_dma_data(cpu_dai, substream, &omap_mcbsp_dai_dma_params[id][substream->stream]); @@ -330,6 +340,14 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, regs->xcr2 |= XWDLEN2(OMAP_MCBSP_WORD_16); regs->xcr1 |= XWDLEN1(OMAP_MCBSP_WORD_16); break; + case SNDRV_PCM_FORMAT_S32_LE: + /* Set word lengths */ + wlen = 32; + regs->rcr2 |= RWDLEN2(OMAP_MCBSP_WORD_32); + regs->rcr1 |= RWDLEN1(OMAP_MCBSP_WORD_32); + regs->xcr2 |= XWDLEN2(OMAP_MCBSP_WORD_32); + regs->xcr1 |= XWDLEN1(OMAP_MCBSP_WORD_32); + break; default: /* Unsupported PCM format */ return -EINVAL; @@ -623,13 +641,15 @@ static struct snd_soc_dai_ops omap_mcbsp_dai_ops = { .channels_min = 1, \ .channels_max = 16, \ .rates = OMAP_MCBSP_RATES, \ - .formats = SNDRV_PCM_FMTBIT_S16_LE, \ + .formats = SNDRV_PCM_FMTBIT_S16_LE | \ + SNDRV_PCM_FMTBIT_S32_LE, \ }, \ .capture = { \ .channels_min = 1, \ .channels_max = 16, \ .rates = OMAP_MCBSP_RATES, \ - .formats = SNDRV_PCM_FMTBIT_S16_LE, \ + .formats = SNDRV_PCM_FMTBIT_S16_LE | \ + SNDRV_PCM_FMTBIT_S32_LE, \ }, \ .ops = &omap_mcbsp_dai_ops, \ .private_data = &mcbsp_data[(link_id)].bus_id, \ -- 1.7.0.4

5 4

[alsa-devel] [RFC][PATCH] fall back to reserved minor numbers
by Wu Fengguang 14 May '10

14 May '10

When the static minor numbers collide because of too many devices, fall back to the reserved minor numbers 2 and 3. This for example will allow Intel HDMI audio driver to create three PCM devices (index 3, 7, 8; the minor number of the last index will otherwise collide with the first record device). The other option is to force enable CONFIG_SND_DYNAMIC_MINORS. Signed-off-by: Wu Fengguang <fengguang.wu(a)intel.com> --- include/sound/minors.h | 4 +++- sound/core/sound.c | 10 ++++++++-- 2 files changed, 11 insertions(+), 3 deletions(-) --- drm-intel.orig/include/sound/minors.h 2010-05-13 10:06:52.000000000 +0800 +++ drm-intel/include/sound/minors.h 2010-05-13 10:10:06.000000000 +0800 @@ -35,7 +35,9 @@ #define SNDRV_MINOR_TIMER (SNDRV_MINOR_GLOBAL + 1 * 32) #ifndef CONFIG_SND_DYNAMIC_MINORS - /* 2 - 3 (reserved) */ + +#define SNDRV_MINOR_BACKUP1 2 +#define SNDRV_MINOR_BACKUP2 3 #define SNDRV_MINOR_HWDEP 4 /* 4 - 7 */ #define SNDRV_MINOR_RAWMIDI 8 /* 8 - 15 */ #define SNDRV_MINOR_PCM_PLAYBACK 16 /* 16 - 23 */ --- drm-intel.orig/sound/core/sound.c 2010-05-13 10:06:04.000000000 +0800 +++ drm-intel/sound/core/sound.c 2010-05-13 10:11:19.000000000 +0800 @@ -269,8 +269,14 @@ int snd_register_device_for_dev(int type minor = snd_find_free_minor(); #else minor = snd_kernel_minor(type, card, dev); - if (minor >= 0 && snd_minors[minor]) - minor = -EBUSY; + if (minor >= 0) { + if (snd_minors[minor]) + minor = SNDRV_MINOR_BACKUP1; + if (snd_minors[minor]) + minor = SNDRV_MINOR_BACKUP2; + if (snd_minors[minor]) + minor = -EBUSY; + } #endif if (minor < 0) { mutex_unlock(&sound_mutex);

2 3

[alsa-devel] [PATCH 0/5] updates for Intel SandyBridge/CougarPoint HDMI codec
by Wu Fengguang 14 May '10

14 May '10

Hi Takashi, The Intel SandyBridge/CougarPoint HDMI codec is very similar to the IbexPeak HDMI codec, except that it exports one more Audio Converter. Now we have 3 Audio Converters, each of them present one HDMI PCM device: (and expect a 4th HDMI PCM device in future) $ aplay -l | grep HDMI card 0: PCH [HDA Intel PCH], device 3: INTEL HDMI 0 [INTEL HDMI 0] card 0: PCH [HDA Intel PCH], device 7: INTEL HDMI 1 [INTEL HDMI 1] card 0: PCH [HDA Intel PCH], device 8: INTEL HDMI 2 [INTEL HDMI 2] So ALSA has to support more than 8 PCM playback devices now. The first two patches do this dirty work, however I'm not sure if they will introduce some side effects. The last three patches are more straightforward and safe. Thanks, Fengguang

5 19

Re: [alsa-devel] [PATCH v3 0/2] McBSP changes for OMAP4 platform
by Liam Girdwood 14 May '10

14 May '10

On Thu, 2010-05-13 at 09:19 +0100, Mark Brown wrote: > On Wed, May 12, 2010 at 12:18:38PM -0500, Jorge Eduardo Candelaria wrote: > > The following patches enable McBSP driver to be used along with the > > audio driver in SDP4430 and other OMAP4 based boards. > > Both > > Acked-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Tony, do we have you ack/sob to upstream via ASoC ? We do have a lot pending with mcbsp dependencies for ASoC atm and this would simplify upstreaming. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk

2 1

[alsa-devel] underruns over network
by Preston Kulaga 13 May '10

13 May '10

Hello, I am quite new to ALSA and am having a bit of trouble with underruns. I am working on a voice communication system via udp sockets and am getting underruns on receiving end very sporadically (capture end is fine). Have done a great deal of reading and searching on reasons for this but am not sure what approach is best to limit the underruns. I must not be transferring the data quickly enough over the network before the ring buffer runs out of data, which makes sense, but how would you accommodate for this? I am able to buffer a large amount of network data and then playback successfully, but obviously the delay induced is so significant that it makes real-time communication impossible. If I just recover/prepare the stream after an underrun the audio is horribly distorted. Is there a normal way of dealing with this issue that I am unable to find? I would appreciate any insight, guidance, references for any help you can give me. Thank You.

1 0