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

Re: [alsa-devel] [pulseaudio-discuss] Documentation for how rewinding works
by Raymond Yau 27 Aug '12

27 Aug '12

2012-8-19 下午7:17 於 "Tanu Kaskinen" <tanuk(a)iki.fi> 寫道： > > Hi, > > While reviewing a rewind related patch, I noticed that I don't > understand the rewinding code thoroughly, even though I have studied it > a few times in the past. I decided that I should write a wiki page for > the code so that working with it would be easier in the future for me > and everybody else. > > So, here's the result: > http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer… > > While doing that, I found quite a few bugs, which are noted on that > page. I don't plan fixing them any time soon (help with that would be > very welcome), so I will just file bugs about the issues so that they > are not forgotten. > it seem that the alsa sink is more complicated than your figure. Refer to figure 14 HD Audio DMA and buffering , section 4.6 Energy Efficient HA audio mechanism most sound cards have fixed size FIFO buffer instead of dynamic FIFO and minimum transfer size(brust) similar to hda controller which snd_pcm_rewind cannot rewind any audio data in those first in first out buffer. http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/alsa?i… 1) do the server really need to rewind when there is only one pulse client ? 2) does pulseaudio add this rewind safeguard delay to the latency ?

2 3

[alsa-devel] REGRESSION: Webcam mic for 145f:015b not longer working with 1.0.24 and above (OK with 1.0.23)
by Kostas 27 Aug '12

27 Aug '12

Hi All, I have a 'Trust Webcam' (USB ID: 145f:015b) that comes with a microphone. The microphone works with Alsa 1.0.23 but it does not work with the latest Alsa 1.0.25 neither with Alsa 1.0.24. Apparently this is a regression. What shall I do to figure out the source of the problem? Here are attached my alsa-infos, with Alsa 1.0.23 (working), 1.0.24 (NOT working) and 1.0.25 (NOT working). Thanks! 1.0.23 http://www.alsa-project.org/db/?f=a4e2c86d93ff67c5d6acd4933c76f47a60cf51ee 1.0.24 http://www.alsa-project.org/db/?f=9aa13f70ec169011b9dfc5625370ce3e6f7827a1 1.0.25 http://www.alsa-project.org/db/?f=c3f63b69655b379e3eec54ab00e63b186a677422

2 1

[alsa-devel] Driver for HT|OMEGA eCLARO (C-Media 8788 ***PCIe***)
by Aaron Fulkerson 27 Aug '12

27 Aug '12

Hello and nice to meet you all. This will be my first post if the previous one did not work. The problem is this: there is not a working driver for the HT|OMEGA eCLARO. The card is based on the C-Media 8788 chip for which there is an existing driver, however, due to the fact that the eCLARO is a PCIe-based card, the driver doesn't function properly. What are the chances of a working driver being written for this card?

1 0

[alsa-devel] [PATCH v2 0/4] ASoC: omap-mcbsp: Sidetone related changes
by Peter Ujfalusi 25 Aug '12

25 Aug '12

Hello, Changes since v1: - Macro for the ST control has been fixed - New patch to combine the st channel volume set/get macros Mark: this series depends on the McBSP DT support (to be precise patch 3 and 4 has dependency). Intro mail from v1: When we boot with DT blob the sidetone is not supported at the moment. Prepare the McBSP code for the time when we are going to be able to support ST with DT booted kernel. Meanwhile do not block the audio card if the st_data is missing from the port, but print a warning about it. This will allow us to debug the DT booted kernels with audio. Regards, Peter --- Peter Ujfalusi (4): ASoC: omap-mcbsp: Check mcbsp->id instead of cpu_dai->id when adding ST controls ASoC: omap-mcbsp: Only print warning if the st_data is missing for the port ASoC: omap-mcbsp: Use macro to create the McBSP2/3 ST controls ASoC: omap-mcbsp: Single macro for st channel volume set/get sound/soc/omap/omap-mcbsp.c | 64 ++++++++++++++++++------------------------- 1 files changed, 27 insertions(+), 37 deletions(-) -- 1.7.8.6

3 8

[alsa-devel] [PATCH] ASoC: wm0010: Move resource acquisition to device probe
by Mark Brown 25 Aug '12

25 Aug '12

