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

[alsa-devel] [PATCH] sound: oss: Remove useless initialisation
by Amitoj Kaur Chawla 12 Jul '16

12 Jul '16

@@ type T; identifier x; constant C; expression e; @@ T x - = C ; x = e; Signed-off-by: Amitoj Kaur Chawla <amitoj1606(a)gmail.com> --- sound/oss/ad1848.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/oss/ad1848.c b/sound/oss/ad1848.c index 10c8de1..6368e5c 100644 --- a/sound/oss/ad1848.c +++ b/sound/oss/ad1848.c @@ -254,7 +254,7 @@ static void ad_write(ad1848_info * devc, int reg, int data) static void wait_for_calibration(ad1848_info * devc) { - int timeout = 0; + int timeout; /* * Wait until the auto calibration process has finished. -- 1.9.1

1 0

[alsa-devel] Verification of settings
by Rob Nertney 12 Jul '16

12 Jul '16

Hi all, Could I please get a sanity check on my hw_params? I have a DMA which is providing between 1-16 channels of 4 bytes/ch worth of data as a frame. I get an interrupt to my driver every frame's worth of data (64 Bytes). The data is S32_LE, 16000Hz. My DMA has 2 buffers, PING and PONG. Each receives an IRQ on a frame length, and these local buffers are the size of a frame length (64Bytes). #define MAX_BUFFER (64 * 2) static struct snd_pcm_hardware my_pcm_hw = { .info = (SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP_VALID), .formats = SNDRV_PCM_FMTBIT_S32, .rates = SNDRV_PCM_RATE_16000, .rate_min = 16000, .rate_max = 16000, .channels_min = 1, .channels_max = NUM_CHANNELS, .buffer_bytes_max = MAX_BUFFER, .period_bytes_min = 4, .period_bytes_max = 64, .periods_min = 2, .periods_max = 2, }; My understanding is that the MAX_BUFFER needs to be at least twice the size of a period so I don't underrun. .periods_max means the maximum number of periods in a the alsa dma_area buffer, right? So when my DMA fires its ISR, I copy from its local PING buffer to the dma_area at offset 0, increment the buf_pos by the frame_length (64Bytes), and call snd_pcm_period_elapsed. My DMA fires its ISR for its local PONG buffer, copies to the dma_area+buf_pos, increments buf_pos (now back to 0, since buffer only holds 2 frames/periods), and I call snd_pcm_period_elapsed again, correct? Thanks, Rob

2 3

[alsa-devel] [PATCH 0/4] ASoC: Intel: Add support for KBL
by Vinod Koul 11 Jul '16

11 Jul '16

Kabylake is next generation Intel SoC which also sports a DSP. This controller is quite similar to Skylake. This patch series add KBL IDs to SKL driver, hdmi driver, sets combo jack for rt286 codec and finally adds entry to skl machine driver Shreyas NC (1): ASoC: hdac_hdmi: Add device id for Kabylake Vinod Koul (3): ASoC: Intel: add kablake device IDs ASoC: rt286: set combo jack for Kabylake ASoC: Intel: board: add kabylake machine id sound/soc/codecs/hdac_hdmi.c | 1 + sound/soc/codecs/rt286.c | 7 +++++++ sound/soc/intel/boards/skl_rt286.c | 9 +++++++++ sound/soc/intel/skylake/skl-messages.c | 6 ++++++ sound/soc/intel/skylake/skl.c | 8 ++++++++ 5 files changed, 31 insertions(+) -- 1.9.1

2 8

Re: [alsa-devel] Problem getting USB DAC to work
by Alan Stern 11 Jul '16

11 Jul '16

On Mon, 11 Jul 2016, John Westwood wrote: > I think the MTP stuff is a red herring. I checked syslog when I use a DAC that > works (Audiolab MDAC) and that has the MTP lines too, but it doesn't have the > warning line about Unlikely big volume range. > > In addition, the working DAC has the following lines which are not present the > non-working DAC: > > Jul 11 19:56:35 atlas kernel: [83940.049124] input: Lakewest Audio Audiolab > M-DAC as /devices/pci0000:00/0000:00:1d.1/usb7/7-2/7-2:1.0/0003:0451: > ADAC.0002/input/input12 > Jul 11 19:56:35 atlas kernel: [83940.104367] hid-generic 0003:0451:ADAC.0002: > input,hiddev0,hidraw1: USB HID v1.11 Device [Lakewest Audio Audiolab M-DAC] on > usb-0000:00:1d.1-2/input0 > > With the non-working DAC I get these lines instead: > > Jul 11 19:56:25 atlas kernel: [83930.079063] usb 7-2: Warning! Unlikely big > volume range (=65535), cval->res is probably wrong. > Jul 11 19:56:25 atlas kernel: [83930.079067] usb 7-2: [2] FU [PCM Playback > Volume] ch = 1, val = -32768/32767/1 > > > I think maybe the problem is similar to this one: > > https://groups.google.com/forum/#!topic/linux.debian.kernel/HwwkRkbL5aY > > Is my problem a bug in snd-usb-audio? Or am I doing something wrong? I would > really appreciate some thoughts on this, I feel like I'm talking to myself :-( Considering that you're not really doing anything, you're probably not doing something wrong. :-) On the other hand, you're likely to get more of a response if you direct your questions to the person who solved the problem mentioned in that Debian bug report, and if you CC: the sound developers' mailing list rather than the general USB list. Alan Stern

1 0

Re: [alsa-devel] [PATCH] snd/hda: fix use-after-free after module unload
by Takashi Iwai 11 Jul '16

11 Jul '16

On Sat, 09 Jul 2016 16:38:57 +0200, Peter Wu wrote: > > register_vga_switcheroo() sets the PM ops from the hda structure which > is freed later in azx_free. Make sure that these ops are cleared. > > Caught by KASAN. > > Fixes: 246efa4a072f ("snd/hda: add runtime suspend/resume on optimus support (v4)") > Signed-off-by: Peter Wu <peter(a)lekensteyn.nl> > --- > sound/pci/hda/hda_intel.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c > index 94089fc..a339066 100644 > --- a/sound/pci/hda/hda_intel.c > +++ b/sound/pci/hda/hda_intel.c > @@ -1219,6 +1219,7 @@ static int azx_free(struct azx *chip) > snd_hda_unlock_devices(&chip->bus); > if (hda->vga_switcheroo_registered) > vga_switcheroo_unregister_client(chip->pci); > + vga_switcheroo_fini_domain_pm_ops(chip->card->dev); The domain pm ops is set only when hda->vga_switcheroo_registered flag is set. So the call should be in the previous if block. Also, the indentation looks wrong. Please use the correct indentation. Could you resubmit with these fixes? thanks, Takashi

2 3

[alsa-devel] [PATCH] ASoC: hdac_hdmi: Fix potential NULL dereference
by Vinod Koul 11 Jul '16

11 Jul '16

Static checker warns: Pointer 'hlink' returned from call to function 'snd_hdac_ext_bus_get_link' at line may be NULL and will be dereferenced" So we should always check the return of snd_hdac_ext_bus_get_link() before referencing the link pointer Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> --- sound/soc/codecs/hdac_hdmi.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/sound/soc/codecs/hdac_hdmi.c b/sound/soc/codecs/hdac_hdmi.c index 13002f33384e..cc7bb77a28f1 100644 --- a/sound/soc/codecs/hdac_hdmi.c +++ b/sound/soc/codecs/hdac_hdmi.c @@ -1388,6 +1388,11 @@ static int hdmi_codec_probe(struct snd_soc_codec *codec) * exit, we call pm_runtime_suspend() so that will do for us */ hlink = snd_hdac_ext_bus_get_link(edev->ebus, dev_name(&edev->hdac.dev)); + if (!hlink) { + dev_err(&edev->hdac.dev, "hdac link not found\n"); + return -EIO; + } + snd_hdac_ext_bus_link_get(edev->ebus, hlink); ret = create_fill_widget_route_map(dapm); @@ -1494,6 +1499,11 @@ static int hdac_hdmi_dev_probe(struct hdac_ext_device *edev) /* hold the ref while we probe */ hlink = snd_hdac_ext_bus_get_link(edev->ebus, dev_name(&edev->hdac.dev)); + if (!hlink) { + dev_err(&edev->hdac.dev, "hdac link not found\n"); + return -EIO; + } + snd_hdac_ext_bus_link_get(edev->ebus, hlink); hdmi_priv = devm_kzalloc(&codec->dev, sizeof(*hdmi_priv), GFP_KERNEL); @@ -1600,6 +1610,11 @@ static int hdac_hdmi_runtime_suspend(struct device *dev) } hlink = snd_hdac_ext_bus_get_link(ebus, dev_name(dev)); + if (!hlink) { + dev_err(dev, "hdac link not found\n"); + return -EIO; + } + snd_hdac_ext_bus_link_put(ebus, hlink); return 0; @@ -1621,6 +1636,11 @@ static int hdac_hdmi_runtime_resume(struct device *dev) return 0; hlink = snd_hdac_ext_bus_get_link(ebus, dev_name(dev)); + if (!hlink) { + dev_err(dev, "hdac link not found\n"); + return -EIO; + } + snd_hdac_ext_bus_link_get(ebus, hlink); err = snd_hdac_display_power(bus, true); -- 1.9.1

