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

[alsa-devel] [PATCH] ASoC: cs42l73: Sync digital mixer kcontrols to allow for 0dB
by Brian Austin 11 May '12

11 May '12

Some of the Digital mixer kcontrol max values were off by 1 not allowing a max of 0dB. Signed-off-by: Brian Austin <brian.austin(a)cirrus.com> --- sound/soc/codecs/cs42l73.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/sound/soc/codecs/cs42l73.c b/sound/soc/codecs/cs42l73.c index 5a537b7..e0d45fd 100644 --- a/sound/soc/codecs/cs42l73.c +++ b/sound/soc/codecs/cs42l73.c @@ -565,22 +565,22 @@ static const struct snd_kcontrol_new cs42l73_snd_controls[] = { attn_tlv), SOC_SINGLE_TLV("SPK-IP Mono Volume", - CS42L73_SPKMIPMA, 0, 0x3E, 1, attn_tlv), + CS42L73_SPKMIPMA, 0, 0x3F, 1, attn_tlv), SOC_SINGLE_TLV("SPK-XSP Mono Volume", - CS42L73_SPKMXSPA, 0, 0x3E, 1, attn_tlv), + CS42L73_SPKMXSPA, 0, 0x3F, 1, attn_tlv), SOC_SINGLE_TLV("SPK-ASP Mono Volume", - CS42L73_SPKMASPA, 0, 0x3E, 1, attn_tlv), + CS42L73_SPKMASPA, 0, 0x3F, 1, attn_tlv), SOC_SINGLE_TLV("SPK-VSP Mono Volume", - CS42L73_SPKMVSPMA, 0, 0x3E, 1, attn_tlv), + CS42L73_SPKMVSPMA, 0, 0x3F, 1, attn_tlv), SOC_SINGLE_TLV("ESL-IP Mono Volume", - CS42L73_ESLMIPMA, 0, 0x3E, 1, attn_tlv), + CS42L73_ESLMIPMA, 0, 0x3F, 1, attn_tlv), SOC_SINGLE_TLV("ESL-XSP Mono Volume", - CS42L73_ESLMXSPA, 0, 0x3E, 1, attn_tlv), + CS42L73_ESLMXSPA, 0, 0x3F, 1, attn_tlv), SOC_SINGLE_TLV("ESL-ASP Mono Volume", - CS42L73_ESLMASPA, 0, 0x3E, 1, attn_tlv), + CS42L73_ESLMASPA, 0, 0x3F, 1, attn_tlv), SOC_SINGLE_TLV("ESL-VSP Mono Volume", - CS42L73_ESLMVSPMA, 0, 0x3E, 1, attn_tlv), + CS42L73_ESLMVSPMA, 0, 0x3F, 1, attn_tlv), SOC_ENUM("IP Digital Swap/Mono Select", ip_swap_enum), -- 1.7.10

2 1

[alsa-devel] [PATCH] usb-audio: Fix comment
by Mark Hills 11 May '12

11 May '12

Explained by Takashi in <s5hfwbtmz0q.wl%tiwai(a)suse.de> > The reason is because get_min_max*() isn't called in the place you > created these controls, and get_min_max() would be called only for > integer volumes later even if uninitialized. A short cut for booleans. Signed-off-by: Mark Hills <mark(a)pogo.org.uk> --- sound/usb/mixer_quirks.c | 12 ++---------- 1 files changed, 2 insertions(+), 10 deletions(-) diff --git a/sound/usb/mixer_quirks.c b/sound/usb/mixer_quirks.c index 12125ca..41f4b69 100644 --- a/sound/usb/mixer_quirks.c +++ b/sound/usb/mixer_quirks.c @@ -79,16 +79,8 @@ static int snd_create_std_mono_ctl(struct usb_mixer_interface *mixer, cval->control = control; cval->cmask = cmask; - /* FIXME: Do we need this? - * The following values are for compatibility with - * Ebox-44 mixer. - * But the corresponding ebox-44 function says: - * "Volume controls will override these values" - * - * These values don't have any effect at all for - * M-Audio FTUs. - * So I think, we can safely omit the range settings here. - */ + /* get_min_max() is called only for integer volumes later, + * so provide a short-cut for booleans */ cval->min = 0; cval->max = 1; cval->res = 0; -- 1.7.4.4

2 1

[alsa-devel] ALSA calling pcm_pointer excessively?
by Russell King - ARM Linux 11 May '12

11 May '12

