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

[alsa-devel] [PATCH] ASoC: cs42l52: Remove unneeded version.h include
by Jesper Juhl 11 Jun '12

11 Jun '12

Signed-off-by: Jesper Juhl <jj(a)chaosbits.net> --- sound/soc/codecs/cs42l52.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/codecs/cs42l52.c b/sound/soc/codecs/cs42l52.c index a710941..ec03abc 100644 --- a/sound/soc/codecs/cs42l52.c +++ b/sound/soc/codecs/cs42l52.c @@ -14,7 +14,6 @@ #include <linux/module.h> #include <linux/moduleparam.h> -#include <linux/version.h> #include <linux/kernel.h> #include <linux/init.h> #include <linux/delay.h> -- 1.7.10.4 -- 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

[PATCH] USB: fix gathering of interface associations
by Daniel Mack 10 Jun '12

10 Jun '12

TEAC's UD-H01 (and probably other devices) have a gap in the interface number allocation in their descriptors: Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 220 bNumInterfaces 3 [...] Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 [...] Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 2 bInterfaceCount 2 bFunctionClass 1 Audio bFunctionSubClass 0 bFunctionProtocol 32 iFunction 4 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 [...] Once a configuration is selected on this device, usb_set_configuration() walks the known interfaces of a given configuration and calls find_iad() on each of them to set the interface association pointer the interface is included in. The problem here is that the loop varibale index is taken for the interface number in the comparison logic that gathers the association. Which is fine as long as the descriptors are sane. In the case above, however, the logic gets out of sync and the interface association fields of all interfaces beyond the interface number gap are wrong. Fix this by passing the interface's bInterfaceNumber to find_iad() instead. Signed-off-by: Daniel Mack <zonque(a)gmail.com> Reported-by: bEN <ml_all(a)circa.be> Reported-by: Ivan Perrone <ivanperrone(a)hotmail.com> Tested-by: Sergio Tabanelli <sergio.tabanelli(a)gmail.com> Cc: <stable(a)kernel.org> --- drivers/usb/core/message.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c index b548cf1..bdd1c67 100644 --- a/drivers/usb/core/message.c +++ b/drivers/usb/core/message.c @@ -1838,7 +1838,6 @@ free_interfaces: intfc = cp->intf_cache[i]; intf->altsetting = intfc->altsetting; intf->num_altsetting = intfc->num_altsetting; - intf->intf_assoc = find_iad(dev, cp, i); kref_get(&intfc->ref); alt = usb_altnum_to_altsetting(intf, 0); @@ -1851,6 +1850,8 @@ free_interfaces: if (!alt) alt = &intf->altsetting[0]; + intf->intf_assoc = + find_iad(dev, cp, alt->desc.bInterfaceNumber); intf->cur_altsetting = alt; usb_enable_interface(dev, intf, true); intf->dev.parent = &dev->dev; -- 1.7.10.2 --------------050305000101090703040603--

1 0

[alsa-devel] Possible option for driver development for Creamware/Sonic Core soon
by Dan Swain 10 Jun '12

10 Jun '12

Dear all, I've recently acquired one of the less-recent Creamware Luna cards. After reading on Nabble that someone expressed an interest in ALSA drivers for these cards two years ago (and hearing from Paul Davis that he'd been unsuccessful in gaining enthusiasm from Creamware), I decided to get in touch with the community that supports these cards on forums.planetz.com It appears that in 2006, Sonic Core bought Creamware, and began developing their own framework to program the DSPs on the original cards, plus some new creations by them. This platform is known as Scope, and the most current version is 5.1, which is compatible with Windows 32 and 64-bit operating systems. However, they (Sonic Core) are working on Scope 6.0, which is intended to be a cross-platform system. From what I've been reading, they are using the JUCE framework as the basis of their development for this version, so they can target (primarily) Windows AND Mac OSX systems. Some interest has been noted for a Linux version too, after I started this thread: http://forums.planetz.com/viewtopic.php?f=5&t=31065 _From what I'm aware, the Sonic Core developers drop in to that forum now and again, so it may be possible to get informed responses. The plug-in base for these cards is quite extensive, even with the free ones developed by community members, particularly synthesisers, so it would make a wonderful addition to the Linux audio world I'm new to Sonic Core as well, and unfortunately I'm not a programmer, though I wouldn't be averse to trying to help in any way I can. My understanding here is that all that needs to be developed is a driver that connects to Sonic Core's framework. Thanks for taking the time to read, and I hope this sparks some interest with the ALSA community! Kind Regards, Dan -- Dan Swain <sp4md4n(a)gmail.com>

