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

Re: [alsa-devel] [PATCH] soc/sh: Fix I2C dependency for SND_FSI_AK4642
by Mark Brown 14 Jun '10

14 Jun '10

On Mon, Jun 14, 2010 at 05:39:41PM +0200, Peter Huewe wrote: > bool "FSI-AK4642 sound support" > depends on SND_SOC_SH4_FSI > select SND_SOC_AK4642 > + select I2C I'd have thought a depends was more appropriate. Arguably you want to depend on the SH I2C driver since the driver is useless without the relevant I2C controller.

1 0

[alsa-devel] [PATCH] ASoC: DaVinci: Fix McASP hardware FIFO configuration
by Sudhakar Rajashekhara 14 Jun '10

14 Jun '10

On DA830/OMAP-L137 and DA850/OMAP-L138 SoCs, the McASP peripheral has FIFO support. This FIFO provides additional data buffering. It also provides tolerance to variation in host/DMA controller response times. More details of the FIFO operation can be found at http://focus.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=spr… Existing sequence of steps for audio playback/capture are: a. DMA configuration b. McASP configuration (configures and enables FIFO) c. Start DMA d. Start McASP (enables FIFO) During McASP configuration, while FIFO was being configured, FIFO was being enabled in davinci_hw_common_param() function of sound/soc/davinci/davinci-mcasp.c file. This generated a transmit DMA event, which gets serviced when DMA is started. https://patchwork.kernel.org/patch/84611/ patch clears the DMA events before starting DMA, which is the right thing to do. But this resulted in a state where DMA was waiting for an event from McASP (after step c above), but the event which was already there, has got cleared (because of step b above). The fix is not to enable the FIFO during McASP configuration as FIFO was being enabled as part of McASP start. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj(a)ti.com> --- Applies to latest of Linus's tree. sound/soc/davinci/davinci-mcasp.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index 79f0f4a..d395509 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -612,7 +612,6 @@ static void davinci_hw_common_param(struct davinci_audio_dev *dev, int stream) NUMDMA_MASK); mcasp_mod_bits(dev->base + DAVINCI_MCASP_WFIFOCTL, ((dev->txnumevt * tx_ser) << 8), NUMEVT_MASK); - mcasp_set_bits(dev->base + DAVINCI_MCASP_WFIFOCTL, FIFO_ENABLE); } if (dev->rxnumevt && stream == SNDRV_PCM_STREAM_CAPTURE) { @@ -623,7 +622,6 @@ static void davinci_hw_common_param(struct davinci_audio_dev *dev, int stream) NUMDMA_MASK); mcasp_mod_bits(dev->base + DAVINCI_MCASP_RFIFOCTL, ((dev->rxnumevt * rx_ser) << 8), NUMEVT_MASK); - mcasp_set_bits(dev->base + DAVINCI_MCASP_RFIFOCTL, FIFO_ENABLE); } } -- 1.5.6

2 1

Re: [alsa-devel] [PATCH 3/4] ALSA: usb-audio: parse UAC2 sample rate ranges correctly
by Daniel Mack 14 Jun '10

14 Jun '10

On Fri, Jun 11, 2010 at 10:59:44PM +0800, Alex Lee wrote: > If the device has a variable clock, it may report a RES of only 1. So you > may end up with thousands (and even millions) of sample rates. It might be > better to have separate code to cater to discrete clocks vs variable clocks. Just for the records: this is exactly what Mac OS X does, and it will comsume 100% CPU when a device with such descriptors is plugged in. So even though this is now sanely handled by ALSA, it really shouldn't be done that way by implementors. Daniel

1 0

Re: [alsa-devel] [PATCH 1/1] ALSA: hda - Fix line-in for mb5 model MacBook (Pro) 5, 1 / 5, 2
by Takashi Iwai 14 Jun '10

14 Jun '10

At Mon, 14 Jun 2010 16:31:21 +0930, Alex Murray wrote: > > Takashi - There is no incompatibilty, both are the same - the mb5 model > is used for all MacBook (Pro) 5,1 / 5,2 models, the only differnce > between the Pro and non-Pro is the Pro has the subwoofer (LFE) which the > non-Pro lacks. > > You can see here > http://ubuntuforums.org/showpost.php?p=9444153&postcount=3 for a copy > of /proc/asound/card0/codec#0 on a MacBook 5,1 (i.e. not Pro) which > confirms the line-out is 0x7 for that model as well - I've tested this > directly on my MacBook Pro 5,1 - so I am 100% confident this is correct > for both Pro and non-Pro models, unless you have evidence otherwise? OK, then it's all green. I applied the patch now. Thanks for a quick response! Takashi

