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

Re: [alsa-devel] [PATCH 10/10] OMAPDSS: HDMI: Implement DSS driver interface for audio
by Ricardo Neri 26 Apr '12

26 Apr '12

+alsa-devel list On 04/25/2012 01:19 AM, Tomi Valkeinen wrote: > On Tue, 2012-04-24 at 23:48 -0500, Ricardo Neri wrote: >> On 04/23/2012 08:01 AM, Tomi Valkeinen wrote: >>> On Wed, 2012-03-28 at 16:38 -0600, Ricardo Neri wrote: >>>> Implement the DSS device driver audio support interface in the HDMI >>>> panel driver and generic driver. The implementation relies on the >>>> IP-specific functions that are defined at DSS probe time. >>>> >>>> A HW-safe spinlock is used to protect the audio functions. This is because >>> >>> What is a "HW-safe spinlock"? >> Sorry, I meant a spinlock that disables the HW irqs when held:hardirq-safe. >> >>> >>>> the audio functions may be called while holding a lock; in such case, >>>> the panel's driver mutex is not suitable. Functions should be used >>>> to set registers and should not wait for any other event. >>> >>> Are you sure this is the only option? What lock is being held? >> For instance, ALSA calls the start audio function while holding a >> hardirq-safe readlock. Hence, when reaching the HDMI panel start >> function, a lock is held and irqs are disabled. Using a mutex, that >> might sleep, is not correct; nor it is using an hardirq-unsafe spinlock. >> Otherwise, deadlocks and/or inverse lock ordering may arise. This >> situation was signaled by lockdep. >> >> IMHO, as the DSS device driver does not know who is going to use it (at >> least the audio part), it should not assume that no locks are held when >> its functions are called. >> >>> While a spinlock may be ok for now, quite often enabling/disabling things do not >>> happen immediately,and it's much easier to do the wait synchronously. >> I don't understand this comment. To me, holding a lock until the >> enabling function returns is synchronous. Would you please clarify? > > I meant that quite often when enabling things on hardware it takes time > until the HW is actually up and running. Perhaps a regulator needs to be > started, or such. And it's usually simpler to wait for the HW to be up > synchronously in the enable function, instead of some kind of > asynchronous mechanism. And if a function waits synchronously, a mutex > is better than spinlock. > > And in that sense it's often better to define (define meaning, adding a > comment, or just mentally taking note about it) that the functions in > the API may sleep, so that the driver is free to do what is best for the > case, and it's also future-proof in a way that you can easily add > function calls that sleep to the functions in the future. > > But you are also right in your previous comment, it's better to define > functions so that they never sleep, as that gives the callers the > freedom to call the funcs in atomic context. > > Perhaps we can have audio_start() that never sleeps, it just enables a > few bits that start the audio. But how about audio_enable()? Is it > possible that on some OMAP version it would need to enable a regulator, > or set a gpio that's in an external i2c controlled mux chip, or such? I think it might be possible to have such a scenario if, for instance, an external chip is used to support DisplayPort on OMAP4/5. As DisplayPort can support audio-only use-cases, it would have to enable the adapter chip (but HDMI output would have to be enabled to feed the chip, though). > > If so, we need to make sure it's not currently called in an atomic > context, because it would break if the function will sleep in the > future. And with "make sure" I just mean that we check the code and keep > it in mind. Or perhaps adding a comment in the header, that says > "audio_enable may sleep, other audio functions do not sleep" or such. I revisited the ALSA code. Only the audio_start function is atomic. Although ALSA may not be the only user, it makes sense to me to think that they will follow a similar approach in terms of locks. Hence, based on that and on the reasons you describe (audio_enable potentially taking too long to return), Rephrasing what you stated, a mutex may be used for the enable/disable and config operations. Only start/stop would be protected by a spinlock. This should be described in comments in the header file. Does it make sense to you? BR, Ricardo > > Tomi

2 1

[alsa-devel] imx sgtl5000:BUG: scheduling while atomic: speaker-test/1225/0x00000003
by Richard Zhao 26 Apr '12

26 Apr '12