I'm wondering what is causing ALSA to behave as follows - I have a 64KiB buffer, which is divided up into 4 16KiB periods. The log below is from my soc-dmaengine.c code which supports audio on the Assabet (as we don't have cyclic DMA support there yet.) I'm just trying to sort out the DMA engine tx_status residue code, and am using this as proof that its working. However, it seems that ALSA for whatever reason likes to hammer away at the pcm_pointer callback from time to time: soc_dmaengine_pointer: index 3 stat 1 residue 0018 cookie 3cfe pos 10000 bytes ffe8 soc_dmaengine_pointer: index 3 stat 1 residue 0008 cookie 3cfe pos 10000 bytes fff8 soc_dmaengine_callback: complete soc_dmaengine_pointer: index 0 stat 1 residue 3ff0 cookie 3cff pos 4000 bytes 0010 soc_dmaengine_submit: submitting index 3 size 4000 cookie 3d02 soc_dmaengine_pointer: index 0 stat 1 residue 3fd0 cookie 3cff pos 4000 bytes 0030 soc_dmaengine_pointer: index 0 stat 1 residue 17b8 cookie 3cff pos 4000 bytes 2848 soc_dmaengine_pointer: index 0 stat 1 residue 1770 cookie 3cff pos 4000 bytes 2890 soc_dmaengine_pointer: index 0 stat 1 residue 1768 cookie 3cff pos 4000 bytes 2898 soc_dmaengine_pointer: index 0 stat 1 residue 1758 cookie 3cff pos 4000 bytes 28a8 soc_dmaengine_pointer: index 0 stat 1 residue 1748 cookie 3cff pos 4000 bytes 28b8 soc_dmaengine_pointer: index 0 stat 1 residue 1740 cookie 3cff pos 4000 bytes 28c0 soc_dmaengine_pointer: index 0 stat 1 residue 1730 cookie 3cff pos 4000 bytes 28d0 soc_dmaengine_pointer: index 0 stat 1 residue 1720 cookie 3cff pos 4000 bytes 28e0 soc_dmaengine_pointer: index 0 stat 1 residue 1718 cookie 3cff pos 4000 bytes 28e8 ... soc_dmaengine_pointer: index 0 stat 1 residue 0018 cookie 3cff pos 4000 bytes 3fe8 soc_dmaengine_pointer: index 0 stat 1 residue 0008 cookie 3cff pos 4000 bytes 3ff8 soc_dmaengine_callback: complete soc_dmaengine_pointer: index 1 stat 1 residue 3ff0 cookie 3d00 pos 8000 bytes 4010 soc_dmaengine_submit: submitting index 0 size 4000 cookie 3d03 soc_dmaengine_pointer: index 1 stat 1 residue 3fd0 cookie 3d00 pos 8000 bytes 4030 soc_dmaengine_pointer: index 1 stat 1 residue 3b28 cookie 3d00 pos 8000 bytes 44d8 soc_dmaengine_pointer: index 1 stat 1 residue 3b10 cookie 3d00 pos 8000 bytes 44f0 soc_dmaengine_pointer: index 1 stat 1 residue 3b00 cookie 3d00 pos 8000 bytes 4500 'pos' is the end of the current DMA buffer ((index + 1) * period_byte_size) 'residue' is the value returned from tx_status 'bytes' is the value passed into bytes_to_frames() to return from my pcm_pointer function. The question is - what would cause ALSA to hammer away at the buffer like that - checking it every 16 or 8 DMA bytes transferred? I'm also seeing around 75% system CPU time, which really isn't good. The above was captured while aplay was running, with no apparant audio corruption. Any ideas?

5 20

Re: [alsa-devel] Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED]
by Takashi Iwai 11 May '12

11 May '12