1 0

Re: [alsa-devel] [PATCH 1/1] ALSA: hda - Fix line-in for mb5 model MacBook (Pro) 5, 1 / 5, 2
by Takashi Iwai 14 Jun '10

14 Jun '10

At Mon, 14 Jun 2010 12:08:43 +0930, murray.alex(a)gmail.com wrote: > > From: Alex Murray <murray.alex(a)gmail.com> > > The line-in input is 0x7 not 0x2 for MacBook (Pro) 5,1 / 5,2 models > > Signed-off-by: Alex Murray <murray.alex(a)gmail.com> MB5 != MBP5, so I suspect this might be rather the incompatibility between them... Takashi > > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c > index 17d4548..007f96b 100644 > --- a/sound/pci/hda/patch_realtek.c > +++ b/sound/pci/hda/patch_realtek.c > @@ -6948,7 +6948,7 @@ static struct hda_input_mux mb5_capture_source = { > .num_items = 3, > .items = { > { "Mic", 0x1 }, > - { "Line", 0x2 }, > + { "Line", 0x7 }, > { "CD", 0x4 }, > }, > }; > @@ -7469,8 +7469,8 @@ static struct snd_kcontrol_new alc885_mb5_mixer[] = { > HDA_BIND_MUTE ("LFE Playback Switch", 0x0e, 0x02, HDA_INPUT), > HDA_CODEC_VOLUME("Headphone Playback Volume", 0x0f, 0x00, HDA_OUTPUT), > HDA_BIND_MUTE ("Headphone Playback Switch", 0x0f, 0x02, HDA_INPUT), > - HDA_CODEC_VOLUME("Line Playback Volume", 0x0b, 0x02, HDA_INPUT), > - HDA_CODEC_MUTE ("Line Playback Switch", 0x0b, 0x02, HDA_INPUT), > + HDA_CODEC_VOLUME("Line Playback Volume", 0x0b, 0x07, HDA_INPUT), > + HDA_CODEC_MUTE ("Line Playback Switch", 0x0b, 0x07, HDA_INPUT), > HDA_CODEC_VOLUME("Mic Playback Volume", 0x0b, 0x01, HDA_INPUT), > HDA_CODEC_MUTE ("Mic Playback Switch", 0x0b, 0x01, HDA_INPUT), > HDA_CODEC_VOLUME("Line Boost", 0x15, 0x00, HDA_INPUT), > @@ -7853,10 +7853,9 @@ static struct hda_verb alc885_mb5_init_verbs[] = { > {0x15, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN}, > {0x15, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE}, > > - {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(1)}, > - {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(3)}, > - {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(2)}, > - {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(4)}, > + {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0x1)}, > + {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0x7)}, > + {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0x4)}, > { } > }; > > -- > 1.7.0.4 >

1 0

Re: [alsa-devel] ALSA's jack reporting framework map to Android framework
by Mark Brown 14 Jun '10

14 Jun '10

On 12 Jun 2010, at 23:36, Mike Lockwood wrote: > There is no requirement to use the switch driver for the headset > detect. At the time we did this we couldn't find an existing standard > and we had already written the switch driver for something else, so it > was an easy solution at the time. But if there is something better > available now I don't see any reason not to use it. In situations like this I'd always recommend discussing upstream - there may be something you've missed, or if there isn't then it means whatever you come up with can be adopted as a standard by everyone. > I don't know what the current thinking is about ALSA and android - > someone on our media team would need to address that part of the > thread. But if using ALSA requires GPL/LGPL code in userspace that > would probably be a deal breaker right there. Obviously there's already the option of using ALSA with the regular libraries (which are LGPLed) in Android which a bunch of vendors are using already - there's existing drivers for a range of CPUs and CODECs and many vendors are already shipping other Linux based OSs on their devices outside of Android which use things like the standard audio stack and so don't have a problem with LGPL in userspace. Discussions with Brian Swetland (CCed in so he can correct me if I'm off base here) suggested that a direct to kernel option bypassing the standard libraries might be developed under a MITish license to provide as a default. This is obviously much less work than developing an entirely new audio stack would be, and unless plugins are in use the userspace portion is very thin.

2 1

Re: [alsa-devel] Contents of Alsa-devel digest..
by Junhwa Rhee 14 Jun '10