[ 13.901890] eth0: no IPv6 routers present [ 70.295079] BUG: scheduling while atomic: speaker-test/1225/0x00000003 [ 70.304293] Modules linked in: [ 70.310389] [<c0015a68>] (unwind_backtrace+0x0/0xec) from [<c0585810>] (dump_stack+0x20/0x24) [ 70.310421] [<c0585810>] (dump_stack+0x20/0x24) from [<c0585f6c>] (__schedule_bug+0x54/0x60) [ 70.310452] [<c0585f6c>] (__schedule_bug+0x54/0x60) from [<c058db64>] (__schedule+0x84/0x748) [ 70.310476] [<c058db64>] (__schedule+0x84/0x748) from [<c058e310>] (schedule+0x8c/0x90) [ 70.310500] [<c058e310>] (schedule+0x8c/0x90) from [<c058c504>] (schedule_timeout+0x2fc/0x35c) [ 70.310541] [<c058c504>] (schedule_timeout+0x2fc/0x35c) from [<c058d970>] (wait_for_common+0xd8/0x16c) [ 70.310567] [<c058d970>] (wait_for_common+0xd8/0x16c) from [<c058da44>] (wait_for_completion_timeout+0x1c/0x20) [ 70.310604] [<c058da44>] (wait_for_completion_timeout+0x1c/0x20) from [<c03352bc>] (sdma_run_channel+0x70/0x8c) [ 70.310634] [<c03352bc>] (sdma_run_channel+0x70/0x8c) from [<c0335614>] (sdma_load_context+0x188/0x19c) [ 70.310661] [<c0335614>] (sdma_load_context+0x188/0x19c) from [<c0335688>] (sdma_prep_dma_cyclic+0x60/0x1a8) [ 70.310694] [<c0335688>] (sdma_prep_dma_cyclic+0x60/0x1a8) from [<c04760f4>] (snd_dmaengine_pcm_trigger+0xa0/0x134) [ 70.310729] [<c04760f4>] (snd_dmaengine_pcm_trigger+0xa0/0x134) from [<c0483e68>] (soc_pcm_trigger+0x74/0xb0) [ 70.310770] [<c0483e68>] (soc_pcm_trigger+0x74/0xb0) from [<c046e670>] (snd_pcm_do_start+0x34/0x40) [ 70.310797] [<c046e670>] (snd_pcm_do_start+0x34/0x40) from [<c046e288>] (snd_pcm_action_single+0x48/0x74) [ 70.310823] [<c046e288>] (snd_pcm_action_single+0x48/0x74) from [<c046e334>] (snd_pcm_action+0x80/0x8c) [ 70.310850] [<c046e334>] (snd_pcm_action+0x80/0x8c) from [<c04707f0>] (snd_pcm_start+0x24/0x2c) [ 70.310877] [<c04707f0>] (snd_pcm_start+0x24/0x2c) from [<c0474058>] (snd_pcm_lib_write1+0x2a8/0x340) [ 70.310900] [<c0474058>] (snd_pcm_lib_write1+0x2a8/0x340) from [<c04741d0>] (snd_pcm_lib_write+0x70/0x7c) [ 70.311007] [<c04741d0>] (snd_pcm_lib_write+0x70/0x7c) from [<c04703f8>] (snd_pcm_playback_ioctl1+0x114/0x428) [ 70.311038] [<c04703f8>] (snd_pcm_playback_ioctl1+0x114/0x428) from [<c0470744>] (snd_pcm_playback_ioctl+0x38/0x44) [ 70.311077] [<c0470744>] (snd_pcm_playback_ioctl+0x38/0x44) from [<c0107234>] (do_vfs_ioctl+0x4f4/0x568) [ 70.311105] [<c0107234>] (do_vfs_ioctl+0x4f4/0x568) from [<c0107308>] (sys_ioctl+0x60/0x84) [ 70.311138] [<c0107308>] (sys_ioctl+0x60/0x84) from [<c000df40>] (ret_fast_syscall+0x0/0x30) [ 80.301928] ALSA sound/core/pcm_lib.c:1853 playback write error (DMA or IRQ trouble?) kernel: 3.4rc3 with ASoC/for-next and some my patches. Thanks Richard