1 0

Re: [alsa-devel] Help requested: new HSS1394 MIDI back-end
by Jonathan Woithe 09 Jun '12

09 Jun '12

Clemens Ladisch wrote: > Sean M. Pappalardo - D.J. Pegasus wrote: > > As soon as I start the JACK server to handle the audio interface on > > the SCS.1m, the ALSA driver stops sending MIDI for that device unless > > I stop JACK and power-cycle the device. Its last words are: > > F0 00 01 60 48 53 53 0F 03 00 03 00 00 0B 01 F7 > > This is a ping response (tag F3). Apparently, Jack's FFADO driver > reinitializes the device and registers its own address for received > packets. Since it does _not_ handle MIDI messages, it really should > not do this. If we're talking about the ARM handler for HSS1394 messages, then I suspect the reason it sets this up is that Pieter initially fully intended for FFADO to pass these messages back. Obviously if this were to be done then an ARM handler would be necessary, but that's not how things are panning out. To prevent the ARM handler being registered by FFADO it should only be ncessary to comment out the initMessageHandler() call in the ScsDevice::discover() method. I'm happy to make this change since it seems to make sense to do so given these latest developments. A preliminary approach is in FFADO svn revision 2163 if you want to check it out. Note that this will break FFADO's test-scs program - a detail I'll tidy up if the overall approach seems to work. The other related issue is whether the other device setup done by FFADO interferes with the MIDI stream transmission. I guess that's most easily tested by trying FFADO rev 2163 and seeing if there are other issues remaining. Regards jonathan

1 0

Re: [alsa-devel] [PATCH 0/2] HD-audio HDMI regression fixes with VGA-switcheroo
by Takashi Iwai 09 Jun '12

09 Jun '12