This is more idimatic for modern drivers. Also fix a couple of return codes while we're at it. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm0010.c | 54 ++++++++++++++++++++++----------------------- 1 file changed, 27 insertions(+), 27 deletions(-) diff --git a/sound/soc/codecs/wm0010.c b/sound/soc/codecs/wm0010.c index 30ec0bd..5f99148 100644 --- a/sound/soc/codecs/wm0010.c +++ b/sound/soc/codecs/wm0010.c @@ -799,14 +799,35 @@ static irqreturn_t wm0010_irq(int irq, void *data) static int wm0010_probe(struct snd_soc_codec *codec) { struct wm0010_priv *wm0010 = snd_soc_codec_get_drvdata(codec); - struct spi_device *spi = to_spi_device(wm0010->dev); + + wm0010->codec = codec; + + return 0; +} + +static int __devinit wm0010_spi_probe(struct spi_device *spi) +{ unsigned long flags; unsigned long gpio_flags; int ret; int trigger; int irq; + struct wm0010_priv *wm0010; - wm0010->codec = codec; + wm0010 = devm_kzalloc(&spi->dev, sizeof(*wm0010), + GFP_KERNEL); + if (!wm0010) + return -ENOMEM; + + mutex_init(&wm0010->lock); + spin_lock_init(&wm0010->irq_lock); + + spi_set_drvdata(spi, wm0010); + wm0010->dev = &spi->dev; + + if (dev_get_platdata(&spi->dev)) + memcpy(&wm0010->pdata, dev_get_platdata(&spi->dev), + sizeof(wm0010->pdata)); init_completion(&wm0010->boot_completion); @@ -850,7 +871,7 @@ static int wm0010_probe(struct snd_soc_codec *codec) } } else { dev_err(wm0010->dev, "No reset GPIO configured\n"); - return ret; + return -EINVAL; } irq = spi->irq; @@ -862,9 +883,11 @@ static int wm0010_probe(struct snd_soc_codec *codec) ret = request_threaded_irq(irq, NULL, wm0010_irq, trigger, "wm0010", wm0010); - if (ret) + if (ret) { dev_err(wm0010->dev, "Failed to request IRQ %d: %d\n", irq, ret); + return ret; + } wm0010->irq = irq; if (spi->max_speed_hz) @@ -876,29 +899,6 @@ static int wm0010_probe(struct snd_soc_codec *codec) wm0010->state = WM0010_POWER_OFF; spin_unlock_irqrestore(&wm0010->irq_lock, flags); - return 0; -} - -static int __devinit wm0010_spi_probe(struct spi_device *spi) -{ - struct wm0010_priv *wm0010; - int ret; - - wm0010 = devm_kzalloc(&spi->dev, sizeof(*wm0010), - GFP_KERNEL); - if (!wm0010) - return -ENOMEM; - - mutex_init(&wm0010->lock); - spin_lock_init(&wm0010->irq_lock); - - spi_set_drvdata(spi, wm0010); - wm0010->dev = &spi->dev; - - if (dev_get_platdata(&spi->dev)) - memcpy(&wm0010->pdata, dev_get_platdata(&spi->dev), - sizeof(wm0010->pdata)); - ret = snd_soc_register_codec(&spi->dev, &soc_codec_dev_wm0010, wm0010_dai, ARRAY_SIZE(wm0010_dai)); -- 1.7.10.4

1 0

[alsa-devel] [PATCH] ASoC: wm0010: Add dummy widget for CLKIN
by Mark Brown 25 Aug '12

25 Aug '12

Make it easier to integrate the management of the clock supplying the WM0010 with DAPM by providing a dummy supply widget which supplies the interface widgets, this can be connected to clock outputs by the machines. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm0010.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/sound/soc/codecs/wm0010.c b/sound/soc/codecs/wm0010.c index f820b57..b6f7097 100644 --- a/sound/soc/codecs/wm0010.c +++ b/sound/soc/codecs/wm0010.c @@ -118,9 +118,18 @@ struct wm0010_spi_msg { size_t len; }; +static const struct snd_soc_dapm_widget wm0010_dapm_widgets[] = { +SND_SOC_DAPM_SUPPLY("CLKIN", SND_SOC_NOPM, 0, 0, NULL, 0), +}; + static const struct snd_soc_dapm_route wm0010_dapm_routes[] = { { "SDI2 Capture", NULL, "SDI1 Playback" }, { "SDI1 Capture", NULL, "SDI2 Playback" }, + + { "SDI1 Capture", NULL, "CLKIN" }, + { "SDI2 Capture", NULL, "CLKIN" }, + { "SDI1 Playback", NULL, "CLKIN" }, + { "SDI2 Playback", NULL, "CLKIN" }, }; static const char *wm0010_state_to_str(enum wm0010_state state) @@ -718,6 +727,8 @@ static struct snd_soc_codec_driver soc_codec_dev_wm0010 = { .set_bias_level = wm0010_set_bias_level, .set_sysclk = wm0010_set_sysclk, + .dapm_widgets = wm0010_dapm_widgets, + .num_dapm_widgets = ARRAY_SIZE(wm0010_dapm_widgets), .dapm_routes = wm0010_dapm_routes, .num_dapm_routes = ARRAY_SIZE(wm0010_dapm_routes), }; -- 1.7.10.4