2 2

[alsa-devel] [PATCH 1/2] ASoC: Intel: Skylake: Initialize module list for Broxton
by Vinod Koul 11 Jul '16

11 Jul '16

The module list was not initialized for Broxton DSP code, so initialize it. Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> --- sound/soc/intel/skylake/bxt-sst.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/intel/skylake/bxt-sst.c b/sound/soc/intel/skylake/bxt-sst.c index 622da5d3e3b3..9d36440c802a 100644 --- a/sound/soc/intel/skylake/bxt-sst.c +++ b/sound/soc/intel/skylake/bxt-sst.c @@ -325,6 +325,7 @@ int bxt_sst_dsp_init(struct device *dev, void __iomem *mmio_base, int irq, sst_dsp_mailbox_init(sst, (BXT_ADSP_SRAM0_BASE + SKL_ADSP_W0_STAT_SZ), SKL_ADSP_W0_UP_SZ, BXT_ADSP_SRAM1_BASE, SKL_ADSP_W1_SZ); + INIT_LIST_HEAD(&sst->module_list); ret = skl_ipc_init(dev, skl); if (ret) return ret; -- 1.9.1

2 4

[alsa-devel] [PATCH] ASoC: Intel: atom: fix missing breaks that would cause the wrong operation to execute
by Vinod Koul 11 Jul '16

11 Jul '16

From: Alan Cox <alan(a)linux.intel.com> Now we correctly error an attempt to execute an unsupported operation. Signed-off-by: Alan Cox <alan(a)linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> --- sound/soc/intel/atom/sst-mfld-platform-compress.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/sound/soc/intel/atom/sst-mfld-platform-compress.c b/sound/soc/intel/atom/sst-mfld-platform-compress.c index 395168986462..1bead81bb510 100644 --- a/sound/soc/intel/atom/sst-mfld-platform-compress.c +++ b/sound/soc/intel/atom/sst-mfld-platform-compress.c @@ -182,24 +182,29 @@ static int sst_platform_compr_trigger(struct snd_compr_stream *cstream, int cmd) case SNDRV_PCM_TRIGGER_START: if (stream->compr_ops->stream_start) return stream->compr_ops->stream_start(sst->dev, stream->id); + break; case SNDRV_PCM_TRIGGER_STOP: if (stream->compr_ops->stream_drop) return stream->compr_ops->stream_drop(sst->dev, stream->id); + break; case SND_COMPR_TRIGGER_DRAIN: if (stream->compr_ops->stream_drain) return stream->compr_ops->stream_drain(sst->dev, stream->id); + break; case SND_COMPR_TRIGGER_PARTIAL_DRAIN: if (stream->compr_ops->stream_partial_drain) return stream->compr_ops->stream_partial_drain(sst->dev, stream->id); + break; case SNDRV_PCM_TRIGGER_PAUSE_PUSH: if (stream->compr_ops->stream_pause) return stream->compr_ops->stream_pause(sst->dev, stream->id); + break; case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: if (stream->compr_ops->stream_pause_release) return stream->compr_ops->stream_pause_release(sst->dev, stream->id); - default: - return -EINVAL; + break; } + return -EINVAL; } static int sst_platform_compr_pointer(struct snd_compr_stream *cstream, -- 1.9.1

2 3

[alsa-devel] [PATCH alsa-lib v2 0/3] PCM thread-safety patchset
by Takashi Iwai 11 Jul '16

11 Jul '16

Hi, here is a v2 patchset for supporting multi thread safety to alsa-lib PCM API. Now it's out from RFC and should be reviewed as an official patchset. Basically ALSA PCM functions are thread-unsafe, and applications are supposed to do the proper protection against racy accesses. The reality is, however, that application developers don't care such, as alsa-lib works in most cases. Of course, users still get occasionally mysterious crashes. As a workaround, this patchset adds the pthread mutex protection to most of exported PCM functions. This is slightly an overkill, but the biggest merit is that it's easy to implement; I just wrapped the functions and replaced the internal ones with unlocked versions. To be noted, there is an optimization for the direct hw PCM access. Performance-sensitive applications like JACK should work like before without any overhead. Another bonus by this addition is that we can finally get rid of home brew (and deadly smelling) atomic macros from the tree, since it's now more widely protected. I lightly tested on my local machines (dmix, PA, jack and plugins) and all seem working well, so far. Takashi === v1->v2: - Drop locking for some API functions like hw_params - Lock some functions even for hw plugin to keep PCM internals consistent - Fix deadlock with jack ioplug - More documentations and comments - Add debugging option via $LIBASOUND_THREAD_SAFE=0 - Reordered patches Takashi Iwai (3): pcm: Add thread-safety to PCM API pcm: Remove home brew atomic operations pcm: Add LIBASOUND_THREAD_SAFE env variable check INSTALL | 9 ++ configure.ac | 15 ++ include/Makefile.am | 2 +- include/iatomic.h | 170 -------------------- include/pcm_ioplug.h | 10 +- src/pcm/Makefile.am | 2 +- src/pcm/atomic.c | 43 ----- src/pcm/pcm.c | 433 +++++++++++++++++++++++++++++++++++++++++--------- src/pcm/pcm_direct.c | 4 +- src/pcm/pcm_dmix.c | 13 +- src/pcm/pcm_dshare.c | 13 +- src/pcm/pcm_dsnoop.c | 15 +- src/pcm/pcm_file.c | 21 ++- src/pcm/pcm_generic.c | 10 +- src/pcm/pcm_hw.c | 3 + src/pcm/pcm_ioplug.c | 70 +++++--- src/pcm/pcm_local.h | 131 +++++++++++---- src/pcm/pcm_mmap.c | 18 ++- src/pcm/pcm_plugin.c | 72 ++------- src/pcm/pcm_plugin.h | 2 - src/pcm/pcm_rate.c | 41 ++--- src/pcm/pcm_route.c | 2 +- 22 files changed, 648 insertions(+), 451 deletions(-) delete mode 100644 include/iatomic.h delete mode 100644 src/pcm/atomic.c -- 2.9.0

1 4

[alsa-devel] [PATCH 0/3] ALSA - hda: Add support for link audio time reporting
by Vinod Koul 11 Jul '16

11 Jul '16

Skylake onwards we support GTS capability and thus can report audio link time. This series adds support for parsing the capability and then reports link time. While at it, fix the timestamping Documentation. Guneshwor Singh (2): ALSA - hda: Add support for GTS capability ALSA - hda: Add support for link audio time reporting Vinod Koul (1): ALSA - hda: Fix timestamping documentation Documentation/sound/alsa/timestamping.txt | 12 +- include/sound/hda_register.h | 23 ++++ sound/pci/hda/hda_controller.c | 192 +++++++++++++++++++++++++++++- sound/pci/hda/hda_controller.h | 27 +++++ sound/pci/hda/hda_intel.c | 1 + 5 files changed, 248 insertions(+), 7 deletions(-) -- 1.9.1

2 12