At Fri, 08 Jun 2012 22:17:29 +0200, Jörg-Volker Peetz wrote: > > Takashi Iwai wrote, on 06/08/12 17:52: > > At Fri, 08 Jun 2012 17:45:17 +0200, > > Jörg-Volker Peetz wrote: > >> > >> Hello Takashi, > >> > >> Takashi Iwai wrote, on 06/08/12 15:03: > >>> At Fri, 08 Jun 2012 13:26:57 +0200, > >>> Jörg-Volker Peetz wrote: > >>>> > >>>> Takashi Iwai wrote, on 06/07/12 12:15: > >>>>> Hi, > >>>>> > >>>>> this is a series of patches to fix the regressions of HD-audio HDMI > >>>>> on D-GPUs in 3.5-rc1 due to the support of VGA-switcheroo audio clients. > >>>>> > >>>>> The first patch adds a new helper function to vga-switcheroo and the > >>>>> second just uses that instead of an open code. > >>>>> > >>>>> Dave, if the first patch is OK, I'm going to apply it though sound tree. > >>>>> Let me know if any problem is found. > >>>>> > >>>>> Joerg, could you check whether this doesn't break your setup, too? > >>>>> > >>>>> > >>>>> thanks, > >>>>> > >>>>> Takashi > >>>> > >>>> Hello Takashi, > >>>> > >>>> I applied both your patches on 3.5-rc1. With this kernel I made three tests. > >>>> 1) After booting I switched off the discrete GPU via vga_switcheroo. > >>>> Then ca. 210 times the message > >>>> > >>>> hda-intel: spurious response 0x0:0x0, last cmd=0x170503 > >>>> > >>>> appears on the console and in the logs. > >>>> Starting X and using the built-in USB web-cam work, as well as sound with > >>>> mplayer2 works. > >>>> > >>>> 2) After booting I switched to the discrete GPU via > >>>> > >>>> echo -n DDIS > /sys/kernel/debugfs/vgaswitcheroo/switch > >>>> > >>>> Then I started X via startx. The desktop screen appears but the system > >>>> freezes. No reaction on keyboard or touchpad input. The computer is not > >>>> reachable via ethernet wire. > >>> > >>> Hm, these issues aren't seen on 3.5-rc1 before my patches? > >>> If so, we need to fix now. > >>> > >> No, these issues aren't seen on 3.5-rc1 without your patches. I'm able to start > >> X with the discrete GPU in use, direct rendering and the built-in USB camera work. > > > > OK, it means that the switching from the audio-ON to audio-OFF doesn't > > work. Could you try the patch below in additon? > > > > Applying all your three patches on 3.5-rc1 makes the discrete GPU work on my > system: after mounting debugfs and switching to "DDIS", I can start X and direct > rendering, sound and built-in USB camera work. Good to hear. Dave, is it OK to apply the patch below through sound tree? thanks, Takashi --- From: Takashi Iwai <tiwai(a)suse.de> Subject: [PATCH] vga_switcheroo: Enable/disable audio clients at the right time The audio clients have to be disabled before disabling the VGA and switching. Similarly, enabling the audio client should be done at last. Otherwise the audio-side operation stalls, eventually leading to Oops or lockups. Tested-by: Jörg-Volker Peetz <jvpeetz(a)web.de> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- drivers/gpu/vga/vga_switcheroo.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c index 38f9534..e24ad99 100644 --- a/drivers/gpu/vga/vga_switcheroo.c +++ b/drivers/gpu/vga/vga_switcheroo.c @@ -291,8 +291,6 @@ static int vga_switchto_stage1(struct vga_switcheroo_client *new_client) vga_switchon(new_client); vga_set_default_device(new_client->pdev); - set_audio_state(new_client->id, VGA_SWITCHEROO_ON); - return 0; } @@ -308,6 +306,8 @@ static int vga_switchto_stage2(struct vga_switcheroo_client *new_client) active->active = false; + set_audio_state(active->id, VGA_SWITCHEROO_OFF); + if (new_client->fb_info) { struct fb_event event; event.info = new_client->fb_info; @@ -321,11 +321,11 @@ static int vga_switchto_stage2(struct vga_switcheroo_client *new_client) if (new_client->ops->reprobe) new_client->ops->reprobe(new_client->pdev); - set_audio_state(active->id, VGA_SWITCHEROO_OFF); - if (active->pwr_state == VGA_SWITCHEROO_ON) vga_switchoff(active); + set_audio_state(new_client->id, VGA_SWITCHEROO_ON); + new_client->active = true; return 0; } @@ -371,8 +371,9 @@ vga_switcheroo_debugfs_write(struct file *filp, const char __user *ubuf, /* pwr off the device not in use */ if (strncmp(usercmd, "OFF", 3) == 0) { list_for_each_entry(client, &vgasr_priv.clients, list) { - if (client->active) + if (client->active || client_is_audio(client)) continue; + set_audio_state(client->id, VGA_SWITCHEROO_OFF); if (client->pwr_state == VGA_SWITCHEROO_ON) vga_switchoff(client); } @@ -381,10 +382,11 @@ vga_switcheroo_debugfs_write(struct file *filp, const char __user *ubuf, /* pwr on the device not in use */ if (strncmp(usercmd, "ON", 2) == 0) { list_for_each_entry(client, &vgasr_priv.clients, list) { - if (client->active) + if (client->active || client_is_audio(client)) continue; if (client->pwr_state == VGA_SWITCHEROO_OFF) vga_switchon(client); + set_audio_state(client->id, VGA_SWITCHEROO_ON); } goto out; } -- 1.7.10.4

2 2

Re: [alsa-devel] [Bisected] ALSA: snd-usb: New streaming logic causes distortions on Burr-Brown DAC
by Takashi Iwai 09 Jun '12

09 Jun '12

At Fri, 8 Jun 2012 20:11:54 +0200, Markus Trippelsdorf wrote: > > On 2012.06.08 at 17:50 +0000, Jamie Heilman wrote: > > Markus Trippelsdorf wrote: > > > I hear distortions on my Burr-Brown USB DAC whenever the (software) > > > volume is set to some value lower than 100% in mpd. The lower the volume > > > the bigger are the resulting distortions. > > > > see patch: http://marc.info/?l=linux-kernel&m=133905533312625&w=2 > > > > You're probably getting distortion because mpd decided it would use > > a stream format that's only 8bit. > > Yes. The patch fixes the issue. Many thanks. The patch is already in sound git tree, but missed in rc2. It should be in rc3. thanks, Takashi

1 0

[alsa-devel] [PATCH] ASoC: wm8903: disable mic detect irqs until jack registered
by Stephen Warren 09 Jun '12

09 Jun '12

From: Stephen Warren <swarren(a)nvidia.com> If either mic detection interrupt is unmasked when the IRQ handler is first registered, they might fire immediately. However, at this point, wm8903->mic_jack cannot have been set, since wm8903_mic_detect() can only operate after wm8903_probe() has completed. If the IRQ fires at this point, wm8903_irq() will use the uninitialized or stale mic_jack, and crash. This problem can be triggered by fully initializing an audio card, then removing and re-inserting the machine driver module. This would leave mic detection enabled in HW, and mic_jack set to a stale value. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- This is useful in 3.5. As an aside, I wondered instead about modifying wm8903_remove() to disable mic detection, and clear any status. However, even if we do that, I think we still want to make this change too, since I think we want probe() to work the first time without relying on previous HW state? sound/soc/codecs/wm8903.c | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/wm8903.c b/sound/soc/codecs/wm8903.c index 304b5cf..d00a2b3 100644 --- a/sound/soc/codecs/wm8903.c +++ b/sound/soc/codecs/wm8903.c @@ -1946,7 +1946,16 @@ static int wm8903_probe(struct snd_soc_codec *codec) snd_soc_update_bits(codec, WM8903_INTERRUPT_CONTROL, WM8903_IRQ_POL, irq_pol); - + + /* + * Ensure mic detection interrupts are masked until after + * wm8903_mic_detect() is called, so that wm8903_irq() has + * a valid wm8903->mic_jack() to report on. + */ + snd_soc_update_bits(codec, WM8903_INTERRUPT_STATUS_1_MASK, + WM8903_MICDET_EINT | WM8903_MICSHRT_EINT, + WM8903_MICDET_EINT | WM8903_MICSHRT_EINT); + ret = request_threaded_irq(wm8903->irq, NULL, wm8903_irq, trigger | IRQF_ONESHOT, "wm8903", codec); -- 1.7.0.4

2 2

[alsa-devel] [PATCH 1/2] ASoC: wm8904: Convert to module_i2c_driver()
by Mark Brown 09 Jun '12

09 Jun '12

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8904.c | 18 +----------------- 1 file changed, 1 insertion(+), 17 deletions(-) diff --git a/sound/soc/codecs/wm8904.c b/sound/soc/codecs/wm8904.c index db94d10..02bc2ca 100644 --- a/sound/soc/codecs/wm8904.c +++ b/sound/soc/codecs/wm8904.c @@ -2313,23 +2313,7 @@ static struct i2c_driver wm8904_i2c_driver = { .id_table = wm8904_i2c_id, }; -static int __init wm8904_modinit(void) -{ - int ret = 0; - ret = i2c_add_driver(&wm8904_i2c_driver); - if (ret != 0) { - printk(KERN_ERR "Failed to register wm8904 I2C driver: %d\n", - ret); - } - return ret; -} -module_init(wm8904_modinit); - -static void __exit wm8904_exit(void) -{ - i2c_del_driver(&wm8904_i2c_driver); -} -module_exit(wm8904_exit); +module_i2c_driver(wm8904_i2c_driver); MODULE_DESCRIPTION("ASoC WM8904 driver"); MODULE_AUTHOR("Mark Brown <broonie(a)opensource.wolfsonmicro.com>"); -- 1.7.10

1 1

Re: [alsa-devel] [PATCH 0/2] HD-audio HDMI regression fixes with VGA-switcheroo
by Takashi Iwai 08 Jun '12

08 Jun '12

At Fri, 08 Jun 2012 17:45:17 +0200, Jörg-Volker Peetz wrote: > > Hello Takashi, > > Takashi Iwai wrote, on 06/08/12 15:03: > > At Fri, 08 Jun 2012 13:26:57 +0200, > > Jörg-Volker Peetz wrote: > >> > >> Takashi Iwai wrote, on 06/07/12 12:15: > >>> Hi, > >>> > >>> this is a series of patches to fix the regressions of HD-audio HDMI > >>> on D-GPUs in 3.5-rc1 due to the support of VGA-switcheroo audio clients. > >>> > >>> The first patch adds a new helper function to vga-switcheroo and the > >>> second just uses that instead of an open code. > >>> > >>> Dave, if the first patch is OK, I'm going to apply it though sound tree. > >>> Let me know if any problem is found. > >>> > >>> Joerg, could you check whether this doesn't break your setup, too? > >>> > >>> > >>> thanks, > >>> > >>> Takashi > >> > >> Hello Takashi, > >> > >> I applied both your patches on 3.5-rc1. With this kernel I made three tests. > >> 1) After booting I switched off the discrete GPU via vga_switcheroo. > >> Then ca. 210 times the message > >> > >> hda-intel: spurious response 0x0:0x0, last cmd=0x170503 > >> > >> appears on the console and in the logs. > >> Starting X and using the built-in USB web-cam work, as well as sound with > >> mplayer2 works. > >> > >> 2) After booting I switched to the discrete GPU via > >> > >> echo -n DDIS > /sys/kernel/debugfs/vgaswitcheroo/switch > >> > >> Then I started X via startx. The desktop screen appears but the system > >> freezes. No reaction on keyboard or touchpad input. The computer is not > >> reachable via ethernet wire. > > > > Hm, these issues aren't seen on 3.5-rc1 before my patches? > > If so, we need to fix now. > > > No, these issues aren't seen on 3.5-rc1 without your patches. I'm able to start > X with the discrete GPU in use, direct rendering and the built-in USB camera work. OK, it means that the switching from the audio-ON to audio-OFF doesn't work. Could you try the patch below in additon? > Probably unrelated: in both cases I'm unable to lower the screen brightness from > highest value. Without your patches it appears a warning: > > ACPI Warning: _BQC returned an invalid level (20120320/video-472) Hmm, I see no relation between this and the HDMI audio part. It's of course possible that some non-working state gives side-effects... thanks, Takashi --- diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c index eb4f64f..5b3c7d1 100644 --- a/drivers/gpu/vga/vga_switcheroo.c +++ b/drivers/gpu/vga/vga_switcheroo.c @@ -304,8 +304,6 @@ static int vga_switchto_stage1(struct vga_switcheroo_client *new_client) vga_switchon(new_client); vga_set_default_device(new_client->pdev); - set_audio_state(new_client->id, VGA_SWITCHEROO_ON); - return 0; } @@ -321,6 +319,8 @@ static int vga_switchto_stage2(struct vga_switcheroo_client *new_client) active->active = false; + set_audio_state(active->id, VGA_SWITCHEROO_OFF); + if (new_client->fb_info) { struct fb_event event; event.info = new_client->fb_info; @@ -334,11 +334,11 @@ static int vga_switchto_stage2(struct vga_switcheroo_client *new_client) if (new_client->ops->reprobe) new_client->ops->reprobe(new_client->pdev); - set_audio_state(active->id, VGA_SWITCHEROO_OFF); - if (active->pwr_state == VGA_SWITCHEROO_ON) vga_switchoff(active); + set_audio_state(new_client->id, VGA_SWITCHEROO_ON); + new_client->active = true; return 0; } @@ -384,8 +384,9 @@ vga_switcheroo_debugfs_write(struct file *filp, const char __user *ubuf, /* pwr off the device not in use */ if (strncmp(usercmd, "OFF", 3) == 0) { list_for_each_entry(client, &vgasr_priv.clients, list) { - if (client->active) + if (client->active || client_is_audio(client)) continue; + set_audio_state(client->id, VGA_SWITCHEROO_OFF); if (client->pwr_state == VGA_SWITCHEROO_ON) vga_switchoff(client); } @@ -394,10 +395,11 @@ vga_switcheroo_debugfs_write(struct file *filp, const char __user *ubuf, /* pwr on the device not in use */ if (strncmp(usercmd, "ON", 2) == 0) { list_for_each_entry(client, &vgasr_priv.clients, list) { - if (client->active) + if (client->active || client_is_audio(client)) continue; if (client->pwr_state == VGA_SWITCHEROO_OFF) vga_switchon(client); + set_audio_state(client->id, VGA_SWITCHEROO_ON); } goto out; }

1 0

Re: [alsa-devel] [PATCH v1 3/5] ASOC: mmp: add sspa support
by Mark Brown 08 Jun '12

08 Jun '12

On Mon, Jun 04, 2012 at 02:37:29PM +0800, Zhangfei Gao wrote: > The SSPA is a configurable multi-channel audio serial (TDM) interface. > It's configurable at runtime to support up to 128 channels and the > number of bits per sample: 8, 12, 16, 20, 24 and 32 bits. It also > support stereo format: I2S, left-justified or right-justified. This looks mostly good (though you want to check your indentation a bit) but... > +static int __init mmp_sspa_modinit(void) > +{ > + audio_clk = clk_get(NULL, "mmp-audio"); > + if (IS_ERR(audio_clk)) > + return PTR_ERR(audio_clk); > + > + sysclk = clk_get(NULL, "mmp-sysclk"); > + if (IS_ERR(sysclk)) > + return PTR_ERR(sysclk); > + clk_enable(audio_clk); You should be doing this stuff from the driver, not from the module init (and ideally you'd be managing the audio clock dynamically). Even if it's the same clock every time in current silicon it's still a good idea to do this from a quality of implementation point of view.

2 1