1 0

Re: [alsa-devel] Logitech USB headset not working in 3.6-rc3
by Takashi Iwai 25 Aug '12

25 Aug '12

At Sat, 25 Aug 2012 08:17:58 -0400, Josh Boyer wrote: > > On Sat, Aug 25, 2012 at 02:13:58PM +0200, Daniel Mack wrote: > > On 25.08.2012 14:07, Bruno Wolff III wrote: > > > On Sat, Aug 25, 2012 at 14:02:51 +0200, > > > Daniel Mack <zonque(a)gmail.com> wrote: > > >> > > >> Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix > > >> scheduling-while-atomic bug in PCM capture stream") and see if that > > > > > > I can try that, but it takes a long time to build a new kernel on my > > > old hardware. > > > > > >> helps? If not, can you summarize again which kernels still work for you > > >> and which don't? > > > > > > The latest kernel that works is 3.6.0-0.rc2.git1.2.fc18. The earliest that > > > doesn't work is 3.6.0-0.rc2.git2.1.fc18. > > > > > > > The report you sent doesn't look like it could be caused by e9ba389c5. > > It fixes a kernel Ooops. But as it is the only relevant patch in that > > area, it would be interesting if reverting it fixes anything. > > Yep, agreed. If this revert kernel doesn't work, we're likely down to a > git bisect, Bruno. Yes, please. I'm currently traveling for KS and Plumbers, so I cannot debug it deeply, unfortunately. If the culprit were really my patch, I still don't figure out why it breaks. In that case, it must be really a subtle timing issue... thanks, Takashi

1 0

Re: [alsa-devel] [PATCH - pcxhr 1/1] ALSA: pcxhr: Add 8 new sound cards
by Takashi Iwai 25 Aug '12

25 Aug '12