2 3

[alsa-devel] [snd-usb-audio] frequent "delay: estimated xxx, actual yyy" messages
by Guillaume Clement 25 Apr '12

25 Apr '12

Hello, I am using an USB soundcard (ID : 046d:0a24 : Logitech Speaker Lapdesk N550). During playback, I have frequent messages like these : delay: estimated 795, actual 662 delay: estimated 133, actual 0 delay: estimated 751, actual 662 delay: estimated 89, actual 0 When those messages appear, I am hearing some "cracks" from the soundcard. I've tried to make some research on this, I only found some messages that hint about some interrupt problems. I'm not using any closed source driver and I can reproduce the issue with any computer running Linux. On interesting thing to notice is that it happens only when the CPU is near idle. To workaround the problem, I can just do something like : nice -n 20 dd if=/dev/zero of=/dev/null bs=1k count=500G This would keep my CPU busy and I have no more messages nor cracks. This does not seem to be a recent regression since I've experienced this since I bought the lapdesk in december or so. I am still experiencing this issue with the latest rc (linux-3.4rc3 at the moment) I tried using different .asoundrc setups, tried to install pulseaudio (usually I'm using bare alsa) and still experience the problem. Below is some information that might help locating the problem. I can make some test if needed and even code if I have some information on where the problem might me located. Note: those commands are typed during playback. $ cat /proc/asound/N550/stream0 Logitech, Inc. Logitech Speaker Lapdesk N550 at usb-0000:00:1d.0-2, full speed : USB Audio Playback: Status: Running Interface = 1 Altset = 1 URBs = 2 [ 20 20 ] Packet Size = 200 Momentary freq = 44100 Hz (0x2c.199a) Interface 1 Altset 1 Format: S16_LE Channels: 2 Endpoint: 1 OUT (ADAPTIVE) Rates: 44100, 48000 $ cat /proc/asound/N550/pcm0p/info card: 0 device: 0 subdevice: 0 stream: PLAYBACK id: USB Audio name: USB Audio subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 1 subdevices_avail: 0 $ cat /proc/asound/N550/pcm0p/sub0/hw_params access: RW_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 44100 (44100/1) period_size: 5513 buffer_size: 22050 $ cat /proc/asound/N550/pcm0p/sub0/info card: 0 device: 0 subdevice: 0 stream: PLAYBACK id: USB Audio name: USB Audio subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 1 subdevices_avail: 0 $ cat /proc/asound/N550/pcm0p/sub0/status state: RUNNING owner_pid : 1210 trigger_time: 3264.436419606 tstamp : 3302.883104696 delay : 20904 avail : 2646 avail_max : 21026 ----- hw_ptr : 1695160 appl_ptr : 1714564 $ cat /proc/asound/N550/pcm0p/sub0/sw_params tstamp_mode: NONE period_step: 1 avail_min: 5513 start_threshold: 16537 stop_threshold: 22050 silence_threshold: 0 silence_size: 0 boundary: 1445068800

3 4

[alsa-devel] [PATCH] fix bug 5579: invalid long long format specifier
by John Spencer 25 Apr '12

25 Apr '12

the attached patch fixes an invalid long long format specifier issue (%L was used by mistake, which is the long double specifier). this lead to abort() on 64bit system, making some of the alsa-utils unusable. --JS

3 3

[alsa-devel] [PATCH v2] ASoC: omap-pcm: Free dma buffers in case of error.
by Oleg Matcovschi 25 Apr '12

25 Apr '12

Change-Id: I4ba9de0de4681332539246ccc5e11a7a8fb32e79 Signed-off-by: Oleg Matcovschi <oleg.matcovschi(a)ti.com> --- v1: initial revision v2: resending patch including maintainers sound/soc/omap/omap-pcm.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index a2a464f..380a5bd 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -414,6 +414,10 @@ static int omap_pcm_new(struct snd_soc_pcm_runtime *rtd) } out: + /* free preallocated buffers in case of error */ + if (ret) + omap_pcm_free_dma_buffers(pcm); + return ret; } -- 1.7.4.1

