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

[PATCH] udev: Allow ALSA input jacks to be accessed by the current user
by David Henningsson 15 Jun '11

15 Jun '11

One missing piece for userspace (PulseAudio etc) to actually be able to use the jack input devices that ALSA create, is that these devices are accessible by root only. This patch makes the input device nodes accessible by the same users that can access the sound card: the current logged in user, as well as users in the audio group. Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- extras/input_id/input_id.c | 23 +++++++++++++++++++++++ extras/udev-acl/70-acl.rules | 1 + rules/rules.d/60-persistent-input.rules | 1 + 3 files changed, 25 insertions(+), 0 deletions(-) diff --git a/extras/input_id/input_id.c b/extras/input_id/input_id.c index ba53df0..814ce8e 100644 --- a/extras/input_id/input_id.c +++ b/extras/input_id/input_id.c @@ -189,6 +189,25 @@ static void test_key (struct udev *udev, puts("ID_INPUT_KEYBOARD=1"); } +static void test_sound (struct udev_device *dev, + const unsigned long* bitmask_sw) +{ + + struct udev_device *snd_dev; + + /* Ensure parent is sound card */ + snd_dev = udev_device_get_parent_with_subsystem_devtype(dev, "sound", NULL); + if (!snd_dev) + return; + + /* Check that there is at least one relevant switch type */ + if (test_bit(SW_HEADPHONE_INSERT, bitmask_sw) || + test_bit(SW_MICROPHONE_INSERT, bitmask_sw) || + test_bit(SW_LINEOUT_INSERT, bitmask_sw) || + test_bit(SW_VIDEOOUT_INSERT, bitmask_sw)) + puts("ID_INPUT_SNDJACK=1"); +} + static void help(void) { printf("Usage: input_id [options] <device path>\n" @@ -212,6 +231,7 @@ int main (int argc, char** argv) unsigned long bitmask_abs[NBITS(ABS_MAX)]; unsigned long bitmask_key[NBITS(KEY_MAX)]; unsigned long bitmask_rel[NBITS(REL_MAX)]; + unsigned long bitmask_sw[NBITS(SW_MAX)]; udev = udev_new(); if (udev == NULL) @@ -272,10 +292,13 @@ int main (int argc, char** argv) get_cap_mask (dev, "capabilities/abs", bitmask_abs, sizeof (bitmask_abs)); get_cap_mask (dev, "capabilities/rel", bitmask_rel, sizeof (bitmask_rel)); get_cap_mask (dev, "capabilities/key", bitmask_key, sizeof (bitmask_key)); + get_cap_mask (dev, "capabilities/sw", bitmask_sw, sizeof (bitmask_sw)); test_pointers(bitmask_ev, bitmask_abs, bitmask_key, bitmask_rel); test_key(udev, bitmask_ev, bitmask_key); + test_sound(dev, bitmask_sw); + return 0; } diff --git a/extras/udev-acl/70-acl.rules b/extras/udev-acl/70-acl.rules index 037349d..a6f54d9 100644 --- a/extras/udev-acl/70-acl.rules +++ b/extras/udev-acl/70-acl.rules @@ -25,6 +25,7 @@ SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="4|5", TAG+="udev-ac # sound devices SUBSYSTEM=="sound", TAG+="udev-acl" +SUBSYSTEM=="input", ENV{ID_INPUT_SNDJACK}=="1", TAG+="udev-acl" # ffado is an userspace driver for firewire sound cards SUBSYSTEM=="firewire", ENV{ID_FFADO}=="1", TAG+="udev-acl" diff --git a/rules/rules.d/60-persistent-input.rules b/rules/rules.d/60-persistent-input.rules index cd1de4e..d04c09e 100644 --- a/rules/rules.d/60-persistent-input.rules +++ b/rules/rules.d/60-persistent-input.rules @@ -12,6 +12,7 @@ ENV{ID_INPUT_MOUSE}=="?*", ENV{.INPUT_CLASS}="mouse" ENV{ID_INPUT_TOUCHPAD}=="?*", ENV{.INPUT_CLASS}="mouse" ENV{ID_INPUT_TABLET}=="?*", ENV{.INPUT_CLASS}="mouse" ENV{ID_INPUT_JOYSTICK}=="?*", ENV{.INPUT_CLASS}="joystick" +ENV{ID_INPUT_SNDJACK}=="?*", ENV{.INPUT_CLASS}="sndjack", GROUP="audio" DRIVERS=="pcspkr", ENV{.INPUT_CLASS}="spkr" ATTRS{name}=="*dvb*|*DVB*|* IR *", ENV{.INPUT_CLASS}="ir" -- 1.7.4.1 --------------060705090906040605070702--

1 0

[alsa-devel] Need Help About Submitting Updates to Existing ASoC Codec Driver [Re Post]
by Ashish P. Chavan 15 Jun '11

15 Jun '11

[Sorry for my previous post in which outlook messed up line breaks, Please ignore it. This is repost of the same message.] Hi, We are in the process of upgrading codec driver for Dialog's DA7210 codec (sound/soc/codecs/da7210.c). Existing driver in mainline is just bare minimum and doesn't support many of the chip's features. Our update would be a major functionality update in nature. Our final goal is to get the updated driver merged into mainline kernel. For this we just want to make sure that we follow correct process. As far as I understood from alsa-project.org and other resources, the normal process is to submit the patch against alsa-kenel (git.alsa-project.org:alsa-kernel.git alsa-kernel) and get it reviewed by maintainers there. Once all maintainers are satisfied with the patch, it will be eventually put in to for-linus branch and get in to mainline. Is this the correct approach and path to achieve our goal? Is there any obvious misunderstanding or missing step(s) here? Thanks, -- Ashish ---------------------------------------------------------------------------- || Linux Is User Friendly, It's Just Selective About Who It's Friend' Are || ----------------------------------------------------------------------------

2 1

[alsa-devel] [PATCH 1/8] ASoC: AD1836: drop unnecessary spi register check
by Mike Frysinger 15 Jun '11

15 Jun '11

The only thing the init func does is register a spi driver, so if that fails, we return the value back up to the caller who will display an error message for us. So drop the redundant checking/message. Signed-off-by: Mike Frysinger <vapier(a)gentoo.org> --- sound/soc/codecs/ad1836.c | 10 +--------- 1 files changed, 1 insertions(+), 9 deletions(-) diff --git a/sound/soc/codecs/ad1836.c b/sound/soc/codecs/ad1836.c index 754c496..d368539 100644 --- a/sound/soc/codecs/ad1836.c +++ b/sound/soc/codecs/ad1836.c @@ -315,15 +315,7 @@ static struct spi_driver ad1836_spi_driver = { static int __init ad1836_init(void) { - int ret; - - ret = spi_register_driver(&ad1836_spi_driver); - if (ret != 0) { - printk(KERN_ERR "Failed to register ad1836 SPI driver: %d\n", - ret); - } - - return ret; + return spi_register_driver(&ad1836_spi_driver); } module_init(ad1836_init); -- 1.7.5.3

3 12

Re: [alsa-devel] Headphone output doesn't work with 3.0.0-rc* anymore
by Takashi Iwai 15 Jun '11

15 Jun '11

At Thu, 9 Jun 2011 13:14:01 +0200, Michal Hocko wrote: > > On Thu 09-06-11 11:44:41, Takashi Iwai wrote: > > At Thu, 9 Jun 2011 11:28:26 +0200, > > Michal Hocko wrote: > > > > > > [1 <text/plain; us-ascii (7bit)>] > > > On Thu 09-06-11 11:20:04, Takashi Iwai wrote: > > > > At Thu, 9 Jun 2011 11:06:07 +0200, > > > > Michal Hocko wrote: > > > > > > > > > > On Thu 09-06-11 10:56:16, Michal Hocko wrote: > > > > > > On Thu 09-06-11 08:09:18, Takashi Iwai wrote: > > > > > > > At Wed, 8 Jun 2011 19:48:55 +0200, > > > > > [...] > > > > > > > Thanks, that's helpful. > > > > > > > As a quirk solution, could you try to pass model=auto option to > > > > > > > snd-hda-intel module? > > > > > > > > > > > > Headphones work now but speakers are quite... I have tried to play > > > > > > with Headphone and Speaker controls in alsamixer but no changes. > > > > > > > > > > > > Here is what I get in logs when the module is loaded: > > > > > > [ 5320.360277] HDA Intel 0000:00:1b.0: PCI INT A disabled > > > > > > [ 5326.920247] HDA Intel 0000:00:1b.0: power state changed by ACPI to D0 > > > > > > [ 5326.920262] HDA Intel 0000:00:1b.0: power state changed by ACPI to D0 > > > > > > [ 5326.920279] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 > > > > > > [ 5326.920375] HDA Intel 0000:00:1b.0: irq 42 for MSI/MSI-X > > > > > > [ 5326.920405] HDA Intel 0000:00:1b.0: setting latency timer to 64 > > > > > > [ 5326.981085] input: HDA Intel Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input18 > > > > > > [ 5326.981262] input: HDA Intel Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input19 > > > > > > [ 5326.987934] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input20 > > > > > > > > > > > > [maybe not important but input numbers are increasing for every new load] > > > > > > > > > > > > There is another strange thing. After I stop mplayer and wait for some > > > > > > time (~1min) I can hear a "click" sound and then there is no sound at > > > > > > all... If I start mplayer in the meantime it just works... > > > > > > If I try to remove the module and load it again then things work and stop > > > > > > working after first playback again. > > > > > > > > > > And I have just found out that I do not have to start any playback to > > > > > see this. It is sufficient to load the module and wait a minute and > > > > > there is no sound at all (both from speakers or headphones). > > > > > > > > OK, could you give alsa-info.sh outputs at both working and > > > > non-working states? > > > > > > Sure. Attached. The only change seems to be: > > > Node 0x02 [Audio Output] wcaps 0x11: Stereo > > > Device: name="ALC262 Analog", type="Audio", device=0 > > > - Converter: stream=5, channel=0 > > > + Converter: stream=0, channel=0 > > > > This is OK. It shows that the converter was assigned once to this > > stream when you played back a sound before power-save. > > > > As long as the codec registers show the same value, it's not obviously > > what went wrong. The symptom sounds like a resume issue. If so, > > S3/S4 might show the same problem. > > > > BTW, does my patch fix the problem when you load without model=auto? > > I have just booted to the rc2 with the patch (https://lkml.org/lkml/2011/6/9/25) > and it looks it didn't solve the problem. Playback works only from > speakers when headphones are not plugged in - no sound if plugged in. So, the auto-mute now works but now the headphone doesn't work. Weird... Maybe the same reason the speaker doesn't work with auto-mode. I saw that the only one converter keeps the stream in your alsa-info.sh output although multiple converters (0x02, 0x03, 0x06) should be used simultaneously. > See alsa-info.txt-fresh-boot. Same thing happens if I > modprobe -r snd-hda-intel and then load it again (without any parameters). > > > If yes, does the problem appear with it? I.e. is the silence problem > > specific to model=auto or not? > > If I try to modproble with model=auto I get headphones working but not > output from speakers. Have a look at alsa-info.txt-modprobe_auto. For testing, just copy 2.6.39/sound/pci/*.[ch] into 3.0 tree and rebuild. Does it work as expected? If you have a good-working reference, please take alsa-info.sh output while playing back a stream. Note that the one-minute thing happens only when you unplug AC cable, supposedly. Or, simply write some value (in seconds) to /sys/modules/snd_hda_intel/parameters/powersave and access the device once (either mixer or PCM) to activate the power-saving mode. thanks, Takashi

3 16

[alsa-devel] Need Help About Submitting Updates to Existing ASoC Codec Driver
by Ashish P. Chavan 15 Jun '11

15 Jun '11

Hi, We are in the process of upgrading codec driver for Dialog's DA7210 codec (sound/soc/codecs/da7210.c). Existing driver in mainline is just bare minimum and doesn't support many of the chip's features. Our update would be a major functionality update in nature. Our final goal is to get the updated driver merged into mainline kernel. For this we just want to make sure that we follow correct process. As far as I understood from alsa-project.org and other resources, the normal process is to submit the patch against alsa-kenel (git.alsa-project.org:alsa-kernel.git alsa-kernel) and get it reviewed by maintainers there. Once all maintainers are satisfied with the patch, it will be eventually put in to for-linus branch and get in to mainline. Is this the correct approach and path to achieve our goal? Is there any obvious misunderstanding or missing step(s) here? Thanks, -- Ashish ---------------------------------------------------------------------------- || Linux Is User Friendly, It's Just Selective About Who It's Friend' Are || ----------------------------------------------------------------------------

1 0

[alsa-devel] IEC61937/SPDIF
by ajay khandelwal 14 Jun '11

14 Jun '11

Hi All, I have to develop driver for SPDIF output of my board connected to HDMI. I'm not sure for following (specially IEC61937) 1) How should driver know if it is compressed audio or plain pcm 2) Is their any plugin available for IEC61937, I could see only for IEC958 3) Who should create burst preamble, some plug in or driver. Thanks and Regards, Ajay

3 2

[alsa-devel] [PATCH v3] ASoC: dapm - Refactor widget IO functions in preparation for platform widgets.
by Liam Girdwood 14 Jun '11

14 Jun '11

This time with soc_widget_update_bits reflecting recent soc_update_bits changes. Currently widget IO is tightly coupled to the CODEC drivers. Future platform DSP devices have mixer components that can alter power usage and hence require full DAPM support. This provides a generic widget IO operation wrapper in preparation for future patches that implement platform driver DAPM. Signed-off-by: Liam Girdwood <lrg(a)ti.com> --- sound/soc/soc-dapm.c | 49 +++++++++++++++++++++++++++++++++++++++++++------ 1 files changed, 43 insertions(+), 6 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 34106bc..2e6c351 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -124,6 +124,43 @@ static inline struct snd_soc_dapm_widget *dapm_cnew_widget( return kmemdup(_widget, sizeof(*_widget), GFP_KERNEL); } +static int soc_widget_read(struct snd_soc_dapm_widget *w, int reg) +{ + if (w->codec) + return snd_soc_read(w->codec, reg); + return 0; +} + +static int soc_widget_write(struct snd_soc_dapm_widget *w, int reg, int val) +{ + if (w->codec) + return snd_soc_write(w->codec, reg, val); + return 0; +} + +static int soc_widget_update_bits(struct snd_soc_dapm_widget *w, + unsigned short reg, unsigned int mask, unsigned int value) +{ + int change; + unsigned int old, new; + int ret; + + ret = soc_widget_read(w, reg); + if (ret < 0) + return ret; + + old = ret; + new = (old & ~mask) | (value & mask); + change = old != new; + if (change) { + ret = soc_widget_write(w, reg, new); + if (ret < 0) + return ret; + } + + return change; +} + /** * snd_soc_dapm_set_bias_level - set the bias level for the system * @dapm: DAPM context @@ -181,7 +218,7 @@ static void dapm_set_path_status(struct snd_soc_dapm_widget *w, unsigned int mask = (1 << fls(max)) - 1; unsigned int invert = mc->invert; - val = snd_soc_read(w->codec, reg); + val = soc_widget_read(w, reg); val = (val >> shift) & mask; if ((invert && !val) || (!invert && val)) @@ -197,7 +234,7 @@ static void dapm_set_path_status(struct snd_soc_dapm_widget *w, for (bitmask = 1; bitmask < e->max; bitmask <<= 1) ; - val = snd_soc_read(w->codec, e->reg); + val = soc_widget_read(w, e->reg); item = (val >> e->shift_l) & (bitmask - 1); p->connect = 0; @@ -227,7 +264,7 @@ static void dapm_set_path_status(struct snd_soc_dapm_widget *w, w->kcontrol_news[i].private_value; int val, item; - val = snd_soc_read(w->codec, e->reg); + val = soc_widget_read(w, e->reg); val = (val >> e->shift_l) & e->mask; for (item = 0; item < e->max; item++) { if (val == e->values[item]) @@ -669,7 +706,7 @@ int dapm_reg_event(struct snd_soc_dapm_widget *w, else val = w->off_val; - snd_soc_update_bits(w->codec, -(w->reg + 1), + soc_widget_update_bits(w, -(w->reg + 1), w->mask << w->shift, val << w->shift); return 0; @@ -877,7 +914,7 @@ static void dapm_seq_run_coalesced(struct snd_soc_dapm_context *dapm, "pop test : Applying 0x%x/0x%x to %x in %dms\n", value, mask, reg, card->pop_time); pop_wait(card->pop_time); - snd_soc_update_bits(dapm->codec, reg, mask, value); + soc_widget_update_bits(w, reg, mask, value); } list_for_each_entry(w, pending, power_list) { @@ -1878,7 +1915,7 @@ int snd_soc_dapm_new_widgets(struct snd_soc_dapm_context *dapm) /* Read the initial power state from the device */ if (w->reg >= 0) { - val = snd_soc_read(w->codec, w->reg); + val = soc_widget_read(w, w->reg); val &= 1 << w->shift; if (w->invert) val = !val; -- 1.7.4.1

2 1

[alsa-devel] Subject= @Daniel Mack: Send you a FTU
by Aurélien Leblond 14 Jun '11

14 Jun '11

>> I saw on the mailing that you a Felix have been doing a great deal of >> work to provide better support for the M-Audio FastTrack Ultra. >> I tested yesterday the new patch that provides mixer and the >> possibility to change the internal routing of the soundcard... I can >> finally use all the input/output to use external FX, that's very >> handy! >> >> Anyway, on the M-Audio forum, Felix has been mentionning several times >> that there were few bugs that needed to be fixed with this soundcard, >> but that you needed to get your hand on one device to fix them (and >> may be even improve things around its support in general). > >Quite frankly, I'm not fully aware about known issues with these >devices that need attention. Could you summarize which problems are >left to look at? There are still the issue of samples dropping. Tto reproduce it: - Open Audacity and set it up to be using Jack. - Click Generate -> Tone -> Ok. "Normally" you should hear very regular pops...

3 2

Re: [alsa-devel] [PATCH] hdspm.c: make driver name generic to avoid user confusion
by Adrian Knoth 14 Jun '11

14 Jun '11

On Tue, Jun 07, 2011 at 10:44:18AM +0200, Jörn Nettingsmeier wrote: > hi adi, *! Hi! > here's a trivial patch to change the driver name of hdspm.c to avoid > irritating users who don't have the MADI version (just happened on the > LAU list). > static struct pci_driver driver = { > - .name = "RME Hammerfall DSP MADI", > + .name = "RME Hammerfall HDSPe Series", Are braces allowed in driver names? I guess so. "HDSPe" is also confusing, only referring to the PCIe versions. Since we also support the old PCI versions, I suggest to name it "RME Hammerfall HDSP(e) Series" On the other hand, the 'H' in "HDSP" stands for "Hammerfall", so "RME HDSP(e) Series" would be more appropriate. Luckily, we don't collide with the hdsp.c driver name, but still, it's misleading, because there are cards that match "RME HDSP(e) Series" (like the Multiface/Digiface) but are handled by hdsp.c instead. What at mess. ;) Merging hdsp.c into hdspm.c would be the clean approach to this problem, still I don't have time for this in the near future. Maybe in July. Given that all current variants are misleading in one way or another, we could also leave everything as is. What do you think? Cheers -- mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver

3 4

[alsa-devel] [PATCH] Sound, 6Fire USB: Fix double-free bug in usb6fire_fw_ezusb_upload()
by Jesper Juhl 14 Jun '11

14 Jun '11

We have a double-free bug in sound/usb/6fire/firmware.c::usb6fire_fw_ezusb_upload(). We already call release_firmware(fw) on line 258, so when we then do it again after usb6fire_fw_ezusb_write() returns <0, we have a double-free. Easily fixed by just removing the last call to release_firmware(). Signed-off-by: Jesper Juhl <jj(a)chaosbits.net> --- firmware.c | 1 - 1 file changed, 1 deletion(-) Patch against Linus' tree (head at 40779859de0f73b40390c6401a024d06cf024290). diff --git a/sound/usb/6fire/firmware.c b/sound/usb/6fire/firmware.c index a91719d..1e3ae33 100644 --- a/sound/usb/6fire/firmware.c +++ b/sound/usb/6fire/firmware.c @@ -270,7 +270,6 @@ static int usb6fire_fw_ezusb_upload( data = 0x00; /* resume ezusb cpu */ ret = usb6fire_fw_ezusb_write(device, 0xa0, 0xe600, &data, 1); if (ret < 0) { - release_firmware(fw); snd_printk(KERN_ERR PREFIX "unable to upload ezusb " "firmware %s: end message.\n", fwname); return ret; -- Jesper Juhl <jj(a)chaosbits.net> http://www.chaosbits.net/ Don't top-post http://www.catb.org/jargon/html/T/top-post.html Plain text mails only, please.

2 1