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

[alsa-devel] [PATCH] ALSA: HDA: Add Sony VAIO quirk for ALC269
by David Henningsson 26 Aug '10

26 Aug '10

The attached patch enables playback on a Sony VAIO machine. References: http://launchpadlibrarian.net/53762567/Card0.Codecs.codec.0.txt http://launchpadlibrarian.net/53762571/PciMultimedia.txt https://bugs.launchpad.net/bugs/618271 -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic

3 4

[alsa-devel] explicit commandline control of speakers vs headphone output
by Eric Holstege 26 Aug '10

26 Aug '10

It appears that when I have a headphone plugged in, the speakers are automatically disabled and the output sound is sent to the headphone. However, I want to explicitly control (e.g. via a script or commandline - not a GUI) whether the sound from an (arbitrary) application is going to the speakers or to the headphone even when the headphone is plugged in. (When I say "arbitrary application" that means I can't alter the code of the application itself). Is this possible? (I have heard that ALSA mutes the speakers when it detects plugged-in headphones. Is switching between them as simple as using e.g. amixer(1) to unmute the speakers and mute the headphones and vice versa, or is there more to it.)

2 1

[alsa-devel] [PATCH 0/3] alsa-lib: UCM - Use Case Manager
by Liam Girdwood 25 Aug '10

25 Aug '10

This patch series follows on from the RFC and adds sound card hardware Use Case Management support to alsa-lib. The main features of UCM are :- o Abstraction of sound card hardware routing and controls into high level use case verbs, devices and modifiers. o Discovery of source/sink PCMs for each use case. o Discovery of hardware master volume controls for each use case. It's intended UCM will provide clients (like pulseaudio) complete control over hardware signal routing within a sound card without any knowledge of the sound card hardware. Use case definintions are stored in text files (per sound card) and are now divided into three components as descibed in the RFC. A working use case definition file can be found here :- http://git.slimlogic.co.uk/cgi-bin/cgit.cgi/alsa-ucm-conf.git/tree/cards/SD… The three components of a use case are now :- 1) Verb (or action). This is mandatory and describes (in terms of ALSA control settings) the system use case action. e.g "Phone Call", "Music Playback". 2) Device. This is also mandatory and describes the audio playback or capture device. e.g. "Handset", "Bluetooth", "Headset". 3) Modifier. This is optional and is used to modify the current use case verb. i.e. The user could be listening to music when an incoming phone call requires that a ring tone is played. In this case the use case verb would be set to "Music Playback" when the music playback started and then the "Tone Playback" modifier could be enabled to play the ring tone. The use case verb would then be changed to "Voice Call" if the call was accepted. Patch 2/3 is a little on the large side so, I've included a link if it gets bounced by the list. http://git.slimlogic.co.uk/cgi-bin/cgit.cgi/alsa-lib.git/commit/?h=ucm-upst… Liam Girdwood (3): ucm: header - ALSA Use Case Manager ucm: core - Add initial Use Case Manager support. ucm: build - add build support for Use Case Manager doc/doxygen.cfg.in | 1 + include/Makefile.am | 2 +- include/use-case.h | 427 +++++++ src/Makefile.am | 2 +- src/use-case.c | 3515 +++++++++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 3945 insertions(+), 2 deletions(-) create mode 100644 include/use-case.h create mode 100644 src/use-case.c

5 15

[alsa-devel] Loopback device conf/alias
by pl bossart 25 Aug '10

25 Aug '10

I played with the snd_aloop module that Jaroslav added a couple of days ago. It just does what I wanted and seems to work ok :-) Thanks for this patch! I would like however to expose this output as a PulseAudio profile. Using a string such as hw:%f conflicts with other analog output profiles, and the actual card index will vary depending on each hardware setup. Is there a way to have an alias or a configuration so that I could use a profile definition as aloop:%f in PulseAudio, and use arecord -Daloop for my monitoring app. By default the playback device would be 0 and the capture one 1. As long as the card index is handle automatically I am happy. I tried to play with alsa-lib .conf files, no luck (I really have no idea how this works). Any ideas on how to add an alias? Thanks for your feedback -Pierre

2 2