5 4

[alsa-devel] Writing an ASoC codec driver for Beaglebone McASP
by Ulrik Kjems 25 Apr '12

25 Apr '12

I am working on connecting audio from the beaglebone McASP to a codec on an eval board, supporting a general TDM format. I know for sure the setup is viable because I have the system running in a bare-metal configuration using Starterware. I want to make it work under Linux ALSA/ASoC. I am willing to share the source code if anyone is interested in working on this as well. To do this I need to configure/write a driver for ALSA/ASoC, and my goal is to be able to perform multi-channel sound capture and playback using ALSA. The current kernel (3.2.14) davinci platform driver (davinci-evm.c) apparantly supports TI's AM3358 EVM board, which uses the same ARM3358 Sitara processor as the Beaglebone. The EVM board uses a similar (but not identical) McASP config (and a TLV320AIC3x codec, I believe). When booting the kernel on the Beaglebone the ALSA driver fails to register with the McASP. I can see in soc-core.c around line 825 that four client devices must be found: codec, codec_dai, platform, and platform_dai. By modifying sound/soc/davinci/davinci-evm.c to reflect the fact that for beaglebone McASP 0 is being used (as opposed to the EVM board where mcasp 1 is in use), I can make the platform register: static struct snd_soc_dai_link am335x_evm_dai = { .name = "TLV320AIC3X", .stream_name = "AIC3X", // .cpu_dai_name = "davinci-mcasp.1", .cpu_dai_name = "davinci-mcasp.0", // <<<<<<<Changed .codec_dai_name = "tlv320aic3x-hifi", .codec_name = "tlv320aic3x-codec.1-001b", .platform_name = "davinci-pcm-audio", .init = evm_aic3x_init, .ops = &evm_ops, }; Now, all I need is for the codec to register. If I look at /sys/kernel/debug/asoc/ I can see the davinci platform now (the above change enables this) ~# cat /sys/kernel/debug/asoc/platforms davinci-pcm-audio ~# cat /sys/kernel/debug/asoc/dais davinci-mcasp.0 ~# cat /sys/kernel/debug/asoc/codecs # No codecs! ~# Of course, I dont have the codec tlv320aic3x-hifi on my system,- but for now I would be happy configuring my codec manually (as I said its on an eval board with a config software tool I can use in place of I2C) so that I could get sound through the system. So my question is, how do I go about convincing ALSA that its OK not to have the codec? Is there a generic codec I could use as a starting point (e.g. setting codec_dai_name in the above struct to something else)? I dont understand the kernel code well enough to see why and how the kernel can detect the absence of the TLV codec above - I dont seem to be getting any calls to any of the functions inside sound/soc/codecs/tlv320aic3x.c except aic3x_modinit(void) - how on earth does the system know the codec is not there ?

1 0

[alsa-devel] Logical device name for 4-channel microphones?
by Tanu Kaskinen 25 Apr '12

25 Apr '12

Hi, What is the best source of information about device names ("front", "surround40" etc)? Is it the DeviceNames wiki page[1]? That page was slightly out of date, so I updated and expanded it (review would be welcome). I'm looking for information specifically about capture device names. The wiki page didn't help me there, as it only listed playback device names. My problem is that I'd like to make Pulseaudio handle 4-channel webcam microphones[2], but I'm not aware of any input device names for 4-channel devices. Are there such device names? If not, what should be done? Pulseaudio could just use "hw", but I'd prefer there to be a standard device name for 4-channel mics. AFAIK, at playback side, some surround implementations are using multiple devices on one card, and using "hw" wouldn't work in those cases, while e.g. "surround40" can use the multiple devices behind the scenes. I would guess that the same could be the case with some multichannel microphones, and therefore a logical name like "fourchannelmic" would be better than using "hw". [1] http://www.alsa-project.org/main/index.php/DeviceNames [2] https://bugs.freedesktop.org/show_bug.cgi?id=45813 -- Tanu

3 5