14 Jun '10

Re: Contents of Alsa-devel digest..

1 0

[alsa-devel] BUG: cx88 can't find device struct
by Timothy E. Krantz 13 Jun '10

13 Jun '10

Hi, I started looking into this problem a while back and gave up. Now I decided to try again. I am running MythDora 12.23 and would like to update the alsa driver to 1.0.23 so that I can use HDMI audio out on my nvidia GT220 card. So I download the alsa-driver-1.0.23.tar.bz file, unpack it, ./configure and make and make install. When I reboot I can verify the new alsa driver by cat/proc/asound/version and it is indeed 1.0.23. If I then try to record an analog station I get: Jun 9 14:40:19 mythdora kernel: BUG: cx88 can't find device struct. Can't proceed with open Jun 9 14:40:19 mythdora kernel: cx88[1]: Calling XC5000 callback Jun 9 14:40:19 mythdora kernel: BUG: cx88 can't find device struct. Can't proceed with open Hmmm, ok the alsa driver implementation updated some kernel header file perhaps, so I download the latest v4l-dvb tree and compile it and install it and reboot. Same thing. No sound on analog recordings. I am sure I am missing some important step or something. Any help would be greatly appreciated! Tim

2 1

Re: [alsa-devel] Alsa-devel Digest, Vol 40, Issue 58
by Tobias Schneider 13 Jun '10

13 Jun '10

----- Ursprüngliche Nachricht ----- Von: alsa-devel-request(a)alsa-project.org Gesendet: Sonntag, 13. Juni 2010 12:00 An: alsa-devel(a)alsa-project.org Betreff: Alsa-devel Digest, Vol 40, Issue 58 Send Alsa-devel mailing list submissions to alsa-devel(a)alsa-project.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.alsa-project.org/mailman/listinfo/alsa-devel or, via email, send a message with subject or body 'help' to alsa-devel-request(a)alsa-project.org You can reach the person managing the list at alsa-devel-owner(a)alsa-project.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Alsa-devel digest..." Today's Topics: 1. Re: ALSA's jack reporting framework map to Android framework (Mark Brown) 2. Re: [PATCH] ASoC: Remove unused header (Mark Brown) 3. Re: Timing Info (Paul Dugas) ---------------------------------------------------------------------- Message: 1 Date: Sat, 12 Jun 2010 18:05:52 +0100 From: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Subject: Re: [alsa-devel] ALSA's jack reporting framework map to Android framework To: "Harsha, Priya" <priya.harsha(a)intel.com> Cc: "alsa-devel(a)alsa-project.org" <alsa-devel(a)alsa-project.org>, Mike Lockwood <lockwood(a)android.com> Message-ID: <20100612170552.GA3110(a)sirena.org.uk> Content-Type: text/plain; charset=us-ascii On Sat, Jun 12, 2010 at 09:28:34AM +0530, Harsha, Priya wrote: Please fix your MUA to word wrap your messages, it makes them more legible and easier to reply to. > The ALSA's jack reporting framework reports jacks at > /dev/input/eventx. But the Android framework expects the jack reporting > to be done in /sys/.../switch/h2w. That ... is simply 'class' - the Android kernel includes a new sysfs class for switches, CCing in Mike Lockwood who wrote it in case he's got any input from the Android side. > Any suggestions as to how the ALSA's jack reporting framework to > Android framework? Are there any audio drivers that have mapped this? The obvious thing to do here seems to be to update the Android framework to be able to use the standard kernel interfaces. I obviously can't speak for Google but it seems like the sort of patch they'd be willing to accept, especially if you retain the ability to use the non-standard extensions that are currently being used. I guess an alternative would be to have the Android kernels add an adaptor in the input subsystem (for various reasons not all jack sense goes through ALSA) so that input subsystem switches get represented via the Android switch ABI, though that would increase the amount of out of tree code that needs to be carried and so seems like the wrong direction to be heading. ------------------------------ Message: 2 Date: Sat, 12 Jun 2010 18:07:15 +0100 From: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Subject: Re: [alsa-devel] [PATCH] ASoC: Remove unused header To: Liam Girdwood <lrg(a)slimlogic.co.uk> Cc: Grant Likely <grant.likely(a)secretlab.ca>, Herb Peyerl <hpeyerl(a)beer.org>, alsa-devel(a)alsa-project.org, linux-kernel(a)vger.kernel.org Message-ID: <20100612170715.GB3110(a)sirena.org.uk> Content-Type: text/plain; charset=us-ascii On Fri, Jun 11, 2010 at 10:50:40AM +0100, Liam Girdwood wrote: > On Thu, 2010-06-10 at 17:54 -0600, Grant Likely wrote: > > The header contains an extern that isn't used by anything. Remove. > > Signed-off-by: Grant Likely <grant.likely(a)secretlab.ca> > Acked-by: Liam Girdwood <lrg(a)slimlogic.co.uk> Applied, thanks. ------------------------------ Message: 3 Date: Sat, 12 Jun 2010 17:59:27 -0400 From: Paul Dugas <paul(a)dugasenterprises.com> Subject: Re: [alsa-devel] Timing Info To: alsa-devel(a)alsa-project.org Message-ID: <AANLkTik3ycq3POxHRG_bc0jO-KByZVvirVJ-X9-bySY_(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Fri, Jun 11, 2010 at 6:00 PM, Paul Dugas <paul(a)dugasenterprises.com> wrote: > I'm using snd_pcm_readi() to collect samples and am wondering if/how I > can get accurate timestamps for them. ?Seems like the snd_pcm_status() > gives me this info but I'm unclear on the specifics. ?Can someone > point me toward the correct field in the status structure that I > should be using and what sample that timestamp corresponds to? > > Does snd_pcm_status_get_tstamp() get me the timestamp for the first > frame returned by the next snd_pcm_readi() call? I know now get_tstamp() isn't what I'm looking for after reading some prior postings and other web sites. Can't seem to find a discussion of timing in the ALSA docs themselves. Maybe I'm being dense. Looks like some processing of the trigger timestamp is what I need but I'm not following the logic of "triggers" in the simple use of snd_pcm_readi() that I've got. Before the first readi() call, the trigger time is 0. The second time, it's pretty close to the wall time for the first call. Perhaps that's the timestamp of the first sample of the first period I read and I need to add the period_time each time? Seems like that'd accrue error when recording over longer periods of time (which my application does). What's the "timestamp mode". Does it generate a timestamp each period? How would I access that timestamp? Thanks in advance for any assistance, Paul ------------------------------ _______________________________________________ Alsa-devel mailing list Alsa-devel(a)alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel End of Alsa-devel Digest, Vol 40, Issue 58 ******************************************