[Re-added Cc to alsa-devel to let others following] At Fri, 11 May 2012 10:37:44 -0300, Dâniel Fraga wrote: > > On Fri, 11 May 2012 09:43:48 +0200 > Takashi Iwai <tiwai(a)suse.de> wrote: > > > Does it mean that you have no headphone, or does the machine have no > > headphone jack? > > The machine has a headphone jack, but I never use a headphone. > > > That's why I'm asking to test. Usually when such a noise occurs due > > to the auto-mute feature, it's because the bogus unsolicited events > > are fired up too much although no jack is plugged actually. Thus > > usually the auto-mute feature itself doesn't work in such a case > > (either no hardware implementation or the hardware has its own > > switching mechanism.) > > I understand. Ok... so you want me to plug the headphone and > test if the auto-mute works right? Ok, I did that and yes, it works > fine as expected (the audio from speakers is automatically muted when a > headphone is inserted). Hm, so it's strange that the auto-mute causes a problem. Could you check which unsolicited events are triggered on your machine? When you build your kernel with the tracing support (CONFIG_TRACEPOINTS=y), you can enable the tracing via % echo 1 > /sys/kernel/debug/tracing/events/hda/hda_unsol_event/enable then after some time, gather the result by checking /sys/kernel/debug/tracing/trace file. The output is like below. % cat /sys/kernel/debug/tracing/trace # tracer: nop # # entries-in-buffer/entries-written: 4/4 #P:4 # # _-----=> irqs-off # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / delay # TASK-PID CPU# |||| TIMESTAMP FUNCTION # | | | |||| | | <idle>-0 [001] d.h3 10157.942108: hda_unsol_event: [0] res=10010020, res_ex=10 <idle>-0 [001] d.h3 10158.848271: hda_unsol_event: [0] res=10010000, res_ex=10 ..... Check whether the events come up frequently even without plugging/unplugging any jacks. Usually this shouldn't happen. But in the case of problematic hardware with the auto-mute, many bogus unsol events are triggered. thanks, Takashi

2 5

[alsa-devel] Realtek ACL892: audio gap ~ each 10 seconds?
by Dâniel Fraga 11 May '12

11 May '12

I changed my motherboard to Asus P8Z68V-Pro/gen3 and it uses the Realtek ACL892. Everything works, except for the fact that the sound has a "gap" each 10 seconds... it's annoying... it's just like a small pop or click... What can I do to debug that? Is there a workaround I can try? Thanks. -- Linux 3.3.0: Saber-toothed Squirrel http://www.youtube.com/DanielFragaBR

4 11

[alsa-devel] [PATCH 1/1] aplay: print vu-meter to stderr, not stdout
by Jerome Carretero 11 May '12

11 May '12

It allows showing the vu-meter while recording to stdout, eg: aplay -C -V stereo | oggenc - > out.ogg Signed-off-by: Jerome Carretero <cJ(a)zougloub.eu> diff --git a/aplay/aplay.c b/aplay/aplay.c index 1ce34c4..8462484 100644 --- a/aplay/aplay.c +++ b/aplay/aplay.c @@ -1453,9 +1453,9 @@ static void print_vu_meter_mono(int perc, int maxperc) sprintf(line + val, "| MAX"); else sprintf(line + val, "| %02i%%", maxperc); - fputs(line, stdout); + fputs(line, stderr); if (perc > 100) - printf(_(" !clip ")); + fprintf(stderr, _(" !clip ")); } static void print_vu_meter_stereo(int *perc, int *maxperc) @@ -1493,7 +1493,7 @@ static void print_vu_meter_stereo(int *perc, int *maxperc) memcpy(line + bar_length, tmp, 3); } line[bar_length * 2 + 6 + 2] = 0; - fputs(line, stdout); + fputs(line, stderr); } static void print_vu_meter(signed int *perc, signed int *maxperc) @@ -1631,9 +1631,9 @@ static void compute_max_peak(u_char *data, size_t count) if (perc[c] > maxperc[c]) maxperc[c] = perc[c]; - putchar('\r'); + putc('\r', stderr); print_vu_meter(perc, maxperc); - fflush(stdout); + fflush(stderr); } else if(verbose==3) { printf(_("Max peak (%li samples): 0x%08x "), (long)ocount, max_peak[0]); @@ -1642,8 +1642,8 @@ static void compute_max_peak(u_char *data, size_t count) putchar('#'); else putchar(' '); - printf(" %i%%\n", perc[0]); - fflush(stdout); + fprintf(stderr, " %i%%\n", perc[0]); + fflush(stderr); } } -- 1.7.10

2 2

[alsa-devel] [PATCH 0/6] Add device tree support for mxs audio
by Shawn Guo 11 May '12

11 May '12