[alsa-devel] [PATCH 1/3] ASoC: SSM2602: Add sysclk based rate constraints
by Lars-Peter Clausen 25 Apr '12

25 Apr '12

Not all advertised rates are available for all sysclk frequencies. Add additional sysclk based rate constraints. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- sound/soc/codecs/ssm2602.c | 38 ++++++++++++++++++++++++++++++++++---- 1 file changed, 34 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/ssm2602.c b/sound/soc/codecs/ssm2602.c index 4c94fd2..dcedd74 100644 --- a/sound/soc/codecs/ssm2602.c +++ b/sound/soc/codecs/ssm2602.c @@ -53,6 +53,7 @@ enum ssm2602_type { /* codec private data */ struct ssm2602_priv { unsigned int sysclk; + struct snd_pcm_hw_constraint_list *sysclk_constraints; enum snd_soc_control_type control_type; struct snd_pcm_substream *master_substream; struct snd_pcm_substream *slave_substream; @@ -195,6 +196,24 @@ static const struct snd_soc_dapm_route ssm2604_routes[] = { {"ADC", NULL, "Line Input"}, }; +static const unsigned int ssm2602_rates_12288000[] = { + 8000, 32000, 48000, 96000, +}; + +static struct snd_pcm_hw_constraint_list ssm2602_constraints_12288000 = { + .list = ssm2602_rates_12288000, + .count = ARRAY_SIZE(ssm2602_rates_12288000), +}; + +static const unsigned int ssm2602_rates_11289600[] = { + 8000, 44100, 88200, +}; + +static struct snd_pcm_hw_constraint_list ssm2602_constraints_11289600 = { + .list = ssm2602_rates_11289600, + .count = ARRAY_SIZE(ssm2602_rates_11289600), +}; + struct ssm2602_coeff { u32 mclk; u32 rate; @@ -320,6 +339,12 @@ static int ssm2602_startup(struct snd_pcm_substream *substream, } else ssm2602->master_substream = substream; + if (ssm2602->sysclk_constraints) { + snd_pcm_hw_constraint_list(substream->runtime, 0, + SNDRV_PCM_HW_PARAM_RATE, + ssm2602->sysclk_constraints); + } + return 0; } @@ -361,16 +386,21 @@ static int ssm2602_set_dai_sysclk(struct snd_soc_dai *codec_dai, return -EINVAL; switch (freq) { - case 11289600: - case 12000000: case 12288000: - case 16934400: case 18432000: - ssm2602->sysclk = freq; + ssm2602->sysclk_constraints = &ssm2602_constraints_12288000; + break; + case 11289600: + case 16934400: + ssm2602->sysclk_constraints = &ssm2602_constraints_11289600; + break; + case 12000000: + ssm2602->sysclk_constraints = NULL; break; default: return -EINVAL; } + ssm2602->sysclk = freq; } else { unsigned int mask; -- 1.7.9.5

2 3

[alsa-devel] [PATCH v2] ASoC: bf5xx-ssm2602: Setup sysclock in init callback
by Lars-Peter Clausen 25 Apr '12

25 Apr '12

The sysclock is fixed, so just set it up once in the init callback instead of setting it repeatably in the hw_params callback. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- Since v1: * Fix duplicate use of bf5xx_ssm2602_init function name. Sorry, I amended the wrong commit before sending out v1... --- sound/soc/blackfin/bf5xx-ssm2602.c | 37 ++++-------------------------------- 1 file changed, 4 insertions(+), 33 deletions(-) diff --git a/sound/soc/blackfin/bf5xx-ssm2602.c b/sound/soc/blackfin/bf5xx-ssm2602.c index b39ad35..7dbeef1 100644 --- a/sound/soc/blackfin/bf5xx-ssm2602.c +++ b/sound/soc/blackfin/bf5xx-ssm2602.c @@ -44,16 +44,8 @@ static struct snd_soc_card bf5xx_ssm2602; -static int bf5xx_ssm2602_hw_params(struct snd_pcm_substream *substream, - struct snd_pcm_hw_params *params) +static int bf5xx_ssm2602_dai_init(struct snd_soc_pcm_runtime *rtd) { - struct snd_soc_pcm_runtime *rtd = substream->private_data; - struct snd_soc_dai *codec_dai = rtd->codec_dai; - unsigned int clk = 0; - int ret = 0; - - pr_debug("%s rate %d format %x\n", __func__, params_rate(params), - params_format(params)); /* * If you are using a crystal source which frequency is not 12MHz * then modify the below case statement with frequency of the crystal. @@ -61,31 +53,10 @@ static int bf5xx_ssm2602_hw_params(struct snd_pcm_substream *substream, * If you are using the SPORT to generate clocking then this is * where to do it. */ - - switch (params_rate(params)) { - case 8000: - case 16000: - case 48000: - case 96000: - case 11025: - case 22050: - case 44100: - clk = 12000000; - break; - } - - ret = snd_soc_dai_set_sysclk(codec_dai, SSM2602_SYSCLK, clk, + return snd_soc_dai_set_sysclk(rtd->codec_dai, SSM2602_SYSCLK, 12000000, SND_SOC_CLOCK_IN); - if (ret < 0) - return ret; - - return 0; } -static struct snd_soc_ops bf5xx_ssm2602_ops = { - .hw_params = bf5xx_ssm2602_hw_params, -}; - /* CODEC is master for BCLK and LRC in this configuration. */ #define BF5XX_SSM2602_DAIFMT (SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | \ SND_SOC_DAIFMT_CBM_CFM) @@ -98,7 +69,7 @@ static struct snd_soc_dai_link bf5xx_ssm2602_dai[] = { .codec_dai_name = "ssm2602-hifi", .platform_name = "bfin-i2s-pcm-audio", .codec_name = "ssm2602.0-001b", - .ops = &bf5xx_ssm2602_ops, + .init = bf5xx_ssm2602_dai_init, .dai_fmt = BF5XX_SSM2602_DAIFMT, }, { @@ -108,7 +79,7 @@ static struct snd_soc_dai_link bf5xx_ssm2602_dai[] = { .codec_dai_name = "ssm2602-hifi", .platform_name = "bfin-i2s-pcm-audio", .codec_name = "ssm2602.0-001b", - .ops = &bf5xx_ssm2602_ops, + .init = bf5xx_ssm2602_dai_init, .dai_fmt = BF5XX_SSM2602_DAIFMT, }, }; -- 1.7.9.5

2 1

[alsa-devel] [PATCH 1/2] ASoC: bf5xx-ssm2602: Set DAI format
by Lars-Peter Clausen 25 Apr '12

25 Apr '12

Commit 980b0bc69 ("ASoC: blackfin: Use dai_fmt") converted the blackfin ASoC machine drivers to use the dai_links dai_fmt field to setup their DAI format. For the bf5xx-ssm2602 the commit removed the manual call to snd_soc_dai_set_fmt, but missed to set the dai_links dai_fmt field. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- The commit that introduced the problem is only in 3.4-rc --- sound/soc/blackfin/bf5xx-ssm2602.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/blackfin/bf5xx-ssm2602.c b/sound/soc/blackfin/bf5xx-ssm2602.c index df3ac73..b39ad35 100644 --- a/sound/soc/blackfin/bf5xx-ssm2602.c +++ b/sound/soc/blackfin/bf5xx-ssm2602.c @@ -99,6 +99,7 @@ static struct snd_soc_dai_link bf5xx_ssm2602_dai[] = { .platform_name = "bfin-i2s-pcm-audio", .codec_name = "ssm2602.0-001b", .ops = &bf5xx_ssm2602_ops, + .dai_fmt = BF5XX_SSM2602_DAIFMT, }, { .name = "ssm2602", @@ -108,6 +109,7 @@ static struct snd_soc_dai_link bf5xx_ssm2602_dai[] = { .platform_name = "bfin-i2s-pcm-audio", .codec_name = "ssm2602.0-001b", .ops = &bf5xx_ssm2602_ops, + .dai_fmt = BF5XX_SSM2602_DAIFMT, }, }; -- 1.7.9.5

2 2