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

[alsa-devel] usb: Endpoints sharing the same interface
by Mark Hills 03 Mar '13

03 Mar '13

Novation Twitch [1] is a USB device with audio capture and playback endpoints on the same bInterfaceNumber. This has thrown up some tricky cases in the USB audio driver, and I'd appreciate some advice. I'll follow up with my patches so far as an RFC. This device has endpoints for 2 channels capture (0x01), 4 channels playback (0x82), both on interface #0. Interface #1 is raw MIDI. I seem to be finding code that assumes pcm to always use the first endpoint on an interface. eg. problems with maxpacksize (see patch in thread) Now I'm in a position where playback _or_ capture works reliably. But to start capture stops playback, and vice-versa (or sometimes causes hangs) It seems like snd_pcm_prepare() concludes that need_setup_ep is required, but I think this may be based on something going on in set_sample_rate_v1() also looking to the first endpoint -- usb_sndctrlpipe(dev,0). Before I do any more work on this, are there any hints where to go with this? If we can overcome thse limitations then the same would likely apply to Saffire 6 USB and other Focusrite devices [2], and maybe some of the other devices with quirks that only support playback. Many thanks [1] http://uk.novationmusic.com/digital-dj/twitch/ [2] http://focusritedevelopmentteam.wordpress.com/category/drivers/ -- Mark --- Bus 005 Device 010: ID 1235:0018 Novation EMS Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x1235 Novation EMS idProduct 0x0018 bcdDevice 1.00 iManufacturer 1 Focusrite A.E. Ltd iProduct 2 Twitch iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 64 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 498mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x024c 1x 588 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0126 1x 294 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Device Status: 0x0000 (Bus Powered)

1 4

[alsa-devel] amdtp: syt handling
by Robert von Chamier 03 Mar '13

03 Mar '13

Hello, i am working on the firewire amdtp module. My aim is to add the capture functionality. Already in my prototype the module captures up to 192k sampling rate. But ... How i have to handle the syt in the CIP packages? Do i compare the syt with the corresponding cycle? or ... Do i take the syt as timestamp for alsa? Is it possible to commit a timestamp to alsa for the corresponding samples? Can you help me? Robert

2 1

[alsa-devel] [PATCH] ASoC: max98090: Convert to devm_regmap_init_i2c
by Axel Lin 03 Mar '13

03 Mar '13

Signed-off-by: Axel Lin <axel.lin(a)ingics.com> --- sound/soc/codecs/max98090.c | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c index fc17604..6dd36da 100755 --- a/sound/soc/codecs/max98090.c +++ b/sound/soc/codecs/max98090.c @@ -2324,28 +2324,20 @@ static int max98090_i2c_probe(struct i2c_client *i2c, max98090->pdata = i2c->dev.platform_data; max98090->irq = i2c->irq; - max98090->regmap = regmap_init_i2c(i2c, &max98090_regmap); + max98090->regmap = devm_regmap_init_i2c(i2c, &max98090_regmap); if (IS_ERR(max98090->regmap)) { ret = PTR_ERR(max98090->regmap); dev_err(&i2c->dev, "Failed to allocate regmap: %d\n", ret); - goto err_enable; + return ret; } - ret = snd_soc_register_codec(&i2c->dev, - &soc_codec_dev_max98090, max98090_dai, - ARRAY_SIZE(max98090_dai)); - if (ret < 0) - regmap_exit(max98090->regmap); - -err_enable: - return ret; + return snd_soc_register_codec(&i2c->dev, &soc_codec_dev_max98090, + max98090_dai, ARRAY_SIZE(max98090_dai)); } static int max98090_i2c_remove(struct i2c_client *client) { - struct max98090_priv *max98090 = dev_get_drvdata(&client->dev); snd_soc_unregister_codec(&client->dev); - regmap_exit(max98090->regmap); return 0; } -- 1.7.9.5

2 2

[alsa-devel] [PATCH RFT] ASoC: wm8350: Use jiffies rather than msecs in schedule_delayed_work()
by Axel Lin 03 Mar '13

03 Mar '13