At Fri, 24 Aug 2012 16:22:57 +0200, Markus Bollinger wrote: > > add new sound cards VX442HR VX442e PCX442HR PCX442e VX822HR VX822e PCX822HR > and PCX822e > > Signed-off-by: Markus Bollinger <bollinger(a)digigram.com> The changes look OK, but the patch file embedded in the mail looks broken. If it's difficult to embed the patch, could you use an attachment? thanks, Takashi > > diff --git a/pci/pcxhr/pcxhr.c b/pci/pcxhr/pcxhr.c > index e3ac1f7..be4f145 100644 > --- a/pci/pcxhr/pcxhr.c > +++ b/pci/pcxhr/pcxhr.c > @@ -91,6 +91,14 @@ enum { > PCI_ID_PCX924E, > PCI_ID_PCX924HRMIC, > PCI_ID_PCX924E_MIC, > + PCI_ID_VX442HR, > + PCI_ID_PCX442HR, > + PCI_ID_VX442E, > + PCI_ID_PCX442E, > + PCI_ID_VX822HR, > + PCI_ID_PCX822HR, > + PCI_ID_VX822E, > + PCI_ID_PCX822E, > PCI_ID_LAST > }; > > @@ -121,6 +129,14 @@ static DEFINE_PCI_DEVICE_TABLE(pcxhr_ids) = { > { 0x10b5, 0x9056, 0x1369, 0xbb21, 0, 0, PCI_ID_PCX924E, }, > { 0x10b5, 0x9056, 0x1369, 0xbf01, 0, 0, PCI_ID_PCX924HRMIC, }, > { 0x10b5, 0x9056, 0x1369, 0xbf21, 0, 0, PCI_ID_PCX924E_MIC, }, > + { 0x10b5, 0x9656, 0x1369, 0xd001, 0, 0, PCI_ID_VX442HR, }, > + { 0x10b5, 0x9656, 0x1369, 0xd101, 0, 0, PCI_ID_PCX442HR, }, > + { 0x10b5, 0x9056, 0x1369, 0xd021, 0, 0, PCI_ID_VX442E, }, > + { 0x10b5, 0x9056, 0x1369, 0xd121, 0, 0, PCI_ID_PCX442E, }, > + { 0x10b5, 0x9656, 0x1369, 0xd201, 0, 0, PCI_ID_VX822HR, }, > + { 0x10b5, 0x9656, 0x1369, 0xd301, 0, 0, PCI_ID_PCX822HR, }, > + { 0x10b5, 0x9056, 0x1369, 0xd221, 0, 0, PCI_ID_VX822E, }, > + { 0x10b5, 0x9056, 0x1369, 0xd321, 0, 0, PCI_ID_PCX822E, }, > { 0, } > }; > > @@ -160,6 +176,14 @@ static struct board_parameters pcxhr_board_params[] = { > [PCI_ID_PCX924E] = { "PCX924e", 1, 1, 5, 44 }, > [PCI_ID_PCX924HRMIC] = { "PCX924HR-Mic", 1, 1, 5, 44 }, > [PCI_ID_PCX924E_MIC] = { "PCX924e-Mic", 1, 1, 5, 44 }, > +[PCI_ID_VX442HR] = { "VX442HR", 2, 2, 0, 41 }, > +[PCI_ID_PCX442HR] = { "PCX442HR", 2, 2, 0, 41 }, > +[PCI_ID_VX442E] = { "VX442e", 2, 2, 1, 41 }, > +[PCI_ID_PCX442E] = { "PCX442e", 2, 2, 1, 41 }, > +[PCI_ID_VX822HR] = { "VX822HR", 4, 1, 2, 42 }, > +[PCI_ID_PCX822HR] = { "PCX822HR", 4, 1, 2, 42 }, > +[PCI_ID_VX822E] = { "VX822e", 4, 1, 3, 42 }, > +[PCI_ID_PCX822E] = { "PCX822e", 4, 1, 3, 42 }, > }; > > /* boards without hw AES1 and SRC onboard are all using fw_file_set==4 */ > diff --git a/pci/pcxhr/pcxhr_hwdep.c b/pci/pcxhr/pcxhr_hwdep.c > index ec1587c..bf207e3 100644 > --- a/pci/pcxhr/pcxhr_hwdep.c > +++ b/pci/pcxhr/pcxhr_hwdep.c > @@ -66,10 +66,10 @@ static int pcxhr_init_board(struct pcxhr_mgr *mgr) > err = pcxhr_send_msg(mgr, &rmh); > if (err) > return err; > - /* test 8 or 12 phys out */ > - if ((rmh.stat[0] & MASK_FIRST_FIELD) != mgr->playback_chips * 2) > + /* test 4, 8 or 12 phys out */ > + if ((rmh.stat[0] & MASK_FIRST_FIELD) < mgr->playback_chips * 2) > return -EINVAL; > - /* test 8 or 2 phys in */ > + /* test 4, 8 or 2 phys in */ > if (((rmh.stat[0] >> (2 * FIELD_SIZE)) & MASK_FIRST_FIELD) < > mgr->capture_chips * 2) > return -EINVAL; > -- > 1.7.9.5

1 0

[alsa-devel] [PATCH] ASoC: wm0010: Enable 44.1kHz support
by Mark Brown 25 Aug '12

25 Aug '12

With appropriate clocking configuration the WM0010 driver supports 44.1kHz audio; enable that. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm0010.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/wm0010.c b/sound/soc/codecs/wm0010.c index e1315e0..f820b57 100644 --- a/sound/soc/codecs/wm0010.c +++ b/sound/soc/codecs/wm0010.c @@ -722,7 +722,7 @@ static struct snd_soc_codec_driver soc_codec_dev_wm0010 = { .num_dapm_routes = ARRAY_SIZE(wm0010_dapm_routes), }; -#define WM0010_RATES (SNDRV_PCM_RATE_48000) +#define WM0010_RATES (SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000) #define WM0010_FORMATS (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE |\ SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S24_LE |\ SNDRV_PCM_FMTBIT_S32_LE) -- 1.7.10.4

1 0

Re: [alsa-devel] Logitech USB headset not working in 3.6-rc3
by Daniel Mack 25 Aug '12

25 Aug '12

On 25.08.2012 14:07, Bruno Wolff III wrote: > On Sat, Aug 25, 2012 at 14:02:51 +0200, > Daniel Mack <zonque(a)gmail.com> wrote: >> >> Can you revert commit e9ba389c5 ("ALSA: usb-audio: Fix >> scheduling-while-atomic bug in PCM capture stream") and see if that > > I can try that, but it takes a long time to build a new kernel on my > old hardware. > >> helps? If not, can you summarize again which kernels still work for you >> and which don't? > > The latest kernel that works is 3.6.0-0.rc2.git1.2.fc18. The earliest that > doesn't work is 3.6.0-0.rc2.git2.1.fc18. > The report you sent doesn't look like it could be caused by e9ba389c5. It fixes a kernel Ooops. But as it is the only relevant patch in that area, it would be interesting if reverting it fixes anything. Btw - thanks a lot for testing -rc kernels, much appreciated! Daniel

1 0