1 0

[alsa-devel] [PATCH] ASoC: Remove unused header
by Grant Likely 12 Jun '10

12 Jun '10

The header contains an extern that isn't used by anything. Remove. Signed-off-by: Grant Likely <grant.likely(a)secretlab.ca> Cc: Liam Girdwood <lrg(a)slimlogic.co.uk> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Cc: Jon Smirl <jonsmirl(a)gmail.com> Cc: Herb Peyerl <hpeyerl(a)beer.org> --- sound/soc/fsl/mpc5200_psc_i2s.c | 1 - sound/soc/fsl/mpc5200_psc_i2s.h | 12 ------------ 2 files changed, 0 insertions(+), 13 deletions(-) delete mode 100644 sound/soc/fsl/mpc5200_psc_i2s.h diff --git a/sound/soc/fsl/mpc5200_psc_i2s.c b/sound/soc/fsl/mpc5200_psc_i2s.c index 4f455bd..676841c 100644 --- a/sound/soc/fsl/mpc5200_psc_i2s.c +++ b/sound/soc/fsl/mpc5200_psc_i2s.c @@ -16,7 +16,6 @@ #include <asm/mpc52xx_psc.h> -#include "mpc5200_psc_i2s.h" #include "mpc5200_dma.h" /** diff --git a/sound/soc/fsl/mpc5200_psc_i2s.h b/sound/soc/fsl/mpc5200_psc_i2s.h deleted file mode 100644 index ce55e07..0000000 --- a/sound/soc/fsl/mpc5200_psc_i2s.h +++ /dev/null @@ -1,12 +0,0 @@ -/* - * Freescale MPC5200 PSC in I2S mode - * ALSA SoC Digital Audio Interface (DAI) driver - * - */ - -#ifndef __SOUND_SOC_FSL_MPC52xx_PSC_I2S_H__ -#define __SOUND_SOC_FSL_MPC52xx_PSC_I2S_H__ - -extern struct snd_soc_dai psc_i2s_dai[]; - -#endif /* __SOUND_SOC_FSL_MPC52xx_PSC_I2S_H__ */

3 2