The delay parameter of schedule_delayed_work() is number of jiffies to wait rather than miliseconds. Before commit 6d3c26bcb "ASoC: Use delayed work to debounce WM8350 jack IRQs", the debounce time is 200 miliseconds in wm8350_hp_jack_handler(). So I think this is a bug when convert to use delayed work. Signed-off-by: Axel Lin <axel.lin(a)ingics.com> --- sound/soc/codecs/wm8350.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/wm8350.c b/sound/soc/codecs/wm8350.c index ec0efc1..0e8b3aa 100644 --- a/sound/soc/codecs/wm8350.c +++ b/sound/soc/codecs/wm8350.c @@ -1301,7 +1301,7 @@ static irqreturn_t wm8350_hpl_jack_handler(int irq, void *data) if (device_may_wakeup(wm8350->dev)) pm_wakeup_event(wm8350->dev, 250); - schedule_delayed_work(&priv->hpl.work, 200); + schedule_delayed_work(&priv->hpl.work, msecs_to_jiffies(200)); return IRQ_HANDLED; } @@ -1318,7 +1318,7 @@ static irqreturn_t wm8350_hpr_jack_handler(int irq, void *data) if (device_may_wakeup(wm8350->dev)) pm_wakeup_event(wm8350->dev, 250); - schedule_delayed_work(&priv->hpr.work, 200); + schedule_delayed_work(&priv->hpr.work, msecs_to_jiffies(200)); return IRQ_HANDLED; } -- 1.7.9.5

2 1

[alsa-devel] [PATCH] ASoC: omap: Check regulator enable for DAC on Pandora
by Mark Brown 03 Mar '13

03 Mar '13

This will probably never fail but it's better style. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/omap/omap3pandora.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/sound/soc/omap/omap3pandora.c b/sound/soc/omap/omap3pandora.c index 805512f..953483e 100644 --- a/sound/soc/omap/omap3pandora.c +++ b/sound/soc/omap/omap3pandora.c @@ -85,7 +85,11 @@ static int omap3pandora_dac_event(struct snd_soc_dapm_widget *w, * VCC power on/off and /PD pin high/low */ if (SND_SOC_DAPM_EVENT_ON(event)) { - regulator_enable(omap3pandora_dac_reg); + ret = regulator_enable(omap3pandora_dac_reg); + if (ret != 0) { + dev_err(w->dapm.dev, "Failed to power DAC: %d\n", ret); + return ret; + } mdelay(1); gpio_set_value(OMAP3_PANDORA_DAC_POWER_GPIO, 1); } else { -- 1.7.10.4

3 2

Re: [alsa-devel] [PATCH v2 3/4] spi: s3c64xx: add dma maxburst size initialization
by Grant Likely 02 Mar '13

02 Mar '13

