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

[alsa-devel] [PATCH v5 0/5] OMAP/ASoC: McBSP: FIFO handling related fixes
by Peter Ujfalusi 03 Jun '10

03 Jun '10

Hello, Tony: Could you take a look at the arch/arm patches in this series? Thanks! Changes since v3/4: - Fixed commit subjects and messages for OMAP3 related patches - Added Acked-by from Mark, and Jarkko Intro message from the original series: This series aims to correct how the McBSP FIFO is viewed, and handled. Introduction of the problem: OMAP McBSP FIFO is word structured: McBSP2 has 1024 + 256 = 1280 word long buffer, McBSP1,3,4,5 has 128 word long buffer This means, that the size of the FIFO depends on the McBSP word size configuration. For example on McBSP3: 16bit samples: size is 128 * 2 = 256 bytes 32bit samples: size is 128 * 4 = 512 bytes It is simpler to place constraint for buffer and period based on channels. McBSP3 as example again (16 or 32 bit samples): 1 channel (mono): size is 128 frames (128 words) 2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words) 4 channels: size is 128 / 4 = 32 frames (4 * 32 words) Since now the McBSP codec supports not only 16bit samples (32biut has been recently added), the FIFO size handling is no longer correct, since it has been hard wired for 16bit word length. The series changes how the users of McBSP are configuring the FIFO: It used to be 0 based (0 meant 1 word threshold). After this series users can configure the threshold in 1 base mode (1 means 1 word threshold). The platform code now provides the full size of the FIFO in words, instead of the already limited value used in the past. In ASoC omap-mcbsp code hw_rule based constraint refinement is going to be used instead of the hardwired static constraint, which was correct only in case of 16bit word length. The hw_rule is refining the minimum buffer size based on the channel number going to be used by the coming stream. In case of threshold mode additional hw_rule refines the maximum allowed period size. The series are generated agains Takashi's sound-2.6: topic/asoc branch. CCing also Eduardo, and Eero since they have worked on the original FIFO/threshold implementation. All commetns and testers are welcome! Peter --- Peter Ujfalusi (5): OMAP: McBSP: Function to query the FIFO size OMAP3: McBSP: Change the way how the FIFO is handled OMAP3: McBSP: Use the port's buffer_size when calculating tx delay ASoC: omap-mcbsp: Save, and use wlen for threshold configuration ASoC: omap-mcbsp: Place correct constraints for streams arch/arm/mach-omap2/mcbsp.c | 10 ++-- arch/arm/plat-omap/include/plat/mcbsp.h | 2 + arch/arm/plat-omap/mcbsp.c | 51 ++++++++++----- sound/soc/omap/omap-mcbsp.c | 112 +++++++++++++++++++++++------- 4 files changed, 128 insertions(+), 47 deletions(-)

3 7

Re: [alsa-devel] [PATCH] AsoC/s3c: patch for the unnecessary variable 'state' removal
by Liam Girdwood 03 Jun '10

03 Jun '10

On Thu, 2010-06-03 at 00:54 +0800, Wan ZongShun wrote: > The variable 'state' of structure 's3c_ac97_info' seems no use here, > so this patch is to remove the unnecessary variable. > > Signed-off-by: Wan ZongShun <mcuos.com(a)gmail.com> > --- > sound/soc/s3c24xx/s3c-ac97.c | 1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > > diff --git a/sound/soc/s3c24xx/s3c-ac97.c b/sound/soc/s3c24xx/s3c-ac97.c > index ecf4fd0..31f6d45 100644 > --- a/sound/soc/s3c24xx/s3c-ac97.c > +++ b/sound/soc/s3c24xx/s3c-ac97.c > @@ -31,7 +31,6 @@ > #define AC_CMD_DATA(x) (x & 0xffff) > > struct s3c_ac97_info { > - unsigned state; > struct clk *ac97_clk; > void __iomem *regs; > struct mutex lock; Acked-by: Liam Girdwood <lrg(a)slimlogic.co.uk> -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk

1 0

Re: [alsa-devel] [PATCH] AsoC/atmel: patch for the unnecessary variable removal
by Liam Girdwood 03 Jun '10

03 Jun '10