[PATCH] ASoC: Add optional prefix_map to snd_soc_card for prefixing codec kcontrols
by Jarkko Nikula 25 Aug '10

25 Aug '10

This optional prefix_map allows to specify unique ALSA control name prefixes for maching codec names. This makes possible to have a sound card configuration using multiple codecs without a name collision that would occur if a codec driver tries to register a kcontrol with an existing name. Now it is possible to specify for instance "Front" and "Rear" prefixes and a sound card can have two separate controls like "Front PCM Playback Volume" and "Rear PCM Playback Volume". Those controls will then show as "Front PCM" and "Rear PCM" in ALSA mixer application. Signed-off-by: Jarkko Nikula <jhnikula(a)gmail.com> --- include/sound/soc.h | 10 ++++++++++ sound/soc/soc-core.c | 35 +++++++++++++++++++++++++++++++++-- sound/soc/soc-dapm.c | 28 ++++++++++++++++++++++------ 3 files changed, 65 insertions(+), 8 deletions(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index d31e8b7..cc309af 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -423,6 +423,7 @@ struct snd_soc_ops { /* SoC Audio Codec device */ struct snd_soc_codec { const char *name; + const char *kcontrol_prefix; int id; struct device *dev; struct snd_soc_codec_driver *driver; @@ -553,6 +554,11 @@ struct snd_soc_dai_link { struct snd_soc_ops *ops; }; +struct snd_soc_prefix_map { + const char *codec_name; + const char *kcontrol_prefix; +}; + /* SoC card */ struct snd_soc_card { const char *name; @@ -587,6 +593,10 @@ struct snd_soc_card { struct snd_soc_pcm_runtime *rtd; int num_rtd; + /* optional map of name prefixes that are associated per codec */ + struct snd_soc_prefix_map *prefix_map; + int num_prefixes; + struct work_struct deferred_resume_work; /* lists of probed devices belonging to this card */ diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 65352c7..b17596f 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1266,6 +1266,23 @@ static void soc_remove_dai_link(struct snd_soc_card *card, int num) static void rtd_release(struct device *dev) {} +static void soc_set_name_prefix(struct snd_soc_card *card, + struct snd_soc_codec *codec) +{ + int i; + + if (card->prefix_map == NULL) + return; + + for (i = 0; i < card->num_prefixes; i++) { + struct snd_soc_prefix_map *map = &card->prefix_map[i]; + if (map->codec_name && !strcmp(codec->name, map->codec_name)) { + codec->kcontrol_prefix = map->kcontrol_prefix; + break; + } + } +} + static int soc_probe_dai_link(struct snd_soc_card *card, int num) { struct snd_soc_dai_link *dai_link = &card->dai_link[num]; @@ -1306,6 +1323,7 @@ static int soc_probe_dai_link(struct snd_soc_card *card, int num) /* probe the CODEC */ if (!codec->probed) { + soc_set_name_prefix(card, codec); if (codec->driver->probe) { ret = codec->driver->probe(codec); if (ret < 0) { @@ -1895,14 +1913,27 @@ int snd_soc_add_controls(struct snd_soc_codec *codec, const struct snd_kcontrol_new *controls, int num_controls) { struct snd_card *card = codec->card->snd_card; + char prefixed_name[44], *name; + const char *prefix = NULL; int err, i; + /* Only codec controls are prefixed */ + if (!codec->probed) + prefix = codec->kcontrol_prefix; + for (i = 0; i < num_controls; i++) { const struct snd_kcontrol_new *control = &controls[i]; - err = snd_ctl_add(card, snd_soc_cnew(control, codec, NULL)); + if (prefix) { + snprintf(prefixed_name, sizeof(prefixed_name), "%s %s", + prefix, control->name); + name = prefixed_name; + } else { + name = control->name; + } + err = snd_ctl_add(card, snd_soc_cnew(control, codec, name)); if (err < 0) { dev_err(codec->dev, "%s: Failed to add %s\n", - codec->name, control->name); + codec->name, name); return err; } } diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 035cab8..412f0bf 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -327,6 +327,7 @@ static int dapm_new_mixer(struct snd_soc_codec *codec, int i, ret = 0; size_t name_len; struct snd_soc_dapm_path *path; + char prefix[10]; /* add kcontrol */ for (i = 0; i < w->num_kcontrols; i++) { @@ -347,6 +348,13 @@ static int dapm_new_mixer(struct snd_soc_codec *codec, name_len = strlen(w->kcontrols[i].name) + 1; if (w->id != snd_soc_dapm_mixer_named_ctl) name_len += 1 + strlen(w->name); + if (codec->kcontrol_prefix) { + name_len += 1 + strlen(codec->kcontrol_prefix); + snprintf(prefix, sizeof(prefix), "%s ", + codec->kcontrol_prefix); + } else { + prefix[0] = '\0'; + } path->long_name = kmalloc(name_len, GFP_KERNEL); @@ -355,12 +363,12 @@ static int dapm_new_mixer(struct snd_soc_codec *codec, switch (w->id) { default: - snprintf(path->long_name, name_len, "%s %s", - w->name, w->kcontrols[i].name); + snprintf(path->long_name, name_len, "%s%s %s", + prefix, w->name, w->kcontrols[i].name); break; case snd_soc_dapm_mixer_named_ctl: - snprintf(path->long_name, name_len, "%s", - w->kcontrols[i].name); + snprintf(path->long_name, name_len, "%s%s", + prefix, w->kcontrols[i].name); break; } @@ -388,6 +396,7 @@ static int dapm_new_mux(struct snd_soc_codec *codec, { struct snd_soc_dapm_path *path = NULL; struct snd_kcontrol *kcontrol; + char prefixed_name[44], *name; int ret = 0; if (!w->num_kcontrols) { @@ -395,7 +404,14 @@ static int dapm_new_mux(struct snd_soc_codec *codec, return -EINVAL; } - kcontrol = snd_soc_cnew(&w->kcontrols[0], w, w->name); + if (codec->kcontrol_prefix) { + snprintf(prefixed_name, sizeof(prefixed_name), "%s %s", + codec->kcontrol_prefix, w->name); + name = prefixed_name; + } else { + name = w->name; + } + kcontrol = snd_soc_cnew(&w->kcontrols[0], w, name); ret = snd_ctl_add(codec->card->snd_card, kcontrol); if (ret < 0) goto err; @@ -406,7 +422,7 @@ static int dapm_new_mux(struct snd_soc_codec *codec, return ret; err: - printk(KERN_ERR "asoc: failed to add kcontrol %s\n", w->name); + printk(KERN_ERR "asoc: failed to add kcontrol %s\n", name); return ret; } -- 1.7.1

1 0

[alsa-devel] need help understanding overrun/underrun
by Harsha, Priya 24 Aug '10

24 Aug '10

Hi I had modified the arecord application to call snd_pcm_writei() with the output of snd_pcm_readi(). Basically a loopback. When we execute, I see the calls return EPIPE (lot of overruns and a few underruns). Can anyone help me understand why there are underrun/overrun being printed? Is it because of the serial call of reads and writes? Is there any issue with the driver I am using? Can you suggest some ways to overcome these messages? Thanks, Harsha

2 3

[alsa-devel] Install Infrasonic Amon on Ubuntu?
by Alberto Molina Díaz 24 Aug '10

24 Aug '10

I have a Infrasonic Amon usb audio interface, but I Can't use it in ubuntu beacuse I can't install it. The id of this sound card this is 1a4e:7021 ¿Anyone know how to install it? Thanks

2 2

[alsa-devel] snd_pcm_multi_rewind
by Raymond Yau 24 Aug '10

24 Aug '10

why the pos array can be assigned dimension by multi->slaves_count ? does sizeof(pos) return the correct size ? why input parameter "frames" can be modified ? frames = f; static snd_pcm_sframes_t snd_pcm_multi_rewind(snd_pcm_t *pcm, snd_pcm_uframes_t frames) { snd_pcm_multi_t *multi = pcm->private_data; unsigned int i; snd_pcm_uframes_t pos[multi->slaves_count]; memset(pos, 0, sizeof(pos)); for (i = 0; i < multi->slaves_count; ++i) { snd_pcm_t *slave_i = multi->slaves[i].pcm; snd_pcm_sframes_t f = snd_pcm_rewind(slave_i, frames); if (f < 0) return f; pos[i] = f; frames = f; } /* Realign the pointers */ for (i = 0; i < multi->slaves_count; ++i) { snd_pcm_t *slave_i = multi->slaves[i].pcm; snd_pcm_uframes_t f = pos[i] - frames; snd_pcm_sframes_t result; if (f > 0) { result = INTERNAL(snd_pcm_forward)(slave_i, f); if (result < 0) return result; if ((snd_pcm_uframes_t)result != f) return -EIO; } } return frames; }

2 1

[alsa-devel] [alsa-lib] Query regarding snd_config_update_free_global() and threads etc.
by Colin Guthrie 24 Aug '10

24 Aug '10

Hi there, I've got a (hopefully quick) query about snd_config_update_free_global() and it's general thread safetyness. I'm currently going insane on this bug: https://bugs.kde.org/show_bug.cgi?id=232068 which revolves around a bug manifested in snd_pcm_close() (or rather snd_pcm_ioplug_close()) when dealing with the ALSA->PulseAudio plugin. _From what I can gather, this problem is related to a KDE module that is loaded into the library in question which does some alsa probing and ultimately calls snd_config_update_free_global() several times. The library itself then goes on to use GStreamer to do actual audio output. The crash then manifests itself prior to any sound actually being output. I can reliably reproduce the machine on two machines (I don't have many at my disposal), but cannot reproduce on a third. The two I can reproduce it on are two and four core intel duo's. The one I cannot reproduce on is an older, single core machine. I am leaning towards some kind of thread safety issue. In searching for similar problems, I found several references to similar crashes attributed to snd_dlobj_cache_cleanup() perhaps not being thread safe. e.g.: https://bugzilla.redhat.com/show_bug.cgi?id=482797#c14 and http://osdir.com/ml/attachments/txtpisfDmzbcN.txt (and from that: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2124 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589896 ) I've found that removing the calls to snd_config_update_free_global() avoid the issue. I'm not even sure they are needed, but all the same I wanted to discuss the core issue. The MEMORY-LEAK file suggests that it should only be called after all snd_*_open() calls, but it doesn't indicate if this is just a recommendation or mandatory. Is the *only* purpose of this call to make valgrind happy? Or does it serve some other useful purpose too? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]

2 3

[alsa-devel] Implementing full-duplex realtime sound processor
by Gregory Bonik 23 Aug '10

23 Aug '10

Hi there, I'm trying to implement a full-duplex realtime sound processing app. I.e., it should capture a stream from a soundcard, do some processing on it and play it with minimal latency. I don't want to use JACK or any other higher-level API, so I'm looking for the best way to do it directly with ALSA. So far I've discovered three approaches: a) Just use blocking read/write functions. This approach seems flawed to me, since a separate thread is required for writing. Synchronizing between threds also introduces additional latency. b) Use the alsalib's asynchronous functionality. At first sight it sounds attractively, but googling for it gets not so happy results. For example, the alsa.opensrc.org wiki claims this functionality is unstable, especially in combination with PulseAudio. I don't know if it's true or not, but it discourages me even from trying it. c) Use synchronous I/O multiplexing (i.e poll syscall) together with non-blocking mode (much like doing I/O on network sockets). It becomes possible with the snd_pcm_poll_descriptors* family of functions. So I decided to try the third way first and wrote a simple test program. I'm using Ubuntu and therefore have PulseAudio sound system. So my program worked successfully through PulseAudio (i. e. with 'default' pcm). But when I tried to run it directly on hw:0,0, it hung in the poll() system call, waiting infinitely for an event on a capturing PCM, as if there was no data available for capturing. I started to look through ALSA API's functions and found occasionally snd_pcm_start. I've never seen it in any tutorial, but I decided to try calling it just after snd_pcm_prepare() for my capturing pcm handle and it did the trick. But if I call this function on a playback pcm handle, it fails with 'Broken pipe' error. To sum it up, I have the following questions: - What does actually snd_pcm_start() do? - Why does it fail on a playback device and do the job on a capture device? - Why does my program work without it when I'm using PulseAudio? - Am I generally on the right way or should I use other approach? Thanks, Gregory Bonik.

2 2