On Fri, 22 Feb 2013 17:09:18 +0900, Boojin Kim <boojin.kim(a)samsung.com> wrote: > This patch adds dma maxburst size initialization. > The maxburst should be set by MODE_CFGn.DMA_TYPE, > because the pl330 dma driver supports burst mode. > > Signed-off-by: Hyeonkook Kim <hk619.kim(a)samsung.com> Acked-by: Grant Likely <grant.likely(a)secretlab.ca> This series probably needs to be merged together through the arm-soc tree. g. > --- > drivers/spi/spi-s3c64xx.c | 18 ++++++++++++++++++ > 1 files changed, 18 insertions(+), 0 deletions(-) > > diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c > index e862ab8..5e6cafe 100644 > --- a/drivers/spi/spi-s3c64xx.c > +++ b/drivers/spi/spi-s3c64xx.c > @@ -287,10 +287,20 @@ static void prepare_dma(struct s3c64xx_spi_dma_data *dma, > struct s3c64xx_spi_driver_data *sdd; > struct samsung_dma_prep info; > struct samsung_dma_config config; > + void __iomem *regs; > + unsigned int mode_cfg; > > if (dma->direction == DMA_DEV_TO_MEM) { > sdd = container_of((void *)dma, > struct s3c64xx_spi_driver_data, rx_dma); > + > + regs = sdd->regs; > + mode_cfg = readl(regs + S3C64XX_SPI_MODE_CFG); > + if (mode_cfg & S3C64XX_SPI_MODE_4BURST) > + config.maxburst = 4; > + else > + config.maxburst = 1; > + > config.direction = sdd->rx_dma.direction; > config.fifo = sdd->sfr_start + S3C64XX_SPI_RX_DATA; > config.width = sdd->cur_bpw / 8; > @@ -298,6 +308,14 @@ static void prepare_dma(struct s3c64xx_spi_dma_data *dma, > } else { > sdd = container_of((void *)dma, > struct s3c64xx_spi_driver_data, tx_dma); > + > + regs = sdd->regs; > + mode_cfg = readl(regs + S3C64XX_SPI_MODE_CFG); > + if (mode_cfg & S3C64XX_SPI_MODE_4BURST) > + config.maxburst = 4; > + else > + config.maxburst = 1; > + > config.direction = sdd->tx_dma.direction; > config.fifo = sdd->sfr_start + S3C64XX_SPI_TX_DATA; > config.width = sdd->cur_bpw / 8; > -- > 1.7.5.4 > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd.

1 0

Re: [alsa-devel] [PATCH v2 3/4] spi: s3c64xx: add dma maxburst size initialization
by Grant Likely 02 Mar '13

02 Mar '13

On Fri, 22 Feb 2013 17:09:18 +0900, Boojin Kim <boojin.kim(a)samsung.com> wrote: > This patch adds dma maxburst size initialization. > The maxburst should be set by MODE_CFGn.DMA_TYPE, > because the pl330 dma driver supports burst mode. > > Signed-off-by: Hyeonkook Kim <hk619.kim(a)samsung.com> Hello Hyeonkook, I applied this patch but then discovered that it relys on the previous patches that you've posted. When patched depend on each other like this please post them as a series with [PATCH x/4] in the subject line. 'git send-email' will format this correctly for you. g. > --- > drivers/spi/spi-s3c64xx.c | 18 ++++++++++++++++++ > 1 files changed, 18 insertions(+), 0 deletions(-) > > diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c > index e862ab8..5e6cafe 100644 > --- a/drivers/spi/spi-s3c64xx.c > +++ b/drivers/spi/spi-s3c64xx.c > @@ -287,10 +287,20 @@ static void prepare_dma(struct s3c64xx_spi_dma_data *dma, > struct s3c64xx_spi_driver_data *sdd; > struct samsung_dma_prep info; > struct samsung_dma_config config; > + void __iomem *regs; > + unsigned int mode_cfg; > > if (dma->direction == DMA_DEV_TO_MEM) { > sdd = container_of((void *)dma, > struct s3c64xx_spi_driver_data, rx_dma); > + > + regs = sdd->regs; > + mode_cfg = readl(regs + S3C64XX_SPI_MODE_CFG); > + if (mode_cfg & S3C64XX_SPI_MODE_4BURST) > + config.maxburst = 4; > + else > + config.maxburst = 1; > + > config.direction = sdd->rx_dma.direction; > config.fifo = sdd->sfr_start + S3C64XX_SPI_RX_DATA; > config.width = sdd->cur_bpw / 8; > @@ -298,6 +308,14 @@ static void prepare_dma(struct s3c64xx_spi_dma_data *dma, > } else { > sdd = container_of((void *)dma, > struct s3c64xx_spi_driver_data, tx_dma); > + > + regs = sdd->regs; > + mode_cfg = readl(regs + S3C64XX_SPI_MODE_CFG); > + if (mode_cfg & S3C64XX_SPI_MODE_4BURST) > + config.maxburst = 4; > + else > + config.maxburst = 1; > + > config.direction = sdd->tx_dma.direction; > config.fifo = sdd->sfr_start + S3C64XX_SPI_TX_DATA; > config.width = sdd->cur_bpw / 8; > -- > 1.7.5.4 > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd.

1 0

Re: [alsa-devel] [PATCH v2 3/4] spi: s3c64xx: add dma maxburst size initialization
by Grant Likely 02 Mar '13

02 Mar '13

On Fri, 22 Feb 2013 17:09:18 +0900, Boojin Kim <boojin.kim(a)samsung.com> wrote: > This patch adds dma maxburst size initialization. > The maxburst should be set by MODE_CFGn.DMA_TYPE, > because the pl330 dma driver supports burst mode. > > Signed-off-by: Hyeonkook Kim <hk619.kim(a)samsung.com> Applied, thanks. g.

1 0

Re: [alsa-devel] [Alsa-user] Status of CM6631 USB
by Daniel Mack 02 Mar '13

02 Mar '13

Hi Torstein, (+ alsa-devel) On 02.03.2013 12:09, Torstein Hegge wrote: > Daniel Mack <zonque <at> gmail.com> writes: >>>> This is a known bug, also most probably flaw in the CMEDIA chip, >>>> and not yet properly worked around in the snd-usb driver. If you >>>> want to investigate, have a look at the feedback format >>>> autodetection code in sound/usb/endpoint.c. >>> >>> Thanks, I'll have a look. >> >> I believe what's going on here is that the device is confused after >> sample rate changes and keeps sending back feedback data for the old >> rate on its feedback endpoint. That causes the autodetection algorithm, >> which kicks in on every first packet of a stream, to go nuts, which >> causes the part of the driver that sends the data assume a very wrong >> rate. Some printk() there should give you a hint. > > I had a look at this using another C-Media CM6631 based device, the Corda > Daccord (usbid 0x0d8c, 0x0309). As far as I can see, what happens in the > feedback format auto-detection is: > > When starting playback of a file with a different sampling frequency than the > previous file, the reported feedback frequency is in the same range as the > previously played file, varying within +-1%. > > The feedback format detection gives a shift of -1 and reports the feedback > frequency as ~48kHz when playing a 44.1kHz file after a 96kHz file. Same thing > happens when playing a 96kHz file after a 44.1kHz file, the device reports > feedback frequency in the 44.1kHz range, the feedback format detection gives a > shift of +1 and reports the feedback frequency as ~88kHz. That's what I suspected. > Bypassing the feedback format detection by hard-coding the frequency shift to > zero and setting the feedback frequency ep->freqm equal to the nominal > frequency ep->freqn if the feedback frequency is far off from the expected > value (like 48kHz when expecting 44.1kHz) does not change the distortion. > > Similarly, forcing the feedback detection to run multiple times until it > reaches an acceptable value just keeps the feedback detection to repeatedly > until playback is stopped. This probably means any amount of skipping packages > early in the stream won't work. Ok. > It seems like the device stays in the previous frequency until the interface > is reset. One possible workaround is to call usb_set_interface() again after > snd_usb_init_sample_rate(), like this: I see - that also explains why explicitly stopping and restarting the stream fixes the problem in most cases, right? > > diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c > index d82e378..01978a6 100644 > --- a/sound/usb/pcm.c > +++ b/sound/usb/pcm.c > @@ -710,6 +710,16 @@ static int snd_usb_pcm_prepare(struct snd_pcm_substream > *substream) > subs->need_setup_ep = false; > } > > + /* Some devices doesn't respond to sample rate changes while the > + * interface is active. */ > + switch (subs->stream->chip->usb_id) { > + case USB_ID(0x0d8c, 0x0304): /* C-Media - Schiit USB Interface */ > + case USB_ID(0x0d8c, 0x0309): /* C-Media CM6631 */ > + usb_set_interface(subs->dev, subs->cur_audiofmt->iface, > + subs->cur_audiofmt->altset_idx); > + break; > + } > + > /* some unit conversions in runtime */ > subs->data_endpoint->maxframesize = > bytes_to_frames(runtime, subs->data_endpoint->maxpacksize); > > This fixes all problems related to sample rate changes for me. I have only > tested with the Daccord, but it should work for the Schiit and other CM6631 > based devices as well. Many thanks for looking into this! Much appreciated. Could you cook a real patch please and send it to alsa-devel? Have a look at Documentation/SubmittingPatches if that's your first submission. Best, Daniel

1 0

[alsa-devel] [PATCH 1/2] ASoC: max98090: Fix checkpatch errors related to spacing
by Sachin Kamat 02 Mar '13

02 Mar '13

Fixes the following type of checkpatch errors: ERROR: "foo * bar" should be "foo *bar" Signed-off-by: Sachin Kamat <sachin.kamat(a)linaro.org> --- sound/soc/codecs/max98090.c | 16 ++++++++-------- 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c index 1cf017f..89f83f8 100755 --- a/sound/soc/codecs/max98090.c +++ b/sound/soc/codecs/max98090.c @@ -507,16 +507,16 @@ static int max98090_put_enab_tlv(struct snd_kcontrol *kcontrol, return 0; } -static const char * max98090_perf_pwr_text[] = +static const char *max98090_perf_pwr_text[] = { "High Performance", "Low Power" }; -static const char * max98090_pwr_perf_text[] = +static const char *max98090_pwr_perf_text[] = { "Low Power", "High Performance" }; static const struct soc_enum max98090_vcmbandgap_enum = SOC_ENUM_SINGLE(M98090_REG_BIAS_CONTROL, M98090_VCM_MODE_SHIFT, ARRAY_SIZE(max98090_pwr_perf_text), max98090_pwr_perf_text); -static const char * max98090_osr128_text[] = { "64*fs", "128*fs" }; +static const char *max98090_osr128_text[] = { "64*fs", "128*fs" }; static const struct soc_enum max98090_osr128_enum = SOC_ENUM_SINGLE(M98090_REG_ADC_CONTROL, M98090_OSR128_SHIFT, @@ -533,28 +533,28 @@ static const struct soc_enum max98090_filter_dmic34mode_enum = M98090_FLT_DMIC34MODE_SHIFT, ARRAY_SIZE(max98090_mode_text), max98090_mode_text); -static const char * max98090_drcatk_text[] = +static const char *max98090_drcatk_text[] = { "0.5ms", "1ms", "5ms", "10ms", "25ms", "50ms", "100ms", "200ms" }; static const struct soc_enum max98090_drcatk_enum = SOC_ENUM_SINGLE(M98090_REG_DRC_TIMING, M98090_DRCATK_SHIFT, ARRAY_SIZE(max98090_drcatk_text), max98090_drcatk_text); -static const char * max98090_drcrls_text[] = +static const char *max98090_drcrls_text[] = { "8s", "4s", "2s", "1s", "0.5s", "0.25s", "0.125s", "0.0625s" }; static const struct soc_enum max98090_drcrls_enum = SOC_ENUM_SINGLE(M98090_REG_DRC_TIMING, M98090_DRCRLS_SHIFT, ARRAY_SIZE(max98090_drcrls_text), max98090_drcrls_text); -static const char * max98090_alccmp_text[] = +static const char *max98090_alccmp_text[] = { "1:1", "1:1.5", "1:2", "1:4", "1:INF" }; static const struct soc_enum max98090_alccmp_enum = SOC_ENUM_SINGLE(M98090_REG_DRC_COMPRESSOR, M98090_DRCCMP_SHIFT, ARRAY_SIZE(max98090_alccmp_text), max98090_alccmp_text); -static const char * max98090_drcexp_text[] = { "1:1", "2:1", "3:1" }; +static const char *max98090_drcexp_text[] = { "1:1", "2:1", "3:1" }; static const struct soc_enum max98090_drcexp_enum = SOC_ENUM_SINGLE(M98090_REG_DRC_EXPANDER, M98090_DRCEXP_SHIFT, @@ -857,7 +857,7 @@ static const struct soc_enum mic2_mux_enum = static const struct snd_kcontrol_new max98090_mic2_mux = SOC_DAPM_ENUM("MIC2 Mux", mic2_mux_enum); -static const char * max98090_micpre_text[] = { "Off", "On" }; +static const char *max98090_micpre_text[] = { "Off", "On" }; static const struct soc_enum max98090_pa1en_enum = SOC_ENUM_SINGLE(M98090_REG_MIC1_INPUT_LEVEL, M98090_MIC_PA1EN_SHIFT, -- 1.7.4.1

2 2