On Thu, 2010-06-03 at 00:28 +0800, Wan ZongShun wrote: > The variable 'periods' of structure 'atmel_runtime_data' > seems no use in whole atmel alsa driver,so I make a patch > to remove the unnecessary variable. > > Signed-off-by: Wan ZongShun <mcuos.com(a)gmail.com> > --- > sound/soc/atmel/atmel-pcm.c | 1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > > diff --git a/sound/soc/atmel/atmel-pcm.c b/sound/soc/atmel/atmel-pcm.c > index f6b3cc0..dc5249f 100644 > --- a/sound/soc/atmel/atmel-pcm.c > +++ b/sound/soc/atmel/atmel-pcm.c > @@ -77,7 +77,6 @@ struct atmel_runtime_data { > size_t period_size; > > dma_addr_t period_ptr; /* physical address of next period */ > - int periods; /* period index of period_ptr */ > > /* PDC register save */ > u32 pdc_xpr_save; Acked-by: Liam Girdwood <lrg(a)slimlogic.co.uk> -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk

1 0

Re: [alsa-devel] [PATCH V4] ASoC/au1x: use resource_size for au1x
by Wan ZongShun 03 Jun '10

03 Jun '10

Hi mark, How about this patch? Applied? 在 2010年6月1日下午3:16，Wan ZongShun <mcuos.com(a)gmail.com> 写道： > Dear all, > > Use the resource_size function instead of manually calculating the > resource size.This patch can reduce the chance of introducing off-by-one > errors. > > Thanks! > > Signed-off-by: Wan ZongShun<mcuos.com(a)gmail.com> > --- > sound/soc/au1x/psc-ac97.c | 13 +++++-------- > sound/soc/au1x/psc-i2s.c | 13 +++++-------- > sound/soc/au1x/psc.h | 1 - > 3 files changed, 10 insertions(+), 17 deletions(-) > > diff --git a/sound/soc/au1x/psc-ac97.c b/sound/soc/au1x/psc-ac97.c > index a61ccd2..d14a5a9 100644 > --- a/sound/soc/au1x/psc-ac97.c > +++ b/sound/soc/au1x/psc-ac97.c > @@ -375,12 +375,10 @@ static int __devinit au1xpsc_ac97_drvprobe(struct platform_device *pdev) > } > > ret = -EBUSY; > - wd->ioarea = request_mem_region(r->start, r->end - r->start + 1, > - "au1xpsc_ac97"); > - if (!wd->ioarea) > + if (!request_mem_region(r->start, resource_size(r), pdev->name)) > goto out0; > > - wd->mmio = ioremap(r->start, 0xffff); > + wd->mmio = ioremap(r->start, resource_size(r)); > if (!wd->mmio) > goto out1; > > @@ -410,8 +408,7 @@ static int __devinit au1xpsc_ac97_drvprobe(struct platform_device *pdev) > > snd_soc_unregister_dai(&au1xpsc_ac97_dai); > out1: > - release_resource(wd->ioarea); > - kfree(wd->ioarea); > + release_mem_region(r->start, resource_size(r)); > out0: > kfree(wd); > return ret; > @@ -420,6 +417,7 @@ out0: > static int __devexit au1xpsc_ac97_drvremove(struct platform_device *pdev) > { > struct au1xpsc_audio_data *wd = platform_get_drvdata(pdev); > + struct resource *r = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > if (wd->dmapd) > au1xpsc_pcm_destroy(wd->dmapd); > @@ -433,8 +431,7 @@ static int __devexit au1xpsc_ac97_drvremove(struct platform_device *pdev) > au_sync(); > > iounmap(wd->mmio); > - release_resource(wd->ioarea); > - kfree(wd->ioarea); > + release_mem_region(r->start, resource_size(r)); > kfree(wd); > > au1xpsc_ac97_workdata = NULL; /* MDEV */ > diff --git a/sound/soc/au1x/psc-i2s.c b/sound/soc/au1x/psc-i2s.c > index 495be6e..737b238 100644 > --- a/sound/soc/au1x/psc-i2s.c > +++ b/sound/soc/au1x/psc-i2s.c > @@ -321,12 +321,10 @@ static int __init au1xpsc_i2s_drvprobe(struct platform_device *pdev) > } > > ret = -EBUSY; > - wd->ioarea = request_mem_region(r->start, r->end - r->start + 1, > - "au1xpsc_i2s"); > - if (!wd->ioarea) > + if (!request_mem_region(r->start, resource_size(r), pdev->name)) > goto out0; > > - wd->mmio = ioremap(r->start, 0xffff); > + wd->mmio = ioremap(r->start, resource_size(r)); > if (!wd->mmio) > goto out1; > > @@ -362,8 +360,7 @@ static int __init au1xpsc_i2s_drvprobe(struct platform_device *pdev) > > snd_soc_unregister_dai(&au1xpsc_i2s_dai); > out1: > - release_resource(wd->ioarea); > - kfree(wd->ioarea); > + release_mem_region(r->start, resource_size(r)); > out0: > kfree(wd); > return ret; > @@ -372,6 +369,7 @@ out0: > static int __devexit au1xpsc_i2s_drvremove(struct platform_device *pdev) > { > struct au1xpsc_audio_data *wd = platform_get_drvdata(pdev); > + struct resource *r = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > if (wd->dmapd) > au1xpsc_pcm_destroy(wd->dmapd); > @@ -384,8 +382,7 @@ static int __devexit au1xpsc_i2s_drvremove(struct platform_device *pdev) > au_sync(); > > iounmap(wd->mmio); > - release_resource(wd->ioarea); > - kfree(wd->ioarea); > + release_mem_region(r->start, resource_size(r)); > kfree(wd); > > au1xpsc_i2s_workdata = NULL; /* MDEV */ > diff --git a/sound/soc/au1x/psc.h b/sound/soc/au1x/psc.h > index 32d3807..093775d 100644 > --- a/sound/soc/au1x/psc.h > +++ b/sound/soc/au1x/psc.h > @@ -32,7 +32,6 @@ struct au1xpsc_audio_data { > unsigned long rate; > > unsigned long pm[2]; > - struct resource *ioarea; > struct mutex lock; > struct platform_device *dmapd; > }; > -- > 1.6.3.3 > -- *linux-arm-kernel mailing list mail addr:linux-arm-kernel@lists.infradead.org you can subscribe by: http://lists.infradead.org/mailman/listinfo/linux-arm-kernel * linux-arm-NUC900 mailing list mail addr:NUC900@googlegroups.com main web: https://groups.google.com/group/NUC900 you can subscribe it by sending me mail: mcuos.com(a)gmail.com

3 3

[alsa-devel] ASoC: Hooking a TI CODEC to a i.MX27 MCU
by Stuart Longland 03 Jun '10

03 Jun '10

Hi all, I'm trying to write a new machine driver and CODEC driver for a device we're building, and as yet, haven't figured out the magic that gets ALSA to enumerate all the devices on the board. I hope to be able to release any code here back to the community, but I probably need to clear it with a few people first (and it'd be nice to contribute _working_ code). Scenario: MCU is a Freescale i.MX27 processor on a Ka-Ro TX27 module CODEC is a Texas Instruments TLV320AIC3204, control via I²C, data via I²S. Chip ID for this CODEC is locked at 0x18. Kernel is 2.6.34, userland is Gentoo/ARM via root-over-NFS. My goal: Just to get audio being transmitted along the I²S bus. (Don't care about mixers, etc.) So far my only means of debugging everything is to sprinkle the code liberally with printk's everywhere... crude, but it gives me some idea what's going on. The CODEC driver is at this moment, an empty shell based on the TLV320AIC3x driver already in the tree. I've tried basing a machine driver on the rx51 driver -- substituting the TLV320AIC3x driver for my own shell driver, and swapping the original cpu_dai configuration for the i.MX driver. I suspect this machine driver is giving me grief. My machine code setup is as follows: /* Digital audio interface glue - connects codec <--> CPU */ static struct snd_soc_dai_link jem3_dai[] = { { .name = "TLV320AIC3204", .stream_name = "AIC3204", .cpu_dai = &imx_ssi_pcm_dai[0], .codec_dai = &aic3204_dai, .init = jem3_aic3204_init, .ops = &jem3_ops, }, }; /* Audio private data */ static struct aic3204_setup_data jem3_aic3204_setup = { .gpio_func[0] = AIC3204_GPIO1_FUNC_DISABLED, .gpio_func[1] = AIC3204_GPIO2_FUNC_DIGITAL_MIC_INPUT, }; /* Audio card */ static struct snd_soc_card jem3_sound_card = { .name = "JEM3", .dai_link = jem3_dai, .num_links = ARRAY_SIZE(jem3_dai), .platform = &imx_soc_platform, }; /* Audio subsystem */ static struct snd_soc_device jem3_snd_devdata = { .card = &jem3_sound_card, .codec_dev = &soc_codec_dev_aic3204, .codec_data = &jem3_aic3204_setup, }; static struct platform_device *jem3_snd_device; static int __init jem3_soc_init(void) { int err; printk( KERN_INFO "%s: hello...\n", __FUNCTION__ ); jem3_snd_device = platform_device_alloc("soc-audio", -1); printk( KERN_INFO "%s: jem3_snd_device = %p\n", __FUNCTION__, jem3_snd_device ); if (!jem3_snd_device) { err = -ENOMEM; goto err1; } printk( KERN_INFO "%s: calling platform_set_drvdata( %p, %p )\n", __FUNCTION__, jem3_snd_device, &jem3_snd_devdata ); platform_set_drvdata(jem3_snd_device, &jem3_snd_devdata); jem3_snd_devdata.dev = &jem3_snd_device->dev; printk( KERN_INFO "%s: calling platform_device_add(%p)\n", __FUNCTION__, jem3_snd_device ); err = platform_device_add(jem3_snd_device); printk( KERN_INFO "%s: platform_device_add(%p) = %d\n", __FUNCTION__, jem3_snd_device, err ); if (err) goto err2; printk( KERN_INFO "%s = 0 (success)\n", __FUNCTION__ ); return 0; err2: platform_device_put(jem3_snd_device); err1: printk( KERN_INFO "%s = %d\n", __FUNCTION__, err ); return err; } Now this compiles... but when I go to load it; one of two things happens... either practically nothing (at this stage; no modules are loaded prior to calling modprobe): 192 / # modprobe snd-soc-jem3 aic3204_i2c_init: adding driver at bf068f9c aic3204_i2c_init: i2c_add_driver(bf068f9c) = 0 jem3_soc_init: hello... jem3_soc_init: jem3_snd_device = c3c600a0 jem3_soc_init: calling platform_set_drvdata( c3c600a0, bf07a780 ) jem3_soc_init: calling platform_device_add(c3c600a0) jem3_soc_init: platform_device_add(c3c600a0) = 0 jem3_soc_init = 0 (success) 192 / # mount /proc 192 / # cat /proc/asound/cards --- no soundcards --- ... Or it goes kaboom... particularly if I rmmod the snd-soc-jem3 module, but leave snd-soc-tlv320aic3204 in place... 192 / # rmmod snd-soc-jem3 jem3_soc_exit: unregistering... jem3_soc_exit: goodbye 192 / # modprobe snd-soc-jem3 jem3_soc_init: hello... jem3_soc_init: jem3_snd_device = c3c600a0 jem3_soc_init: calling platform_set_drvdata( c3c600a0, bf080780 ) jem3_soc_init: calling platform_device_add(c3c600a0) Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = c3e44000 [00000008] *pgd=a3e62031, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT last sysfs file: Modules linked in: snd_soc_jem3(+) snd_soc_imx snd_soc_tlv320aic3204 snd_soc_core snd_pcm snd_timer snd soundcore snd_page_alloc ac97_bus [last unloaded: snd_soc_jem3] CPU: 0 Not tainted (2.6.34-jacques-jem3 #16) PC is at snd_soc_instantiate_cards+0x2c/0x7b4 [snd_soc_core] LR is at 0x0 pc : [<bf0513d8>] lr : [<00000000>] psr: 20000013 sp : c3e33db0 ip : bf05906c fp : bf059074 r10: 00000001 r9 : bf058fd0 r8 : 00000000 r7 : bf07a790 r6 : c3c600a8 r5 : bf072960 r4 : bf059074 r3 : 00000000 r2 : 00000000 r1 : bf072960 r0 : bf059074 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 0005317f Table: a3e44000 DAC: 00000015 Process modprobe (pid: 278, stack limit = 0xc3e32270) Stack: (0xc3e33db0 to 0xc3e34000) 3da0: c3e33dec 00000001 c3c600a8 00000000 3dc0: bf0687c8 00000000 c034f1c8 00000000 c3e32000 c0167c18 c02eee78 c3e33e34 3de0: c3e33e6c c3c0e7a8 00000000 c0275b24 c3c15040 c003a008 c3c15040 000000d0 3e00: c02e2fbc c3e32000 c3eae9c8 c3e85428 c3e33e34 00000008 c034f1dc c3eafac0 3e20: c3eafac0 c3e85428 c3eae9c8 c00f2674 00000000 0000072d c3e33e60 c3eae9c8 3e40: c3e85428 c00f2724 c0355190 00000000 c3eae9c8 bf080790 bf080798 c3c600a8 3e60: 00000000 c3c600b0 00000000 c033ec88 00000000 bf052ed0 c0355190 c3c600a8 3e80: c3e33eb0 bf059020 c0355190 c01ac47c bf059020 c01ab394 c3c600a8 00000000 3ea0: c3e33eb0 c3c600a8 c01ab548 c01aa628 c3c044e8 c3e76ad4 c02de99c c3c600a8 3ec0: c3c600a8 c3c600dc 00000000 c01ab5f4 c3c600a8 c3c600a8 00000000 c01aa5a8 3ee0: 00000000 c01a8c20 bf080870 c3c600b0 c3c600b0 00000000 00000000 c0168c18 3f00: c3c600a8 c3c600a8 c3c600a0 00000000 bf083000 c0021b88 00000000 c034578c 3f20: 000192dc c01acaa0 c3c600a8 bf0809ac fffffff4 bf080780 bf083000 bf083090 3f40: 000020f1 bf080864 c3e32000 c0021374 00000000 00000000 00000000 000020f1 3f60: bf080864 00021388 000020f1 bf080864 00021388 00000000 c0021b88 c3e32000 3f80: 00000000 c006e48c 00000001 00000000 00019738 0000cf60 000190b0 00019330 3fa0: 00000080 c00219e0 0000cf60 000190b0 00021388 000020f1 00019370 00019370 3fc0: 0000cf60 000190b0 00019330 00000080 00000000 bec39994 00000000 000192dc 3fe0: 000192d0 bec39524 0000bc98 4010ab44 60000010 00021388 00ffff00 00ffff00 [<bf0513d8>] (snd_soc_instantiate_cards+0x2c/0x7b4 [snd_soc_core]) from [<bf052ed0>] (soc_probe+0x74/0xb0 [snd_soc_core]) [<bf052ed0>] (soc_probe+0x74/0xb0 [snd_soc_core]) from [<c01ac47c>] (platform_drv_probe+0x1c/0x24) [<c01ac47c>] (platform_drv_probe+0x1c/0x24) from [<c01ab394>] (driver_probe_device+0x88/0x180) [<c01ab394>] (driver_probe_device+0x88/0x180) from [<c01aa628>] (bus_for_each_drv+0x60/0x8c) [<c01aa628>] (bus_for_each_drv+0x60/0x8c) from [<c01ab5f4>] (device_attach+0x5c/0x74) [<c01ab5f4>] (device_attach+0x5c/0x74) from [<c01aa5a8>] (bus_probe_device+0x30/0x50) [<c01aa5a8>] (bus_probe_device+0x30/0x50) from [<c01a8c20>] (device_add+0x1f4/0x4c0) [<c01a8c20>] (device_add+0x1f4/0x4c0) from [<c01acaa0>] (platform_device_add+0xf0/0x194) [<c01acaa0>] (platform_device_add+0xf0/0x194) from [<bf083090>] (jem3_soc_init+0x90/0x110 [snd_soc_jem3]) [<bf083090>] (jem3_soc_init+0x90/0x110 [snd_soc_jem3]) from [<c0021374>] (do_one_initcall+0x2c/0x1a8) [<c0021374>] (do_one_initcall+0x2c/0x1a8) from [<c006e48c>] (sys_init_module+0xc4/0x1f8) [<c006e48c>] (sys_init_module+0xc4/0x1f8) from [<c00219e0>] (ret_fast_syscall+0x0/0x2c) Code: e1530002 0a000021 e597203c e5973010 (e5922008) ---[ end trace 2b2b9768e2c2da90 ]--- The address mentioned there makes me think there's an uninitialised pointer to a struct somewhere... but I've never been able to figure out which one. If I reboot, and try to make it oops like before by loading the CODEC driver then machine driver, everything is serine as one would expect: 192 / # modprobe snd-soc-tlv320aic3204 aic3204_i2c_init: adding driver at bf068f9c aic3204_i2c_init: i2c_add_driver(bf068f9c) = 0 192 / # modprobe snd-soc-jem3 jem3_soc_init: hello... jem3_soc_init: jem3_snd_device = c3dbb2a0 jem3_soc_init: calling platform_set_drvdata( c3dbb2a0, bf07a780 ) jem3_soc_init: calling platform_device_add(c3dbb2a0) jem3_soc_init: platform_device_add(c3dbb2a0) = 0 jem3_soc_init = 0 (success) ...but very quiet... 192 / # mount /proc 192 / # cat /proc/asound/cards --- no soundcards --- Queries: - I notice in old drivers, the I²C chip address of the CODEC could be passed in via the same means that is used here for GPIO configuration. How is this done now? Or how do I tell the kernel to only look at address 0x18? - Despite duplicating what I can see being done in other drivers, I still don't see a sound device created. What am I missing to make an audio device appear? - How does one determine what line foo_bar+0x12/0x34 refers to? As you can tell, I'm a newcomer to kernel hacking, so my appologies if these have been answered elsewhere... I've spent many days looking and haven't stumbled upon the answers as yet, hence why I ask here. Thanks in advance. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) .'''. Gentoo Linux/MIPS Cobalt and Docs Developer '.'` : . . . . . . . . . . . . . . . . . . . . . . .'.' http://dev.gentoo.org/~redhatter :.' I haven't lost my mind... ...it's backed up on a tape somewhere.

5 19

Re: [alsa-devel] UAC2 sound-unstable kernel and SDR-widget
by Daniel Mack 03 Jun '10

03 Jun '10

Hi, On Thu, Jun 03, 2010 at 06:41:24AM +0800, Alex Lee wrote: > On 03-Jun-2010, at 1:17 AM, Ken McGuire <kenm(a)paonia.com> wrote: > > >Hi Alex, > >Well said. You might also send a copy to: > >Daniel Mack <daniel(a)caiaq.de> > >since I think he is the source of the current patches. Just out of interest - where did you send that email to? I can't see any such message on the ALSA or LKML mailing lists. > >>We are a group of amateur radio enthusiasts who are developing > >>an open > >>source "sound card" for Software Defined Radio (SDR) applications. > >> > >>The project is called SDR-widget, and you can find more details in: > >> > >>http://code.google.com/p/sdr-widget/ > >> > >>We also have a google group for the sdr-widget developers, and I have > >>just sent you an invitation to join the group. > >> > >>The sdr-widget is a USB sound card based on the AK5394A ADC and a > >>companion AK DAC, controlled by an AT32UC3A3 uProcessor. We already > >>have a prototype working. > >> > >>We have a version of the firmware running with UAC1, at 96khz 24bit > >>mono, and 48khz 24 bit stereo capture. The widget works under Linux > >>and Windows with this firmware. It enumerates as a composite high > >>speed USB device with 4 interfaces: CDC, HID, custom DG8SAQ, and > >>Audio. Wow, interesting project. Thanks for letting us know. > >>We are now working on a version of the firmware with UAC2. Cool. Luckily, as the specs for this standard are freely available, you shouldn't have much problems doing that. From my experience, it's alsmost completely straight forward. > >>We have recently managed to demonstrate 96khz 24bit stereo capture > >>using Ubuntu 10.04 LTS, with kernel 2.6.34-4 and alsa 1.0.23. We are > >>shooting for 192khz 24 bit stereo full duplex eventually. > >> > >>We are now trying to get the sdr-widget running under kernel > >>2.6.35-rc1 with your latest usb-audio updates. That's very good to hear. My current problem is that I can only test the driver with prototypes we made ourselves, and from reading the specs. So more tester's feedback is certainly appreciated. > >>We feel that this is an opportunity for us to work closely, as both > >>the sound-unstable kernel development and the sdr-widget development > >>are actively being pursued, and both are open source projects. This > >>will allow us to make sure both our projects become fully compliant > >>with the UAC2 specs. Agreed. > >>For example, one area we are looking at currently is the different > >>interpretations of the UAC2 specs for the CLOCK SELECT descriptor: > >> > >> > >> > >>This is the audio-v2.h version: > >> > >> > >>/* 4.7.2.2 Clock Source Descriptor */ > >> > >> > >>struct uac_clock_selector_descriptor { > >> __u8 bLength; > >> __u8 bDescriptorType; > >> __u8 bDescriptorSubtype; > >> __u8 bClockID; > >> __u8 bNrInPins; > >> __u8 baCSourceID[]; > >> /* bmControls, bAssocTerminal and iClockSource omitted */ > >> > >> > >>} __attribute__((packed)); > >> > >> > >>baCSourceID is a array of U8. > >> > >> > >>Whereas widget firmware uses this: > >> > >> > >>//! Clock Selector descriptor pp 4.7.2.2 WARNING this descriptor > >>complies with > >>//! the alsa 1.0.23 usb_audio_v2_compat.h which is different from pp. > >>4.7.2.2 > >>typedef > >>#if (defined __ICCAVR32__) > >>#pragma pack(1) > >>#endif > >>struct > >>#if (defined __GNUC__) > >>__attribute__((__packed__)) > >>#endif > >>{ > >> U8 bLength; /* Size of this descriptor in bytes */ > >> U8 bDescriptorType; /* CS_INTERFACE descriptor type */ > >> U8 bDescritorSubtype; /* CLOCK_SELECTOR subtype */ > >> U8 bClockID; /* Clock Selector ID */ > >> U8 bNrInPins; /* Number of Input Pins */ > >> U8 baCSourceID1; /* variable length */ > >> U8 baCSourceID2; > >> U8 bmControls; /* Clock selector control > >>bitmap !!! comes after > >>baCSource in the spec!! */ Yeah, I know. I fixed this up already, and Takashi queued the patch in his tree. Sorry about that, but ironically, you quoted the corrected version above already. Our two structs are actually in sync now. And more than that, the wrong version of the struct was in fact never used. The code which started to parse clock selectors was added along with the fix for the struct. > >>So we are now discussing whether we should modify the sdr-widget > >>firmware, or to patch the kernel :-) Oh, we of course need to keep to the specs and implement it properly on both sides. I can't promise this whole UAC2 stack to be bug-free or complete at this point. As I said, it is only tested by prototypes that work well under Mac OS X, too. So that's at least some kind of evidence :) Just let me know whether you encounter any kind of bug in the driver stack. Patches are very welcome :) Thanks, Daniel

1 0

Re: [alsa-devel] Crash 2.6.32.x, Echo 3G, Alsa, SCSI
by Clemens Ladisch 03 Jun '10

03 Jun '10

Frederick V Heitkamp wrote: > Repeatable Hard Crash. > What else do I need to provide? > > [ 5484.995249] WriteControlReg: not written, no change > [ 5485.069621] divide error: 0000 [#1] pcm_hw_params ok > [ 5485.070159] Prepare rate=44100 format=2 channels=2 > [ 5485.070161] set_audio_format[14] = 5 > [ 5485.070166] Prepare rate=44100 format=2 channels=2 > [ 5485.070167] set_audio_format[14] = 5 > [ 5485.070003] PREEMPT SMP > ... > [ 5485.070003] EIP is at pcm_pointer+0x37/0x70 [snd_echo3g] > ... > [ 5485.965788] [<c10041c0>] ? do_divide_error+0x0/0x90 > [ 5485.980619] [<f87aa037>] ? pcm_pointer+0x37/0x70 [snd_echo3g] > [ 5485.998047] [<c104764e>] ? run_timer_softirq+0x17e/0x2e0 > [ 5486.014175] [<f87ac9bf>] ? snd_echo_interrupt+0x11f/0x240 [snd_echo3g] > [ 5486.033940] [<c107a5d5>] ? handle_IRQ_event+0x45/0x190 bytes_to_frames() divides by runtime->frame_bits which is not set until after the hw_params callback has succeeded, but the corresponding chip->substream[] entry is set in that callback, by init_engine(). It should probably have been set in the prepare callback. Frederick, please try the patch below. Takashi, is there any reason why the runtime-> fields are initialized after the hw_params callback? Regards, Clemens --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -403,12 +403,6 @@ if (err < 0) goto _error; - if (substream->ops->hw_params != NULL) { - err = substream->ops->hw_params(substream, params); - if (err < 0) - goto _error; - } - runtime->access = params_access(params); runtime->format = params_format(params); runtime->subformat = params_subformat(params); @@ -446,6 +440,13 @@ runtime->boundary *= 2; snd_pcm_timer_resolution_change(substream); + + if (substream->ops->hw_params != NULL) { + err = substream->ops->hw_params(substream, params); + if (err < 0) + goto _error; + } + runtime->status->state = SNDRV_PCM_STATE_SETUP; pm_qos_remove_requirement(PM_QOS_CPU_DMA_LATENCY,

6 10

[alsa-devel] Trouble compiling alsa-driver-1.0.23 on Fedora 13
by Uros Bizjak 02 Jun '10

02 Jun '10

Hello! Trying to compile alsa-driver-1.0.23 on Fedora 13, I got following failure: gmake -C /lib/modules/2.6.33.5-112.fc13.x86_64/source SUBDIRS=/home/uros/alsa-driver-1.0.23 CPP="gcc -E" CC="gcc" modules gmake[1]: Entering directory `/usr/src/kernels/2.6.33.5-112.fc13.x86_64' Makefile:535: /usr/src/kernels/2.6.33.5-112.fc13.x86_64/arch//Makefile: No such file or directory gmake[1]: *** No rule to make target `/usr/src/kernels/2.6.33.5-112.fc13.x86_64/arch//Makefile'. Stop. gmake[1]: Leaving directory `/usr/src/kernels/2.6.33.5-112.fc13.x86_64' gmake: *** [compile] Error 2 I have installed required kernel-devel package. Am I missing something else to successfully compile alsa-kernel drivers? Thanks, Uros.

4 5

[PATCH] Ensure codec patch files are checked for the correct codec ID Signed-off-by: David Henningsson <diwic@ubuntu.com>
by David Henningsson 02 Jun '10

02 Jun '10

--- sound/pci/hda/hda_hwdep.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/sound/pci/hda/hda_hwdep.c b/sound/pci/hda/hda_hwdep.c index a1fc837..0e2cb27 100644 --- a/sound/pci/hda/hda_hwdep.c +++ b/sound/pci/hda/hda_hwdep.c @@ -649,7 +649,9 @@ static void parse_codec_mode(char *buf, struct hda_bus *bus, *codecp = NULL; if (sscanf(buf, "%i %i %i", &vendorid, &subid, &caddr) == 3) { list_for_each_entry(codec, &bus->codec_list, list) { - if (codec->addr == caddr) { + if (codec->vendor_id == vendorid && + codec->subsystem_id == subid && + codec->addr == caddr) { *codecp = codec; break; } -- 1.7.0.4 --------------020601030309080805090208--

1 0

[PATCH] Ensure codec patch files are checked for the correct codec ID Signed-off-by: David Henningsson <diwic@ubuntu.com>
by David Henningsson 02 Jun '10

02 Jun '10

--- sound/pci/hda/hda_hwdep.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/sound/pci/hda/hda_hwdep.c b/sound/pci/hda/hda_hwdep.c index a1fc837..0e2cb27 100644 --- a/sound/pci/hda/hda_hwdep.c +++ b/sound/pci/hda/hda_hwdep.c @@ -649,7 +649,9 @@ static void parse_codec_mode(char *buf, struct hda_bus *bus, *codecp = NULL; if (sscanf(buf, "%i %i %i", &vendorid, &subid, &caddr) == 3) { list_for_each_entry(codec, &bus->codec_list, list) { - if (codec->addr == caddr) { + if (codec->vendor_id == vendorid && + codec->subsystem_id == subid && + codec->addr == caddr) { *codecp = codec; break; } -- 1.7.0.4 --------------000400040903050100030008--

1 0