This series adds device tree probe for mxs-saif driver and mxs-sgtl5000 ASoC machine driver, and is tested on imx28-evk board. It's based on sound, clkdev, mxs pinctrl and DT branches, and probably easier to have it go through arm-soc with sound/for-3.5 pulled in as dependency. Shawn Guo (6): ASoC: mxs: add __devinit for mxs_saif_probe ASoC: mxs: use devm_clk_get for mxs_saif_probe ASoC: mxs: mxs-pcm does not need to be a plaform_driver ASoC: mxs: add device tree support for mxs-saif ASoC: mxs: add device tree support for mxs-sgtl5000 ARM: dts: enable audio support for imx28-evk .../bindings/sound/mxs-audio-sgtl5000.txt | 17 +++ .../devicetree/bindings/sound/mxs-saif.txt | 36 ++++++ arch/arm/boot/dts/imx28-evk.dts | 41 +++++++ arch/arm/boot/dts/imx28.dtsi | 23 ++++ sound/soc/mxs/mxs-pcm.c | 24 +--- sound/soc/mxs/mxs-pcm.h | 3 + sound/soc/mxs/mxs-saif.c | 119 +++++++++++--------- sound/soc/mxs/mxs-saif.h | 1 - sound/soc/mxs/mxs-sgtl5000.c | 61 ++++++++++- 9 files changed, 253 insertions(+), 72 deletions(-)

3 24

Re: [alsa-devel] Getting alsa on Caanoo
by Clemens Ladisch 11 May '12

11 May '12

Marc Nostromo [M-.-n] wrote: > > The alsa-driver package has the snddevices script, but it works only if > > the kernel was compiled without CONFIG_SND_DYNAMIC_MINORS. > > So I should be able to use it to create the devices ? Yes. Regards, Clemens

1 0

[alsa-devel] Getting alsa on Caanoo
by Marc Nostromo [M-.-n] 11 May '12

11 May '12

Hi, I'm trying to get alsa to work on an open source korean game console called the caanoo http://en.wikipedia.org/wiki/CAANOO It's open source and pretty cheap with respect to the horse power it delivers, so using it as base for an embedded synth / sequencer makes a lot of sense to me. I've successfully compiled and loaded the modules for audio & midi support but I'm still stuck with the last step so I wondered if I could get any help over here, I hope it's the right place to ask. Right now, when I connect a midi device through USB, I get the following console message root@wiz:/mnt/sd/ko_s# dmesg > usb 1-1: new full speed USB device using UBI9032 Test HCD and address 2 > usb 1-1: configuration #1 chosen from 1 choice > MIDIStreaming version 01.00 > EP 82: 1 jack(s) > EP 02: 1 jack(s) > created 1 output and 1 input ports And querying /proc/asound gives me root@wiz:/mnt/sd/ko_s# cat /proc/asound/* > 0 [nanoKONTROL ]: USB-Audio =96 nanoKONTROL > KORG INC. nanoKONTROL at usb-ubisys-usb-1, full speed > 0: [ 0] : control > 1: : sequencer > 8: [ 0- 0]: raw midi > 33: : timer 0 snd_usb_audio > G0: system timer : 10000.000us (10000000 ticks) > Advanced Linux Sound Architecture Driver Version 1.0.15 (Tue Nov 20 > 19:16:42 2007 UTC). So I'm thinking I'm on the right track. But I don't see anything in /dev to connect to so I can't really do anything with my device. _From what I read here http://www.gp32x.com/board/index.php?/topic/60064-usbrs232-device-with-the-= caanoo/page__p__954641&#entry954641 it could be due to the fact /dev is mounted in read-only (and that there's no /dev/midiXX present) and that I need to create the device file with mknod. However I'm not sure of what I should do in the specific context of midi/audio with alsa. Right now all I'm looking for is raw midi & pcm out. Could anyone give me a clue as what to try next ? Thanks a lot Marc --- http://www.marc-nostromo.com

3 2

[alsa-devel] [PATCH] atmel/ac97c: correct the unexpected behavior when using uninitial value for reset pin
by Bo Shen 11 May '12

11 May '12

When pdata->reset_pin is passed with a negative value (means gpio is invalid), then chip->reset_pin will not be assigned to a vaule, it will use default value 0. This will cause unexpected behavior. So, add this patch to correct. Signed-off-by: Bo Shen <voice.shen(a)atmel.com> Acked-by: Nicolas Ferre <nicolas.ferre(a)atmel.com> --- sound/atmel/ac97c.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/atmel/ac97c.c b/sound/atmel/ac97c.c index 115313e..f5ded64 100644 --- a/sound/atmel/ac97c.c +++ b/sound/atmel/ac97c.c @@ -991,6 +991,8 @@ static int __devinit atmel_ac97c_probe(struct platform_device *pdev) gpio_direction_output(pdata->reset_pin, 1); chip->reset_pin = pdata->reset_pin; } + } else { + chip->reset_pin = -EINVAL; } snd_card_set_dev(card, &pdev->dev); -- 1.7.10

2 1