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

[alsa-devel] [Patch v2 1/4] ARM: at91: atmel-ssc: add platform device id table
by Bo Shen 06 Nov '12

06 Nov '12

Add platform device id to check whether the SSC controller support pdc or dam for data transfer If match "at91rm9200_ssc", which support pdc for data transfer If match "at91sam9g45_ssc", which support dma for data transfer Signed-off-by: Bo Shen <voice.shen(a)atmel.com> --- No change between v1 and v2 --- arch/arm/mach-at91/at91rm9200.c | 6 +++--- arch/arm/mach-at91/at91rm9200_devices.c | 6 +++--- arch/arm/mach-at91/at91sam9260.c | 2 +- arch/arm/mach-at91/at91sam9260_devices.c | 2 +- arch/arm/mach-at91/at91sam9261.c | 6 +++--- arch/arm/mach-at91/at91sam9261_devices.c | 6 +++--- arch/arm/mach-at91/at91sam9263.c | 4 ++-- arch/arm/mach-at91/at91sam9263_devices.c | 4 ++-- arch/arm/mach-at91/at91sam9g45.c | 4 ++-- arch/arm/mach-at91/at91sam9g45_devices.c | 4 ++-- arch/arm/mach-at91/at91sam9rl.c | 4 ++-- arch/arm/mach-at91/at91sam9rl_devices.c | 4 ++-- drivers/misc/atmel-ssc.c | 23 +++++++++++++++++++++++ include/linux/atmel-ssc.h | 5 +++++ 14 files changed, 54 insertions(+), 26 deletions(-) diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c index b4f0565..85d53c5 100644 --- a/arch/arm/mach-at91/at91rm9200.c +++ b/arch/arm/mach-at91/at91rm9200.c @@ -184,9 +184,9 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tc3_clk), CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.1", &tc4_clk), CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.1", &tc5_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.2", &ssc2_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.2", &ssc2_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91rm9200", &twi_clk), /* fake hclk clock */ CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &ohci_clk), diff --git a/arch/arm/mach-at91/at91rm9200_devices.c b/arch/arm/mach-at91/at91rm9200_devices.c index a563189..59ceea1 100644 --- a/arch/arm/mach-at91/at91rm9200_devices.c +++ b/arch/arm/mach-at91/at91rm9200_devices.c @@ -752,7 +752,7 @@ static struct resource ssc0_resources[] = { }; static struct platform_device at91rm9200_ssc0_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 0, .dev = { .dma_mask = &ssc0_dmamask, @@ -794,7 +794,7 @@ static struct resource ssc1_resources[] = { }; static struct platform_device at91rm9200_ssc1_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 1, .dev = { .dma_mask = &ssc1_dmamask, @@ -836,7 +836,7 @@ static struct resource ssc2_resources[] = { }; static struct platform_device at91rm9200_ssc2_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 2, .dev = { .dma_mask = &ssc2_dmamask, diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c index ad29f93..2c8aab0 100644 --- a/arch/arm/mach-at91/at91sam9260.c +++ b/arch/arm/mach-at91/at91sam9260.c @@ -210,7 +210,7 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tc3_clk), CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.1", &tc4_clk), CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.1", &tc5_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9260", &twi_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20", &twi_clk), /* more usart lookup table for DT entries */ diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c index 805ef95..9cfdc3f 100644 --- a/arch/arm/mach-at91/at91sam9260_devices.c +++ b/arch/arm/mach-at91/at91sam9260_devices.c @@ -742,7 +742,7 @@ static struct resource ssc_resources[] = { }; static struct platform_device at91sam9260_ssc_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 0, .dev = { .dma_mask = &ssc_dmamask, diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c index 8d999eb..4e8c56e 100644 --- a/arch/arm/mach-at91/at91sam9261.c +++ b/arch/arm/mach-at91/at91sam9261.c @@ -174,9 +174,9 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tc0_clk), CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.0", &tc1_clk), CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.0", &tc2_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.2", &ssc2_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.2", &ssc2_clk), CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &hck0), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9261", &twi_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10", &twi_clk), diff --git a/arch/arm/mach-at91/at91sam9261_devices.c b/arch/arm/mach-at91/at91sam9261_devices.c index 9752f17..299637f 100644 --- a/arch/arm/mach-at91/at91sam9261_devices.c +++ b/arch/arm/mach-at91/at91sam9261_devices.c @@ -706,7 +706,7 @@ static struct resource ssc0_resources[] = { }; static struct platform_device at91sam9261_ssc0_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 0, .dev = { .dma_mask = &ssc0_dmamask, @@ -748,7 +748,7 @@ static struct resource ssc1_resources[] = { }; static struct platform_device at91sam9261_ssc1_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 1, .dev = { .dma_mask = &ssc1_dmamask, @@ -790,7 +790,7 @@ static struct resource ssc2_resources[] = { }; static struct platform_device at91sam9261_ssc2_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 2, .dev = { .dma_mask = &ssc2_dmamask, diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c index 6a01d03..95a5471 100644 --- a/arch/arm/mach-at91/at91sam9263.c +++ b/arch/arm/mach-at91/at91sam9263.c @@ -186,8 +186,8 @@ static struct clk *periph_clocks[] __initdata = { static struct clk_lookup periph_clocks_lookups[] = { /* One additional fake clock for macb_hclk */ CLKDEV_CON_ID("hclk", &macb_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.0", &mmc0_clk), CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.1", &mmc1_clk), CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.0", &spi0_clk), diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c index 8dde220..df89a00 100644 --- a/arch/arm/mach-at91/at91sam9263_devices.c +++ b/arch/arm/mach-at91/at91sam9263_devices.c @@ -1199,7 +1199,7 @@ static struct resource ssc0_resources[] = { }; static struct platform_device at91sam9263_ssc0_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 0, .dev = { .dma_mask = &ssc0_dmamask, @@ -1241,7 +1241,7 @@ static struct resource ssc1_resources[] = { }; static struct platform_device at91sam9263_ssc1_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 1, .dev = { .dma_mask = &ssc1_dmamask, diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c index 84af1b5..f4f96a6 100644 --- a/arch/arm/mach-at91/at91sam9g45.c +++ b/arch/arm/mach-at91/at91sam9g45.c @@ -239,8 +239,8 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tcb0_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10.0", &twi0_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10.1", &twi1_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.0", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.1", &ssc1_clk), CLKDEV_CON_DEV_ID(NULL, "atmel-trng", &trng_clk), CLKDEV_CON_DEV_ID(NULL, "atmel_sha", &aestdessha_clk), CLKDEV_CON_DEV_ID(NULL, "atmel_tdes", &aestdessha_clk), diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c index b159607..27e3bf6 100644 --- a/arch/arm/mach-at91/at91sam9g45_devices.c +++ b/arch/arm/mach-at91/at91sam9g45_devices.c @@ -1459,7 +1459,7 @@ static struct resource ssc0_resources[] = { }; static struct platform_device at91sam9g45_ssc0_device = { - .name = "ssc", + .name = "at91sam9g45_ssc", .id = 0, .dev = { .dma_mask = &ssc0_dmamask, @@ -1501,7 +1501,7 @@ static struct resource ssc1_resources[] = { }; static struct platform_device at91sam9g45_ssc1_device = { - .name = "ssc", + .name = "at91sam9g45_ssc", .id = 1, .dev = { .dma_mask = &ssc1_dmamask, diff --git a/arch/arm/mach-at91/at91sam9rl.c b/arch/arm/mach-at91/at91sam9rl.c index 72e9084..4110b54 100644 --- a/arch/arm/mach-at91/at91sam9rl.c +++ b/arch/arm/mach-at91/at91sam9rl.c @@ -184,8 +184,8 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tc0_clk), CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.0", &tc1_clk), CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.0", &tc2_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20.0", &twi0_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20.1", &twi1_clk), CLKDEV_CON_ID("pioA", &pioA_clk), diff --git a/arch/arm/mach-at91/at91sam9rl_devices.c b/arch/arm/mach-at91/at91sam9rl_devices.c index d6ca054..01220c7 100644 --- a/arch/arm/mach-at91/at91sam9rl_devices.c +++ b/arch/arm/mach-at91/at91sam9rl_devices.c @@ -832,7 +832,7 @@ static struct resource ssc0_resources[] = { }; static struct platform_device at91sam9rl_ssc0_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 0, .dev = { .dma_mask = &ssc0_dmamask, @@ -874,7 +874,7 @@ static struct resource ssc1_resources[] = { }; static struct platform_device at91sam9rl_ssc1_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 1, .dev = { .dma_mask = &ssc1_dmamask, diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c index ac00f83..f40abd8 100644 --- a/drivers/misc/atmel-ssc.c +++ b/drivers/misc/atmel-ssc.c @@ -68,6 +68,26 @@ void ssc_free(struct ssc_device *ssc) } EXPORT_SYMBOL(ssc_free); +static struct atmel_ssc_platform_data at91rm9200_config = { + .use_dma = 0, +}; + +static struct atmel_ssc_platform_data at91sam9g45_config = { + .use_dma = 1, +}; + +static const struct platform_device_id atmel_ssc_devtypes[] = { + { + .name = "at91rm9200_ssc", + .driver_data = (unsigned long) &at91rm9200_config, + }, { + .name = "at91sam9g45_ssc", + .driver_data = (unsigned long) &at91sam9g45_config, + }, { + /* sentinel */ + } +}; + static int ssc_probe(struct platform_device *pdev) { struct resource *regs; @@ -80,6 +100,8 @@ static int ssc_probe(struct platform_device *pdev) } ssc->pdev = pdev; + ssc->pdata = (struct atmel_ssc_platform_data *) + platform_get_device_id(pdev)->driver_data; regs = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!regs) { @@ -139,6 +161,7 @@ static struct platform_driver ssc_driver = { .name = "ssc", .owner = THIS_MODULE, }, + .id_table = atmel_ssc_devtypes, .probe = ssc_probe, .remove = __devexit_p(ssc_remove), }; diff --git a/include/linux/atmel-ssc.h b/include/linux/atmel-ssc.h index 4eb3175..1ca0e32 100644 --- a/include/linux/atmel-ssc.h +++ b/include/linux/atmel-ssc.h @@ -5,10 +5,15 @@ #include <linux/list.h> #include <linux/io.h> +struct atmel_ssc_platform_data { + int use_dma; +}; + struct ssc_device { struct list_head list; void __iomem *regs; struct platform_device *pdev; + struct atmel_ssc_platform_data *pdata; struct clk *clk; int user; int irq; -- 1.7.9.5

3 13

[alsa-devel] [PATCH] ASoC: codecs/wm8978: pll incorrectly configured when codec is master
by Eric Millbrandt 06 Nov '12

06 Nov '12

When MCLK is supplied externally and BCLK and LRC are configured as outputs (codec is master), the PLL values are only calculated correctly on the first transmission. On subsequent transmissions, at differenct sample rates, the wrong PLL values are used. Test for f_opclk instead of f_pllout to determine if the PLL values are needed. Signed-off-by: Eric Millbrandt <emillbrandt(a)dekaresearch.com> --- sound/soc/codecs/wm8978.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/wm8978.c b/sound/soc/codecs/wm8978.c index a706262..e329187 100644 --- a/sound/soc/codecs/wm8978.c +++ b/sound/soc/codecs/wm8978.c @@ -784,7 +784,7 @@ static int wm8978_hw_params(struct snd_pcm_substream *substream, wm8978->mclk_idx = -1; f_sel = wm8978->f_mclk; } else { - if (!wm8978->f_pllout) { + if (!wm8978->f_opclk) { /* We only enter here, if OPCLK is not used */ int ret = wm8978_configure_pll(codec); if (ret < 0) -- 1.7.2.5

2 1

Re: [alsa-devel] [PATCH 1/2] ASoC: Ux500: Fixup use of clocks
by Mark Brown 06 Nov '12

06 Nov '12

On Mon, Nov 05, 2012 at 03:27:08PM +0100, Ulf Hansson wrote: > I can not find this patch on any "next-tree" yet. Same goes for: > "[PATCH 2/2] ASoC: Ux500: Control apb clock". > Maybe I should be more patient, but thought it make sense to send a > ping on this. :-) As I've had to tell you before pings are pointless, don't do this - to repeat, if you think something has been missed resend it.

1 0

Re: [alsa-devel] [PATCH] ASoC: wm0010: Only output debug status message on status change.
by Mark Brown 06 Nov '12

06 Nov '12

On Mon, Nov 05, 2012 at 02:45:12PM +0000, Scott Ling wrote: > Rather than outputting the debug status message for every status > received from the DSP, only output a message when the status > changes. This doesn't apply against -next, please check what's going on there.

1 0

Re: [alsa-devel] [PATCH] ASoC: wm0010: Remove boot_done variable as no longer required.
by Mark Brown 06 Nov '12

06 Nov '12

On Mon, Nov 05, 2012 at 02:44:25PM +0000, Scott Ling wrote: > Remove the boot_done counter variable and check the wm0010 state > variable instead. Applied, thanks.

1 0

[alsa-devel] [FT C400,v2,RFC 0/8] M-Audio Fast Track C400
by Eldad Zack 06 Nov '12

06 Nov '12

Hi, The following patches adds support for the M-Audio Fast Track C400. I recently bought this device and I was able to get this work thanks to the discussion on the alsa-devel list.[1] Thanks everyone! This series applies against the latest mainline tree, 3.7-rc4 (HEAD 3d70f8c617a436c7146ecb81df2265b4626dfe89 ) This is v2 of the series. It adds patches #3 and #8. * First of all, everything works: mixer controls, effects control, playback and capture (with the correct sampling frequency set). Note that the device doesn't really have a master control or left/right pan. It's just "emulated" in the software. * Audio in/out seems to work good in v2, mainly because the playback is an implicit feedback endpoint, and it is now configured with the capture endpoint as its sync-buddy (patch #8). * Also needed to correct the calculation for implicit feedback, because of the different channel numbers between the two endpoints on the C400 (6 playback - implicit feedback, 4 capture) (patch #3). * The clock sources are still named "Unit 129" (0x81, internal) and "Unit 130" (0x82, SPDIF). I'll fix this later. I also plan to fix the channel names (i.e., instead of "AIn3", use "SPDIF In L"). * I've touched one FTU mixer creation function. I'd appreciate if someone can test this with the FTU to make sure I didn't break something. * Patches #6 and #7 are not ready to go in. Patch #6 employs a crude hack and misuses cmask. Patch #7 follows suit. I'd appreciate some hints on how to do this properly. (It's theoretically possible to use cmask properly, but cmasks must be a 64 bits type, because we have 10 input * 6 output = 60 paths). Grant, I mentioned just now that I get distorted playback. This was caused by me using an lower bandwidth altsetting (2), which I tried since it gives only 2 playback channels, figuring it might help latency somehow. I now reverted back to the original alsetting (1) and I seem to get a stable latency and I can't hear anything unusual (yet?). jack_delay seems to be happy as well. Cheers, Eldad Cc: Grant Diffey <gdiffey(a)gmail.com> Cc: Chris Cavey <chris-alsa(a)rauros.net> Signed-off-by: Eldad Zack <eldad(a)fogrefinery.com> Eldad Zack (8): usb-audio: skip UAC2 EFFECT_UNIT usb-audio: parameterize FTU effect unit control usb-audio: use sender stride for implicit feedback usb-audio: M-Audio Fast Track C400 quirks table usb-audio: Fast Track C400 mixer ranges usb-audio: Fast Track C400 mixer quirks usb-audio: add remaining C400 controls usb-audio: FT C400 sync playback EP to capture EP sound/usb/endpoint.c | 9 ++- sound/usb/mixer.c | 55 +++++++++++++- sound/usb/mixer_quirks.c | 196 ++++++++++++++++++++++++++++++++++++++++++++-- sound/usb/pcm.c | 13 +++ sound/usb/quirks-table.h | 71 +++++++++++++++++ 5 files changed, 332 insertions(+), 12 deletions(-) -- 1.7.8.6

1 8

Re: [alsa-devel] [Alsa-user] Ticks when playing to USB DAC at high sample rates
by Daniel Mack 06 Nov '12

06 Nov '12

On 05.11.2012 23:29, Jeffrey Barish wrote: > On Mon 05 November 2012 16:03:00 Daniel Mack wrote: >> Hi Jeff, >> >> On 05.11.2012 02:53, Jeffrey Barish wrote: >>> On Sun 04 November 2012 11:39:48 Daniel Mack wrote: >>>> [cc alsa-devel] >>>> >>>> On 04.11.2012 02:25, Jeffrey Barish wrote: >>>>> On Fri 26 October 2012 15:21:06 Jeffrey Barish wrote: >>>>>> On Fri 26 October 2012 21:47:05 Daniel Mack wrote: >>>>>>> On 26.10.2012 21:43, Jeffrey Barish wrote: >>>>>>>> On Thu 25 October 2012 19:10:45 Daniel Mack wrote: >>>>>>>>> On 25.10.2012 17:18, Jeffrey Barish wrote: >>>>>>>>>> I found something in the snd_usb_audio code (in endpoint.c) that >>>>>>>>>> could >>>>>>>>>> explain one of the problems I have observed (the ticks). I would >>>>>>>>>> normally test my theory by modifying the code. In this case, I >>>>>>>>>> would >>>>>>>>>> like to stick in a print statement to see what values are being >>>>>>>>>> assigned >>>>>>>>>> to certain variables. Unfortunately, I am too ignorant to do >>>>>>>>>> something >>>>>>>>>> even this trivial as I have never worked on kernel code. I think I >>>>>>>>>> am >>>>>>>>>> supposed to use printk, >>>>>>>>> >>>>>>>>> printk is nice for simple debugging, yes. But note that this call is >>>>>>>>> timing critical and should not be used in "fast path" code. >>>>>>>>> Introducing >>>>>>>>> a printk for each received packet for example will almost certainly >>>>>>>>> make >>>>>>>>> the driver behave quite differently. >>>>>>>>> >>>>>>>>>> but beyond that I am lost. Can someone provide >>>>>>>>>> me with some directions? I need to know how to make the driver. To >>>>>>>>>> that >>>>>>>>>> end, I probably will have to install additional packages. After >>>>>>>>>> making >>>>>>>>>> the driver, I need to know how to install it over the existing >>>>>>>>>> driver. >>>>>>>>> >>>>>>>>> Here's one way to do it: >>>>>>>>> >>>>>>>>> 1. git clone >>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git (your >>>>>>>>> patch should apply on top of this tree eventually) >>>>>>>>> 2. cd sound >>>>>>>>> 3. zcat /proc/config.gz >.config >>>>>>>>> 4. build and install the kernel image. How that is done depends on >>>>>>>>> the >>>>>>>>> distribution you're using. For Ubuntu follow the docs at [1] (start >>>>>>>>> at >>>>>>>>> point #5). For Fedora and others, something like "make && make >>>>>>>>> install" >>>>>>>>> should do >>>>>>>>> 5. reboot and check that the new kernel is running >>>>>>>>> 6. hack on sound/usb >>>>>>>>> 7. make M=sound/usb >>>>>>>>> 8. reload the module with "sudo rmmod snd_usb_audio; sudo insmod >>>>>>>>> sound/usb/snd-usb-audio.ko" (better plug out the device before so >>>>>>>>> you >>>>>>>>> always have the same defined point of start) >>>>>>>>> >>>>>>>>> >>>>>>>>> Hope that works for you. >>>>>>>>> >>>>>>>>> >>>>>>>>> Daniel >>>>>>>>> >>>>>>>>> [1] https://wiki.ubuntu.com/KernelTeam/GitKernelBuild >>>>>>>> >>>>>>>> Your directions were almost perfect, so even I was able to build the >>>>>>>> kernel. I made a discovery using the new kernel that might help >>>>>>>> someone >>>>>>>> more familiar with the code than I am to localize the problem. I am >>>>>>>> still hearing the blip when I play audio sampled at 88.2 kHz, but I >>>>>>>> just >>>>>>>> noticed that the blip is perfectly periodic, with a period of about >>>>>>>> 16.4 >>>>>>>> seconds. I am playing a sine wave synthesized using GStreamer using >>>>>>>> the >>>>>>>> following command: >>>>>>>> >>>>>>>> gst-launch audiotestsrc volume=0.01 ! audio/x-raw-float, width=64, >>>>>>>> rate=88200, channels=2, endianness=1234 ! audioconvert ! alsasink >>>>>>>> >>>>>>>> A sine wave makes it easier to hear the blip. Does this clue suggest >>>>>>>> anything? >>>>>>>> >>>>>>>> I also want to mention that when I use the new kernel, I do not get >>>>>>>> the >>>>>>>> ticks at either 88.2 or 96 kHz even when I do not use the external >>>>>>>> USB >>>>>>>> hub. I plan next to back up to the 3.6.2 kernel to see whether I >>>>>>>> still >>>>>>>> get ticks there. >>>>>>> >>>>>>> Which kernel did you use when you heard the 'blibs'? >>>>>> >>>>>> The latest news is bad. I am on 3.2.0 now. The USB DAC is working >>>>>> perfectly at this moment at both 96 kHz and 88.2 kHz without the >>>>>> external >>>>>> USB hub (imagine calling that bad news). If I set the srate to 88.2 >>>>>> kHz >>>>>> and stop and start the sine wave, sometimes I get the blip. Forget >>>>>> about >>>>>> its being periodic. It was definitely periodic before lunch; now I >>>>>> usually >>>>>> get random intervals if I get any blips at all. As I am typing this >>>>>> message, I can't get blips at all. There was some correlation between >>>>>> changing sample rates and blips, but I can't reproduce that behavior >>>>>> now. >>>>>> What is most weird is that I haven't gotten any ticks since lunch with >>>>>> any >>>>>> kernel or with either sample rate, yet they were reliable earlier today >>>>>> unless I used the external USB hub. I obviously need to experiment some >>>>>> more to see whether I can observe a pattern. >>>>> >>>>> To conclude (?) this thread, I am now convinced that the anomalies I >>>>> observed were unrelated to the device driver. I had two theories >>>>> remaining. One was that the problem was somehow related to an >>>>> overheating problem. I used a heat gun to convince myself that the >>>>> theory was wrong. The other was that the problem had something to do >>>>> with services running in the background that interfered with the device >>>>> driver. I removed or disabled all services that I could identify as >>>>> superfluous. Removed services include zeitgeist, apparmor, >>>>> modemmanager, >>>>> mdadm, and bluetooth. Disabled services include atd, dns-clean, and >>>>> pppd-dns. The system has been running perfectly with an 88.2 kHz sample >>>>> rate and no external USB hub for 2 days. However, I tried booting the >>>>> system with a copy of the OS from before I removed superfluous services. >>>>> It still ran perfectly. Thus, I cannot convince myself that removing >>>>> superfluous services actually solved the problem. I suppose it's >>>>> possible that some service was running sporadically, which could explain >>>>> why the problem seemed to come and go and also why the problem did not >>>>> occur when I booted the copy of the OS. As long as the problem remains >>>>> dormant I have no alternative but to move on and see whether the problem >>>>> eventually recurs. Only time will tell. >>>>> >>>>> Thanks for all the help. Hey, I built a kernel and got my own version >>>>> of >>>>> the device driver to run. That was exciting. >>>>> >>>>> ------------------------------------------------------------------------ >>>>> -- >>>>> ---- >>>>> >>>>> I'm back. The USB DAC continued to work for two more days after my last >>>>> message and then the blips resumed. I've been digging into the driver >>>>> code >>>>> for two days. I spent today trying to convince myself that the driver >>>>> is >>>>> actually using an asynchronous protocol. The blips are almost certainly >>>>> buffer underruns, which I could account for if the driver were not >>>>> responding to asynchronous feedback from the DAC. I expected to see a >>>>> deviation from the pattern of one frame with 89 samples followed by 4 >>>>> frames with 88 (which results in 88,200 samples per second). That >>>>> sequence would work perfectly if the clocks in the computer and in the >>>>> USB DAC were exactly the same frequency, but of course they are not. >>>>> Consequently, I would expect to see requests for one sample more or less >>>>> once in a while, depending on whether the clock in the computer is >>>>> slower >>>>> or faster than the one in the DAC. What I see is 89 + 4 * 88 almost all >>>>> the time, as expected . Once in a while there is a request for an >>>>> additional frame of 88 and then the pattern of 89 + 4 * 88 resumes. I >>>>> presume that the break in the usual pattern indicates that the device >>>>> driver is responding to a request from the DAC for fewer samples, which >>>>> confirms that the driver is using the asynchronous protocol. That's >>>>> good, if I am right. However, sticking in an extra packet of only 88 >>>>> would be the expected deviation if the host were getting a little ahead >>>>> of the DAC, yet the blip is almost certainly a buffer underrun, which >>>>> means that the host is actually falling behind. Thus, an extra packet >>>>> of >>>>> 89 would make more sense. I should also mention that there is no >>>>> correlation between the timing of the extra packet of 88 and the audible >>>>> blip. Something seems wrong here, but I'm not sure where to go next. >>>>> >>>>> On a related topic, to confirm that the blip is a buffer underrun, I >>>>> would >>>>> like to synthesize a waveform that is DC. With DC, an overrun would not >>>>> produce any audible anomalies whereas an underrun would be audible. I >>>>> am >>>>> using GStreamer to synthesize the test waveform. Does anyone know of a >>>>> way to synthesize a DC waveform using GStreamer? If not, is there any >>>>> other tool available in Linux? >>>>> >>>>> By the way, I bought another USB DAC from a different manufacturer to be >>>>> sure that the anomalies I am observing were not due to a defect in the >>>>> DAC. They both display the same problem. >>>>> >>>>> ----------------------------------------------------- >>>>> >>>>> I modified the device driver to output a constant instead of the >>>>> incoming >>>>> waveform. I get blips, as I expected, so I am now certain that the >>>>> blips >>>>> are caused by a buffer underrun. The blips occur periodically again -- >>>>> period of about 16.5 seconds. I presume that the period is related to >>>>> the difference in clock rates between the host and DAC. Roughly every >>>>> 3-4 blips, I get an extra packet of 88 samples. To prevent buffer >>>>> underrun, I ought to be getting an extra packet of 89 samples every 16.5 >>>>> seconds, but I never do. >>>> >>>> Thanks for all your investigation on this! Sending computed data instead >>>> of the payload delivered by the ALSA stack is in fact a very good way to >>>> isolate the issue. >>>> >>>> The question is: if the algorithm in the USB driver miscalculates the >>>> number of samples to send over time, what't the reason for that? Does >>>> the device report bogus values or is there this a bug in the driver? >>> >>> Well, I have two DACs, each from a different manufacturer. Both >>> experience >>> underruns (though not at the same rate). It's possible that they are both >>> reporting bogus values, but unlikely, so I'm leaning toward the bug >>> theory. >>> >>>> Did you read chapter 5.4.12.1 of the USB2.0 spec, and can you explain >>>> where you suspect the bug to be? The current implementation in the >>>> driver is quite straight forward, mapping all feedback values to Q16.16 >>>> and keeping the lower 16bits around for phase compensation between the >>>> calculation of the packet sizes. >>> >>> Do you perhaps mean chapter 5.12.4.1 (Synchronization Type)? I'm not >>> finding a 5.4.12.1 in usb_20.pdf from a zip dated 102512. >> >> Yes, sorry. >> >>> Please tell me whether I have this right: >>> >>> You start transferring the sound in snd_usb_endpoint_start using >>> usb_submit_urb to submit 2 urbs to the USB core. The urbs specify that on >>> completion, the USB core should call snd_complete_urb. snd_complete_urb >>> resubmits the urb after calling retire_playback_urb (by way of >>> retire_outbound_urb which calls retire_data_urb which is >>> retire_playback_urb), which updates its estimate of delay (what's that? >>> It seems to be 0 always) >> That's just an information that is passed to userspace for latency >> compensation matters. As you don't stream data that ALSA passes up the >> stack anymore in your tests (but static data), you can ignore this >> detail for now. >> >>> and prepare_playback_urb (by way of prepare_outbound_urb which calls >>> prepare_data_urb which is prepare_playback_urb), which fills the >>> transfer_buffer in the urb with the audio data (from a DMA buffer, I >>> guess). >>> >>> Before filling transfer_buffer, prepare_playback_urb calls >>> snd_usb_endpoint_next_packet_size to compute the number of samples to >>> send. >>> This code appears to be the crux of what I need to understand because the >>> value returned from this function is what is supposed to adjust to prevent >>> buffer underruns. >> >> That's correct. >> >>> It isn't clear to me how this function gets information >>> about the state of the buffer in the device. >> >> Via the callback of the feedback data endpoint - the momentary frequency >> is updated there and referred to again in >> snd_usb_endpoint_next_packet_size(). >> >>> The only argument to >>> snd_usb_endpoint_next_packet_size is ep, which is a pointer to the >>> snd_usb_endpoint structure. >> >> Yes, the endpoint structure hold all runtime streaming details. Once a >> sync urb is given back from the host controller, retire_inbound_urb() is >> called and snd_usb_handle_sync_urb() cares for updating the momentary >> frequency of the slave of the sync endpoint, which is the data endpoint >> that is later on used by next_packet_size(). Makes sense? >> >>> I see that ep->phase is the Q16.16 value you >>> mentioned, so the lower 16 bits are for "phase compensation between the >>> calculation of the packet sizes". I don't completely understand that >>> phrase. freqm is an unchanging value (5780275) >> >> freqm shouldn't be unchanging. Are you sure it really is? If so, is >> snd_usb_handle_sync_urb() ever called in your setup? > > Yes. freqm is always 5780275. snd_usb_handle_sync_urb is never called. Ok, we can probably stop debugging here already, because if that function is never called, something's badly wrong. No question the data endpoint will run out of bounds at some point if it doesn't get any usable feedback data. > snd_usb_handle_sync_urb is called from only one place, retire_inbound_urb, so > the latter is never called. I suppose that an inbound urb would never need to > be retired if one were never submitted. Trace whteher usb_submit_urb() is called on the sync endpoint. There must be a reason why the completion routing is never callsed, and that's most probably also the solution of your problem. [..] > Since puzzling over the apparent absence of feedback about the state of the > device, I had an epiphany this morning that such feedback is not necessary. It's always necessary, as two osciallators will drift from each other, no matter what. Without a feedback, there's no way the host can know how many data to send over the wire. > The pattern of payload sizes should not change if the payloads are sent in > response to a request from the device. The device makes this request by > calling snd_complete_urb when it finishes an urb. As the device defines time, > the host is responsible only for having the next urb ready when the device > requests it. Could it be that the missing feedback provides nonessential > information about the state of the device, such as confirmation that the > previous payload was successfully processed? > > I repeated the test with a different DAC. With that DAC it is still the case > that snd_usb_handle_sync_urb is never called. How exactly did you make sure? There's something really wrong if what you describe happens, and we need to find the cause for it. Unless you're dealing with a device that uses one data endpoint as clock source for another data endpoint (which is called an "implicit feedback" mechanism), you need to have a dedicated sync endpoint. Daniel

1 0

[alsa-devel] [FT C400,RFC 0/6] M-Audio Fast Track C400
by Eldad Zack 05 Nov '12

05 Nov '12

Hi, The following patches adds support for the M-Audio Fast Track C400. I recently bought this device and I was able to get this work thanks to the discussion on the alsa-devel list.[1] Thanks everyone! This series applies against the latest mainline tree, 3.7-rc3 (HEAD 0f89a5733a8d28174c7adeb1fdc20ac11439e766 ) * First of all, everything works: mixer controls, effects control, playback and capture (with the correct sampling frequency set). Note that the device doesn't really have a master control or left/right pan. It's just "emulated" in the software. Audio in/out works good (but not good enough yet, see below). Playback and capture at 48KHz as well as 96KHz works fine (if you don't mind an xrun every 2-5 minutes). I've captured with the C400 and played it back on my on-board device and vice versa to make sure it gets the sample rate correctly. * The clock sources are still named "Unit 129" (0x81, internal) and "Unit 130" (0x82, SPDIF). I'll fix this later. I also plan to fix the channel names (i.e., instead of "AIn3", use "SPDIF In L"). * I've touched one FTU mixer creation function. I'd appreciate if someone can test this with the FTU to make sure I didn't break something. * The last two patches are not ready to go in. Patch #5 employs a crude hack and misuses cmask. Patch #6 follows suit. I'd appreciate some hints on how to do this properly. (It's theoretically possible to use cmask properly, but cmasks must be a 64 bits type, because we have 10 input * 6 output = 60 paths). * Somewhat unrelated: I encounter latency issues. I'm not sure if it's just my particular hardware/drivers. I'm getting jack xruns even with very large buffers and low sampling frequency. Jackd is running alone, with almost no system activity (no X). With the USB 2.0 interface (ehci) I have also experienced hard lock-ups after a while (or almost immediately with 96KHz @ 64 bytes * 2 periods). Luckily I have a USB 3.0 interfaces as well (Intel xhci), which doesn't lock-up, but I still get xruns once every 2-5 minutes. (1000HZ kernel, with PREEMPT). Also, xruns are much less frequent when using only capture or only playback. Chris, do you mind testing this and see if (1) it works for you and (2) you see the same latency issues? Thanks for the USB captures, it really saved a lot of work to get this done! Cheers, Eldad Cc: Chris Cavey <chris-alsa(a)rauros.net> Signed-off-by: Eldad Zack <eldad(a)fogrefinery.com> -- Eldad Zack (6): usb-audio: skip UAC2 EFFECT_UNIT usb-audio: parameterize FTU effect unit control usb-audio: M-Audio Fast Track C400 quirks table usb-audio: Fast Track C400 mixer ranges usb-audio: Fast Track C400 mixer quirks usb-audio: add remaining C400 controls sound/usb/mixer.c | 55 +++++++++++++- sound/usb/mixer_quirks.c | 196 ++++++++++++++++++++++++++++++++++++++++++++-- sound/usb/quirks-table.h | 71 +++++++++++++++++ 3 files changed, 313 insertions(+), 9 deletions(-) -- 1.7.8.6

2 8

Re: [alsa-devel] [Alsa-user] Ticks when playing to USB DAC at high sample rates
by Daniel Mack 05 Nov '12

05 Nov '12

Hi Jeff, On 05.11.2012 02:53, Jeffrey Barish wrote: > On Sun 04 November 2012 11:39:48 Daniel Mack wrote: >> [cc alsa-devel] >> >> On 04.11.2012 02:25, Jeffrey Barish wrote: >>> On Fri 26 October 2012 15:21:06 Jeffrey Barish wrote: >>>> On Fri 26 October 2012 21:47:05 Daniel Mack wrote: >>>>> On 26.10.2012 21:43, Jeffrey Barish wrote: >>>>>> On Thu 25 October 2012 19:10:45 Daniel Mack wrote: >>>>>>> On 25.10.2012 17:18, Jeffrey Barish wrote: >>>>>>>> I found something in the snd_usb_audio code (in endpoint.c) that >>>>>>>> could >>>>>>>> explain one of the problems I have observed (the ticks). I would >>>>>>>> normally test my theory by modifying the code. In this case, I would >>>>>>>> like to stick in a print statement to see what values are being >>>>>>>> assigned >>>>>>>> to certain variables. Unfortunately, I am too ignorant to do >>>>>>>> something >>>>>>>> even this trivial as I have never worked on kernel code. I think I am >>>>>>>> supposed to use printk, >>>>>>> >>>>>>> printk is nice for simple debugging, yes. But note that this call is >>>>>>> timing critical and should not be used in "fast path" code. >>>>>>> Introducing >>>>>>> a printk for each received packet for example will almost certainly >>>>>>> make >>>>>>> the driver behave quite differently. >>>>>>> >>>>>>>> but beyond that I am lost. Can someone provide >>>>>>>> me with some directions? I need to know how to make the driver. To >>>>>>>> that >>>>>>>> end, I probably will have to install additional packages. After >>>>>>>> making >>>>>>>> the driver, I need to know how to install it over the existing >>>>>>>> driver. >>>>>>> >>>>>>> Here's one way to do it: >>>>>>> >>>>>>> 1. git clone >>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git (your >>>>>>> patch should apply on top of this tree eventually) >>>>>>> 2. cd sound >>>>>>> 3. zcat /proc/config.gz >.config >>>>>>> 4. build and install the kernel image. How that is done depends on the >>>>>>> distribution you're using. For Ubuntu follow the docs at [1] (start at >>>>>>> point #5). For Fedora and others, something like "make && make >>>>>>> install" >>>>>>> should do >>>>>>> 5. reboot and check that the new kernel is running >>>>>>> 6. hack on sound/usb >>>>>>> 7. make M=sound/usb >>>>>>> 8. reload the module with "sudo rmmod snd_usb_audio; sudo insmod >>>>>>> sound/usb/snd-usb-audio.ko" (better plug out the device before so you >>>>>>> always have the same defined point of start) >>>>>>> >>>>>>> >>>>>>> Hope that works for you. >>>>>>> >>>>>>> >>>>>>> Daniel >>>>>>> >>>>>>> [1] https://wiki.ubuntu.com/KernelTeam/GitKernelBuild >>>>>> >>>>>> Your directions were almost perfect, so even I was able to build the >>>>>> kernel. I made a discovery using the new kernel that might help someone >>>>>> more familiar with the code than I am to localize the problem. I am >>>>>> still hearing the blip when I play audio sampled at 88.2 kHz, but I >>>>>> just >>>>>> noticed that the blip is perfectly periodic, with a period of about >>>>>> 16.4 >>>>>> seconds. I am playing a sine wave synthesized using GStreamer using >>>>>> the >>>>>> following command: >>>>>> >>>>>> gst-launch audiotestsrc volume=0.01 ! audio/x-raw-float, width=64, >>>>>> rate=88200, channels=2, endianness=1234 ! audioconvert ! alsasink >>>>>> >>>>>> A sine wave makes it easier to hear the blip. Does this clue suggest >>>>>> anything? >>>>>> >>>>>> I also want to mention that when I use the new kernel, I do not get the >>>>>> ticks at either 88.2 or 96 kHz even when I do not use the external USB >>>>>> hub. I plan next to back up to the 3.6.2 kernel to see whether I still >>>>>> get ticks there. >>>>> >>>>> Which kernel did you use when you heard the 'blibs'? >>>> >>>> The latest news is bad. I am on 3.2.0 now. The USB DAC is working >>>> perfectly at this moment at both 96 kHz and 88.2 kHz without the external >>>> USB hub (imagine calling that bad news). If I set the srate to 88.2 kHz >>>> and stop and start the sine wave, sometimes I get the blip. Forget about >>>> its being periodic. It was definitely periodic before lunch; now I >>>> usually >>>> get random intervals if I get any blips at all. As I am typing this >>>> message, I can't get blips at all. There was some correlation between >>>> changing sample rates and blips, but I can't reproduce that behavior now. >>>> What is most weird is that I haven't gotten any ticks since lunch with >>>> any >>>> kernel or with either sample rate, yet they were reliable earlier today >>>> unless I used the external USB hub. I obviously need to experiment some >>>> more to see whether I can observe a pattern. >>> >>> To conclude (?) this thread, I am now convinced that the anomalies I >>> observed were unrelated to the device driver. I had two theories >>> remaining. One was that the problem was somehow related to an >>> overheating problem. I used a heat gun to convince myself that the >>> theory was wrong. The other was that the problem had something to do >>> with services running in the background that interfered with the device >>> driver. I removed or disabled all services that I could identify as >>> superfluous. Removed services include zeitgeist, apparmor, modemmanager, >>> mdadm, and bluetooth. Disabled services include atd, dns-clean, and >>> pppd-dns. The system has been running perfectly with an 88.2 kHz sample >>> rate and no external USB hub for 2 days. However, I tried booting the >>> system with a copy of the OS from before I removed superfluous services. >>> It still ran perfectly. Thus, I cannot convince myself that removing >>> superfluous services actually solved the problem. I suppose it's >>> possible that some service was running sporadically, which could explain >>> why the problem seemed to come and go and also why the problem did not >>> occur when I booted the copy of the OS. As long as the problem remains >>> dormant I have no alternative but to move on and see whether the problem >>> eventually recurs. Only time will tell. >>> >>> Thanks for all the help. Hey, I built a kernel and got my own version of >>> the device driver to run. That was exciting. >>> >>> -------------------------------------------------------------------------- >>> ---- >>> >>> I'm back. The USB DAC continued to work for two more days after my last >>> message and then the blips resumed. I've been digging into the driver >>> code >>> for two days. I spent today trying to convince myself that the driver is >>> actually using an asynchronous protocol. The blips are almost certainly >>> buffer underruns, which I could account for if the driver were not >>> responding to asynchronous feedback from the DAC. I expected to see a >>> deviation from the pattern of one frame with 89 samples followed by 4 >>> frames with 88 (which results in 88,200 samples per second). That >>> sequence would work perfectly if the clocks in the computer and in the >>> USB DAC were exactly the same frequency, but of course they are not. >>> Consequently, I would expect to see requests for one sample more or less >>> once in a while, depending on whether the clock in the computer is slower >>> or faster than the one in the DAC. What I see is 89 + 4 * 88 almost all >>> the time, as expected . Once in a while there is a request for an >>> additional frame of 88 and then the pattern of 89 + 4 * 88 resumes. I >>> presume that the break in the usual pattern indicates that the device >>> driver is responding to a request from the DAC for fewer samples, which >>> confirms that the driver is using the asynchronous protocol. That's >>> good, if I am right. However, sticking in an extra packet of only 88 >>> would be the expected deviation if the host were getting a little ahead >>> of the DAC, yet the blip is almost certainly a buffer underrun, which >>> means that the host is actually falling behind. Thus, an extra packet of >>> 89 would make more sense. I should also mention that there is no >>> correlation between the timing of the extra packet of 88 and the audible >>> blip. Something seems wrong here, but I'm not sure where to go next. >>> >>> On a related topic, to confirm that the blip is a buffer underrun, I would >>> like to synthesize a waveform that is DC. With DC, an overrun would not >>> produce any audible anomalies whereas an underrun would be audible. I am >>> using GStreamer to synthesize the test waveform. Does anyone know of a >>> way to synthesize a DC waveform using GStreamer? If not, is there any >>> other tool available in Linux? >>> >>> By the way, I bought another USB DAC from a different manufacturer to be >>> sure that the anomalies I am observing were not due to a defect in the >>> DAC. They both display the same problem. >>> >>> ----------------------------------------------------- >>> >>> I modified the device driver to output a constant instead of the incoming >>> waveform. I get blips, as I expected, so I am now certain that the blips >>> are caused by a buffer underrun. The blips occur periodically again -- >>> period of about 16.5 seconds. I presume that the period is related to >>> the difference in clock rates between the host and DAC. Roughly every >>> 3-4 blips, I get an extra packet of 88 samples. To prevent buffer >>> underrun, I ought to be getting an extra packet of 89 samples every 16.5 >>> seconds, but I never do. >> >> Thanks for all your investigation on this! Sending computed data instead >> of the payload delivered by the ALSA stack is in fact a very good way to >> isolate the issue. >> >> The question is: if the algorithm in the USB driver miscalculates the >> number of samples to send over time, what't the reason for that? Does >> the device report bogus values or is there this a bug in the driver? > > Well, I have two DACs, each from a different manufacturer. Both experience > underruns (though not at the same rate). It's possible that they are both > reporting bogus values, but unlikely, so I'm leaning toward the bug theory. > >> Did you read chapter 5.4.12.1 of the USB2.0 spec, and can you explain >> where you suspect the bug to be? The current implementation in the >> driver is quite straight forward, mapping all feedback values to Q16.16 >> and keeping the lower 16bits around for phase compensation between the >> calculation of the packet sizes. > > Do you perhaps mean chapter 5.12.4.1 (Synchronization Type)? I'm not finding a > 5.4.12.1 in usb_20.pdf from a zip dated 102512. Yes, sorry. > Please tell me whether I have this right: > > You start transferring the sound in snd_usb_endpoint_start using > usb_submit_urb to submit 2 urbs to the USB core. The urbs specify that on > completion, the USB core should call snd_complete_urb. snd_complete_urb > resubmits the urb after calling retire_playback_urb (by way of > retire_outbound_urb which calls retire_data_urb which is retire_playback_urb), > which updates its estimate of delay (what's that? It seems to be 0 always) That's just an information that is passed to userspace for latency compensation matters. As you don't stream data that ALSA passes up the stack anymore in your tests (but static data), you can ignore this detail for now. > and prepare_playback_urb (by way of prepare_outbound_urb which calls > prepare_data_urb which is prepare_playback_urb), which fills the transfer_buffer > in the urb with the audio data (from a DMA buffer, I guess). > > Before filling transfer_buffer, prepare_playback_urb calls > snd_usb_endpoint_next_packet_size to compute the number of samples to send. > This code appears to be the crux of what I need to understand because the > value returned from this function is what is supposed to adjust to prevent > buffer underruns. That's correct. > It isn't clear to me how this function gets information > about the state of the buffer in the device. Via the callback of the feedback data endpoint - the momentary frequency is updated there and referred to again in snd_usb_endpoint_next_packet_size(). > The only argument to > snd_usb_endpoint_next_packet_size is ep, which is a pointer to the > snd_usb_endpoint structure. Yes, the endpoint structure hold all runtime streaming details. Once a sync urb is given back from the host controller, retire_inbound_urb() is called and snd_usb_handle_sync_urb() cares for updating the momentary frequency of the slave of the sync endpoint, which is the data endpoint that is later on used by next_packet_size(). Makes sense? > I see that ep->phase is the Q16.16 value you > mentioned, so the lower 16 bits are for "phase compensation between the > calculation of the packet sizes". I don't completely understand that phrase. > freqm is an unchanging value (5780275) freqm shouldn't be unchanging. Are you sure it really is? If so, is snd_usb_handle_sync_urb() ever called in your setup? > and datainterval is an unchanging value > (0). phase fluctuates in a narrow range (roughly 5792282 to 5832702), but it > is fluctuating only as a consequence of this calculation: we take the bottom 16 > bits of its value and add a fixed value. If I understand this calculation > correctly, I can almost see how it could provide the sequence of packet sizes > (the 89 + 4 * 88 sequence) necessary to produce the correct number of samples > per second, but I don't see how it adjusts that number to the slightly > different concept of time at the device. However, even in that understanding I > am perplexed because I occasionally see an extra packet of 88. The device reports its buffer state by providing feedback information in a perioc manner, as letting the host know about what the device think is its correct data rate is the only way to compensate clock drifts. > Also, I think I understand why you start the transfer with 2 urbs: When the > device finishes with the first urb, the next urb has to be there already to > avoid a period when no urb is present. However, right away an alarm goes off. > When the device finishes processing the first urb, it provides feedback about > the state of the buffer. However, the host cannot respond to this feedback > until after the second urb is processed. Have we convinced ourselves that the > lag doesn't matter? I don't know because I don't understand what happens to > the urb after we send it to the USB core. What do you know about the nature > of the buffering in the device? Is there a place for the USB hardware to store > the contents of transfer_buffer independently of a buffer that feeds the actual > DAC? When does the USB hardware transfer the second urb to the device? Isochronous transfers are scheduled on the bus and sent in the configured time slot (or as soon as possible, if the ASAP flag is set). Data payload should be distributed as evenly as possible over the microframes to not blast the device's internal buffers due to bursts. > Who > tells the DAC to start playing the contents of the buffer? Ususally, once it has its buffers filled with data. > I would like to > hear that the device has a FIFO whose size is sufficient to hold the contents of > at least two transfer_buffers. The first two urbs would fill it before > activating the DAC. Every time the DAC finishes outputting the contents of one > urb, it provides feedback with the amount of space remaining in the FIFO. Not quite. It does report the momentary frequency in periodic packets (like every 16ms), not after each packet. > We > would send that many samples in the next urb. I am fantasizing this solution. > Tell me how it really works. It's described in 5.12.4.1 (Synchronization Type). The driver aims to be as close the the actual data rate that is reported by the device every couple of milliseconds. Does that answer your questions? Daniel

1 0

[alsa-devel] Idea: dynamic loading of USB quirks
by maillist＠superlative.org 05 Nov '12

05 Nov '12

Dear Alsa community, I've some minor contributions in the form of patches for USB quirks for devices in the past. It occurred to me that having these USB quirks hardcoded into the driver maybe isn't the best thing. Looking at the current quirks file, the majority of them are relatively trivial and are really just there to give the USB driver a nudge in the right direction. Having to have these hardcoded into the driver creates a number of issues: 1. It needs someone with the expertise and will, and access the specific device for testing, to build the quirk. To hardened ALSA hackers this seems trivial, but to an average end user who has a device they want to get supported, this can be pretty inpenatrable. The complexity of just getting the alsa source installed and set up for compilation is enough to put off the vast majority of users. 2. It makes the process of getting the driver "to market" lengthy as these changes have to go through all of the normal release schedules, and these are pretty opaque. 3. It makes getting changing a driver (because of a bug, or a new release of hardware) difficult as the revisions need to go through the whole process of creating a patch, getting it accepted, and then the long kernel release process, as well as the various distribution release processes. It occured to me that there might be a better way where quirks like this could be dynamically loaded into the driver after it has loaded. This would a structured text file describing the quirk to be created and pushed into the driver. Ultimately this could be wrapped into a framework where quirk files could be put into a common directory (similar to modprobe.d) with a startup script which pushed these into the driver. At the moment I don't have any specific thoughts about how to do this, but I thought it would be useful to elicit ideas from this community. The way I see it it needs: * A structured file format to describe the quirks * A basic method to push these files into the driver at runtime (sysfs?) * Some sort of dynamic data area for the driver to store the data * changes to the driver to accept, store and process these data structures At the moment I just thought I would get people thinking about this and, perhaps, making suggestions about whether it makes sense, whether it's practically achievable within the framework of the kernel and ALSA, and possible methods which might lead to a solution. If I get the time (and, at the moment, that's unlikely for the next 6 months) I'll look at trying to code something up. If anyone else is inspired and feels like having a crack at it, then feel free. All comments and discussion welcome. Cheers, Keith

3 3