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

[alsa-devel] [PATCH] SoC: intel: byt: Introduce new custom IN2 map
by Carlo Caione 21 Nov '17

21 Nov '17

From: Carlo Caione <carlo(a)endlessm.com> Introduce a new custom dapm routes map to quirk platforms with the internal mic connected to IN2P. Signed-off-by: Carlo Caione <carlo(a)endlessm.com> --- sound/soc/intel/boards/bytcr_rt5651.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/sound/soc/intel/boards/bytcr_rt5651.c b/sound/soc/intel/boards/bytcr_rt5651.c index 3076bfc0db5e..1dad5c98c9ef 100644 --- a/sound/soc/intel/boards/bytcr_rt5651.c +++ b/sound/soc/intel/boards/bytcr_rt5651.c @@ -37,6 +37,7 @@ enum { BYT_RT5651_DMIC_MAP, BYT_RT5651_IN1_MAP, + BYT_RT5651_IN2_MAP, }; #define BYT_RT5651_MAP(quirk) ((quirk) & GENMASK(7, 0)) @@ -58,6 +59,8 @@ static void log_quirks(struct device *dev) dev_info(dev, "quirk DMIC_MAP enabled"); if (BYT_RT5651_MAP(byt_rt5651_quirk) == BYT_RT5651_IN1_MAP) dev_info(dev, "quirk IN1_MAP enabled"); + if (BYT_RT5651_MAP(byt_rt5651_quirk) == BYT_RT5651_IN2_MAP) + dev_info(dev, "quirk IN2_MAP enabled"); if (byt_rt5651_quirk & BYT_RT5651_DMIC_EN) dev_info(dev, "quirk DMIC enabled"); if (byt_rt5651_quirk & BYT_RT5651_MCLK_EN) @@ -143,7 +146,6 @@ static const struct snd_soc_dapm_route byt_rt5651_audio_map[] = { {"ssp2 Rx", NULL, "AIF1 Capture"}, {"Headset Mic", NULL, "micbias1"}, /* lowercase for rt5651 */ - {"IN2P", NULL, "Headset Mic"}, {"Headphone", NULL, "HPOL"}, {"Headphone", NULL, "HPOR"}, {"Speaker", NULL, "LOUTL"}, @@ -151,15 +153,23 @@ static const struct snd_soc_dapm_route byt_rt5651_audio_map[] = { }; static const struct snd_soc_dapm_route byt_rt5651_intmic_dmic_map[] = { + {"IN2P", NULL, "Headset Mic"}, {"DMIC L1", NULL, "Internal Mic"}, {"DMIC R1", NULL, "Internal Mic"}, }; static const struct snd_soc_dapm_route byt_rt5651_intmic_in1_map[] = { {"Internal Mic", NULL, "micbias1"}, + {"IN2P", NULL, "Headset Mic"}, {"IN1P", NULL, "Internal Mic"}, }; +static const struct snd_soc_dapm_route byt_rt5651_intmic_in2_map[] = { + {"Internal Mic", NULL, "micbias1"}, + {"IN1P", NULL, "Headset Mic"}, + {"IN2P", NULL, "Internal Mic"}, +}; + static const struct snd_kcontrol_new byt_rt5651_controls[] = { SOC_DAPM_PIN_SWITCH("Headphone"), SOC_DAPM_PIN_SWITCH("Headset Mic"), @@ -246,6 +256,10 @@ static int byt_rt5651_init(struct snd_soc_pcm_runtime *runtime) custom_map = byt_rt5651_intmic_in1_map; num_routes = ARRAY_SIZE(byt_rt5651_intmic_in1_map); break; + case BYT_RT5651_IN2_MAP: + custom_map = byt_rt5651_intmic_in2_map; + num_routes = ARRAY_SIZE(byt_rt5651_intmic_in2_map); + break; default: custom_map = byt_rt5651_intmic_dmic_map; num_routes = ARRAY_SIZE(byt_rt5651_intmic_dmic_map); -- 2.14.2

3 5

[alsa-devel] [PATCH v2] ALSA: core: update tstamp only if audio_tstamp changed
by Henrik Eriksson 21 Nov '17

21 Nov '17

commit 3179f6200188 ("ALSA: core: add .get_time_info") had a side effect of changing the behaviour of the PCM runtime tstamp. Prior to this change tstamp was not updated by snd_pcm_update_hw_ptr0() unless the hw_ptr had moved, after this change tstamp was always updated. For an application using alsa-lib, doing snd_pcm_readi() followed by snd_pcm_status() to estimate the age of the read samples by subtracting status->avail * [sample rate] from status->tstamp this change degraded the accuracy of the estimate on devices where the pcm hw does not provide a granular hw_ptr, e.g., devices using soc-generic-dmaengine-pcm.c and a dma-engine with residue_granularity DMA_RESIDUE_GRANULARITY_DESCRIPTOR. The accuracy of the estimate depended on the latency between the PCM hw completing a period and the driver called snd_pcm_period_elapsed() to notify ALSA core, typically determined by interrupt handling latency. After the change the accuracy of the estimate depended on the latency between the PCM hw completing a period and the application calling snd_pcm_status(), determined by the scheduling of the application process. The maximum error of the estimate is one period length in both cases, but the error average and variance is smaller when it depends on interrupt latency. Instead of always updating tstamp, update it only if audio_tstamp changed. Fixes: 3179f6200188 ("ALSA: core: add .get_time_info") Suggested-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Signed-off-by: Henrik Eriksson <henrik.eriksson(a)axis.com> --- Changes since v1: - Use Pierre-Louis Bossart's suggested fix - Clean up commit log sound/core/pcm_lib.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c index a93a4235a332..10e7ef7a8804 100644 --- a/sound/core/pcm_lib.c +++ b/sound/core/pcm_lib.c @@ -248,8 +248,10 @@ static void update_audio_tstamp(struct snd_pcm_substream *substream, runtime->rate); *audio_tstamp = ns_to_timespec(audio_nsecs); } - runtime->status->audio_tstamp = *audio_tstamp; - runtime->status->tstamp = *curr_tstamp; + if (!timespec_equal(&runtime->status->audio_tstamp, audio_tstamp)) { + runtime->status->audio_tstamp = *audio_tstamp; + runtime->status->tstamp = *curr_tstamp; + } /* * re-take a driver timestamp to let apps detect if the reference tstamp -- 2.11.0

2 1

[alsa-devel] [PATCH] ASoC: fsl_ssi: call _fsl_ssi_set_dai_fmt() just once in AC'97 mode
by Maciej S. Szmigiero 21 Nov '17

21 Nov '17

In AC'97 mode we configure and start SSI RX / TX on probe path via a call to _fsl_ssi_set_dai_fmt() function. We don't need to call this function again later and in fact don't want to do it since this function temporarily sets STCR, SRCR and SCR to some intermediate values. We need to make sure, however, that only proper channel slots are enabled at playback start time since some AC'97 CODECs (like VT1613) were observed requesting via SLOTREQ (and so enabling at SSI) spurious ones just after an AC'97 link is started but before the CODEC is configured by its driver. Theoretically, this should be necessary only for the very first playback but let's play safe here and make sure that no extra slots are enabled every time a playback is started. Signed-off-by: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name> --- sound/soc/fsl/fsl_ssi.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c index 48bb850a34d9..dad80b4b0cfc 100644 --- a/sound/soc/fsl/fsl_ssi.c +++ b/sound/soc/fsl/fsl_ssi.c @@ -630,12 +630,6 @@ static void fsl_ssi_setup_ac97(struct fsl_ssi_private *ssi_private) regmap_write(regs, CCSR_SSI_SACNT, CCSR_SSI_SACNT_AC97EN | CCSR_SSI_SACNT_FV); - /* no SACC{ST,EN,DIS} regs on imx21-class SSI */ - if (!ssi_private->soc->imx21regs) { - regmap_write(regs, CCSR_SSI_SACCDIS, 0xff); - regmap_write(regs, CCSR_SSI_SACCEN, 0x300); - } - /* * Enable SSI, Transmit and Receive. AC97 has to communicate with the * codec before a stream is started. @@ -1076,6 +1070,9 @@ static int fsl_ssi_set_dai_fmt(struct snd_soc_dai *cpu_dai, unsigned int fmt) { struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(cpu_dai); + if (fsl_ssi_is_ac97(ssi_private)) + return 0; + return _fsl_ssi_set_dai_fmt(cpu_dai->dev, ssi_private, fmt); } @@ -1149,9 +1146,16 @@ static int fsl_ssi_trigger(struct snd_pcm_substream *substream, int cmd, case SNDRV_PCM_TRIGGER_START: case SNDRV_PCM_TRIGGER_RESUME: case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { + /* no SACC{ST,EN,DIS} regs on imx21-class SSI */ + if (fsl_ssi_is_ac97(ssi_private) && + !ssi_private->soc->imx21regs) { + regmap_write(regs, CCSR_SSI_SACCDIS, 0xff); + regmap_write(regs, CCSR_SSI_SACCEN, 0x300); + } + fsl_ssi_tx_config(ssi_private, true); - else + } else fsl_ssi_rx_config(ssi_private, true); break;

2 4

[alsa-devel] [PATCH alsa-tools] hdajacksensetest: add gitcompile to EXTRA_DIST
by Tanu Kaskinen 20 Nov '17

20 Nov '17

The gitcompile script is used from the top-level Makefile, so it needs to be included in the tarball. Signed-off-by: Tanu Kaskinen <tanuk(a)iki.fi> --- hdajacksensetest/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/hdajacksensetest/Makefile.am b/hdajacksensetest/Makefile.am index 795373c..893b4e1 100644 --- a/hdajacksensetest/Makefile.am +++ b/hdajacksensetest/Makefile.am @@ -1,3 +1,4 @@ +EXTRA_DIST = gitcompile MYNAME = hdajacksensetest AUTOMAKE_OPTIONS = foreign bin_PROGRAMS = hdajacksensetest -- 2.14.2

2 1

[alsa-devel] [PATCH] ALSA: line6: add support for POD HD DESKTOP
by Hans P. Möller Ebner 20 Nov '17

20 Nov '17

Add support for the Line6 POD HD500X multi effect processor for playback and capture (in/out audio) through USB. Signed-off-by: Hans P. Moller <hmoller(a)uc.cl> --- sound/usb/line6/podhd.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/sound/usb/line6/podhd.c b/sound/usb/line6/podhd.c index 956f847..ba4f71f 100644 --- a/sound/usb/line6/podhd.c +++ b/sound/usb/line6/podhd.c @@ -39,7 +39,8 @@ enum { LINE6_PODHD500_1, LINE6_PODX3, LINE6_PODX3LIVE, - LINE6_PODHD500X + LINE6_PODHD500X, + LINE6_PODHDDESKTOP }; struct usb_line6_podhd { @@ -377,6 +378,7 @@ static const struct usb_device_id podhd_id_table[] = { { LINE6_IF_NUM(0x414A, 0), .driver_info = LINE6_PODX3 }, { LINE6_IF_NUM(0x414B, 0), .driver_info = LINE6_PODX3LIVE }, { LINE6_IF_NUM(0x4159, 0), .driver_info = LINE6_PODHD500X }, + { LINE6_IF_NUM(0x4156, 0), .driver_info = LINE6_PODHDDESKTOP }, {} }; @@ -463,6 +465,18 @@ static const struct line6_properties podhd_properties_table[] = { .ep_audio_r = 0x86, .ep_audio_w = 0x02, }, + [LINE6_PODHDDESKTOP] = { + .id = "PODHDDESKTOP", + .name = "POD HDDESKTOP", + .capabilities = LINE6_CAP_CONTROL + | LINE6_CAP_PCM | LINE6_CAP_HWMON, + .altsetting = 1, + .ep_ctrl_r = 0x81, + .ep_ctrl_w = 0x01, + .ctrl_if = 1, + .ep_audio_r = 0x86, + .ep_audio_w = 0x02, + }, }; /* -- 2.7.4

3 3

[alsa-devel] [PATCH] ASoC: cht_bsw_rt5645: Use common error handling code in cht_codec_fixup()
by SF Markus Elfring 20 Nov '17

20 Nov '17

From: Markus Elfring <elfring(a)users.sourceforge.net> Date: Sun, 19 Nov 2017 09:53:56 +0100 * Add a jump target so that a specific error message is stored only once at the end of this function implementation. * Replace two calls of the function "dev_err" by goto statements. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net> --- sound/soc/intel/boards/cht_bsw_rt5645.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/sound/soc/intel/boards/cht_bsw_rt5645.c b/sound/soc/intel/boards/cht_bsw_rt5645.c index 18d129caa974..bf3ffc2b0d8f 100644 --- a/sound/soc/intel/boards/cht_bsw_rt5645.c +++ b/sound/soc/intel/boards/cht_bsw_rt5645.c @@ -357,20 +357,16 @@ static int cht_codec_fixup(struct snd_soc_pcm_runtime *rtd, SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBS_CFS ); - if (ret < 0) { - dev_err(rtd->dev, "can't set format to I2S, err %d\n", ret); - return ret; - } + if (ret < 0) + goto report_failure; ret = snd_soc_dai_set_fmt(rtd->codec_dai, SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBS_CFS ); - if (ret < 0) { - dev_err(rtd->dev, "can't set format to I2S, err %d\n", ret); - return ret; - } + if (ret < 0) + goto report_failure; ret = snd_soc_dai_set_tdm_slot(rtd->cpu_dai, 0x3, 0x3, 2, 16); if (ret < 0) { @@ -403,6 +399,10 @@ static int cht_codec_fixup(struct snd_soc_pcm_runtime *rtd, } } return 0; + +report_failure: + dev_err(rtd->dev, "can't set format to I2S, err %d\n", ret); + return ret; } static int cht_aif1_startup(struct snd_pcm_substream *substream) -- 2.15.0

3 2

Re: [alsa-devel] BUG: unable to handle kernel paging request in snd_seq_oss_readq_puts
by Dmitry Vyukov 20 Nov '17

20 Nov '17

On Wed, Nov 1, 2017 at 9:38 PM, syzbot <bot+31681772ec7a18dde8d3f8caf475f361a89b9514(a)syzkaller.appspotmail.com> wrote: > Hello, > > syzkaller hit the following crash on > fc2e8b1a47c14b22c33eb087fca0db58e1f4ed0e > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. > C reproducer is attached > syzkaller reproducer is attached. See https://goo.gl/kgGztJ > for information about syzkaller reproducers This also happened on more recent commits, including upstream 9c323bff13f92832e03657cabdd70d731408d621 (Oct 20): device gre0 entered promiscuous mode BUG: unable to handle kernel paging request at ffffc90001688000 IP: snd_seq_oss_readq_puts+0x146/0x210 sound/core/seq/oss/seq_oss_readq.c:112 PGD 1dac75067 P4D 1dac75067 PUD 1dac76067 PMD 1c1dd3067 PTE 0 Oops: 0000 [#1] SMP KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 1 PID: 18947 Comm: syz-executor2 Not tainted 4.14.0-rc5+ #51 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 task: ffff8801d92c8140 task.stack: ffff8801c2ef0000 RIP: 0010:snd_seq_oss_readq_puts+0x146/0x210 sound/core/seq/oss/seq_oss_readq.c:112 RSP: 0018:ffff8801c2ef6db0 EFLAGS: 00010246 RAX: ffffed00385dedbf RBX: ffffc90001688000 RCX: ffff8801c2ef6df9 RDX: 000000000000554e RSI: ffffffff83d4c556 RDI: 0000000000000282 RBP: ffff8801c2ef6e60 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 00000000400000a0 R13: ffff8801c2ef6e38 R14: ffffc90001688001 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8801db300000(0063) knlGS:00000000f76ffb40 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: ffffc90001688000 CR3: 00000001d0650000 CR4: 00000000001406e0 DR0: 0000000020000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 Call Trace: send_midi_event sound/core/seq/oss/seq_oss_midi.c:616 [inline] snd_seq_oss_midi_input+0xd39/0x1040 sound/core/seq/oss/seq_oss_midi.c:535 snd_seq_oss_event_input+0x15d/0x220 sound/core/seq/oss/seq_oss_event.c:439 snd_seq_deliver_single_event.constprop.11+0x2fb/0x940 sound/core/seq/seq_clientmgr.c:621 deliver_to_subscribers sound/core/seq/seq_clientmgr.c:676 [inline] snd_seq_deliver_event+0x318/0x790 sound/core/seq/seq_clientmgr.c:807 snd_seq_kernel_client_dispatch+0x11e/0x150 sound/core/seq/seq_clientmgr.c:2313 dummy_input+0x2c4/0x400 sound/core/seq/seq_dummy.c:104 snd_seq_deliver_single_event.constprop.11+0x2fb/0x940 sound/core/seq/seq_clientmgr.c:621 snd_seq_deliver_event+0x12c/0x790 sound/core/seq/seq_clientmgr.c:818 snd_seq_dispatch_event+0x105/0x5b0 sound/core/seq/seq_clientmgr.c:892 snd_seq_check_queue.part.3+0x38e/0x510 sound/core/seq/seq_queue.c:285 snd_seq_check_queue sound/core/seq/seq_queue.c:357 [inline] snd_seq_enqueue_event+0x32d/0x3d0 sound/core/seq/seq_queue.c:363 snd_seq_client_enqueue_event+0x21b/0x420 sound/core/seq/seq_clientmgr.c:951 kernel_client_enqueue.part.10+0xb5/0xd0 sound/core/seq/seq_clientmgr.c:2252 kernel_client_enqueue sound/core/seq/seq_clientmgr.c:2242 [inline] snd_seq_kernel_client_enqueue_blocking+0xcf/0x110 sound/core/seq/seq_clientmgr.c:2279 insert_queue sound/core/seq/oss/seq_oss_rw.c:189 [inline] snd_seq_oss_write+0x5fe/0xa80 sound/core/seq/oss/seq_oss_rw.c:148 odev_write+0x64/0x90 sound/core/seq/oss/seq_oss.c:177 __vfs_write+0xef/0x970 fs/read_write.c:479 __kernel_write+0xf8/0x350 fs/read_write.c:500 write_pipe_buf+0x175/0x220 fs/splice.c:797 splice_from_pipe_feed fs/splice.c:502 [inline] __splice_from_pipe+0x328/0x730 fs/splice.c:626 splice_from_pipe+0x1e9/0x330 fs/splice.c:661 default_file_splice_write+0x40/0x90 fs/splice.c:809 do_splice_from fs/splice.c:851 [inline] do_splice fs/splice.c:1147 [inline] SYSC_splice fs/splice.c:1402 [inline] SyS_splice+0x7b7/0x1610 fs/splice.c:1382 do_syscall_32_irqs_on arch/x86/entry/common.c:329 [inline] do_fast_syscall_32+0x3f2/0xf05 arch/x86/entry/common.c:391 entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:124 RIP: 0023:0xf7f03c79 RSP: 002b:00000000f76ff01c EFLAGS: 00000296 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 0000000000000014 RCX: 0000000000000000 RDX: 0000000000000013 RSI: 0000000000000000 RDI: 000000005813dd57 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Code: d9 4c 8d 73 01 48 c1 e8 03 83 e1 07 42 0f b6 04 38 38 c8 7f 08 84 c0 0f 85 bf 00 00 00 48 8b 85 58 ff ff ff 48 8b 8d 68 ff ff ff <41> 0f b6 5e ff 0f b6 00 83 e1 07 38 c8 7f 08 84 c0 0f 85 89 00 RIP: snd_seq_oss_readq_puts+0x146/0x210 sound/core/seq/oss/seq_oss_readq.c:112 RSP: ffff8801c2ef6db0 CR2: ffffc90001688000 ---[ end trace c7c98a599517e76d ]--- > IP: snd_seq_oss_readq_puts+0x146/0x210 > sound/core/seq/oss/seq_oss_readq.c:112 > PGD 1dac75067 P4D 1dac75067 PUD 1dac76067 PMD 1c1cd3067 PTE 0 > Oops: 0000 [#1] SMP KASAN > Dumping ftrace buffer: > (ftrace buffer empty) > Modules linked in: > CPU: 0 PID: 3012 Comm: syzkaller659314 Not tainted 4.14.0-rc1-next-20170918+ > #24 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > task: ffff8801ce930000 task.stack: ffff8801ce650000 > RIP: 0010:snd_seq_oss_readq_puts+0x146/0x210 > sound/core/seq/oss/seq_oss_readq.c:112 > RSP: 0018:ffff8801ce657208 EFLAGS: 00010246 > RAX: ffffed0039ccae4a RBX: ffffc900016f4000 RCX: ffff8801ce657251 > RDX: 0000000000000000 RSI: 1ffff10039d26117 RDI: 0000000000000282 > RBP: ffff8801ce6572b8 R08: ffff8801d807ab50 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000000 R12: 000000003fffffa4 > R13: ffff8801ce657290 R14: ffffc900016f4001 R15: dffffc0000000000 > FS: 00007f9079b19700(0000) GS:ffff8801db200000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: ffffc900016f4000 CR3: 00000001ce47d000 CR4: 00000000001406f0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > Call Trace: > send_midi_event sound/core/seq/oss/seq_oss_midi.c:616 [inline] > snd_seq_oss_midi_input+0xd39/0x1040 sound/core/seq/oss/seq_oss_midi.c:535 > snd_seq_oss_event_input+0x15d/0x220 sound/core/seq/oss/seq_oss_event.c:439 > snd_seq_deliver_single_event.constprop.11+0x2fb/0x940 > sound/core/seq/seq_clientmgr.c:621 > deliver_to_subscribers sound/core/seq/seq_clientmgr.c:676 [inline] > snd_seq_deliver_event+0x318/0x790 sound/core/seq/seq_clientmgr.c:807 > snd_seq_kernel_client_dispatch+0x11e/0x150 > sound/core/seq/seq_clientmgr.c:2309 > dummy_input+0x2c4/0x400 sound/core/seq/seq_dummy.c:104 > snd_seq_deliver_single_event.constprop.11+0x2fb/0x940 > sound/core/seq/seq_clientmgr.c:621 > snd_seq_deliver_event+0x12c/0x790 sound/core/seq/seq_clientmgr.c:818 > snd_seq_dispatch_event+0x105/0x5b0 sound/core/seq/seq_clientmgr.c:892 > snd_seq_check_queue.part.3+0x38e/0x510 sound/core/seq/seq_queue.c:285 > snd_seq_check_queue sound/core/seq/seq_queue.c:357 [inline] > snd_seq_enqueue_event+0x32d/0x3d0 sound/core/seq/seq_queue.c:363 > snd_seq_client_enqueue_event+0x21b/0x420 sound/core/seq/seq_clientmgr.c:951 > kernel_client_enqueue.part.10+0xb5/0xd0 sound/core/seq/seq_clientmgr.c:2248 > kernel_client_enqueue sound/core/seq/seq_clientmgr.c:2238 [inline] > snd_seq_kernel_client_enqueue_blocking+0xcf/0x110 > sound/core/seq/seq_clientmgr.c:2275 > insert_queue sound/core/seq/oss/seq_oss_rw.c:189 [inline] > snd_seq_oss_write+0x5fe/0xa80 sound/core/seq/oss/seq_oss_rw.c:148 > odev_write+0x64/0x90 sound/core/seq/oss/seq_oss.c:177 > __vfs_write+0xef/0x970 fs/read_write.c:479 > vfs_write+0x18f/0x510 fs/read_write.c:543 > SYSC_write fs/read_write.c:588 [inline] > SyS_write+0xef/0x220 fs/read_write.c:580 > entry_SYSCALL_64_fastpath+0x1f/0xbe > RIP: 0033:0x446469 > RSP: 002b:00007f9079b18dc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 > RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000446469 > RDX: 0000000000000150 RSI: 0000000020e7f000 RDI: 0000000000000003 > RBP: 0000000000000082 R08: 00007f9079b19700 R09: 00007f9079b19700 > R10: 00007f9079b19700 R11: 0000000000000246 R12: 0000000000000000 > R13: 00007ffe543fcc1f R14: 00007f9079b199c0 R15: 0000000000000000 > Code: d9 4c 8d 73 01 48 c1 e8 03 83 e1 07 42 0f b6 04 38 38 c8 7f 08 84 c0 > 0f 85 bf 00 00 00 48 8b 85 58 ff ff ff 48 8b 8d 68 ff ff ff <41> 0f b6 5e ff > 0f b6 00 83 e1 07 38 c8 7f 08 84 c0 0f 85 89 00 > RIP: snd_seq_oss_readq_puts+0x146/0x210 > sound/core/seq/oss/seq_oss_readq.c:112 RSP: ffff8801ce657208 > CR2: ffffc900016f4000 > ---[ end trace cc8c763aca15dec8 ]--- > > > --- > This bug is generated by a dumb bot. It may contain errors. > See https://goo.gl/tpsmEJ for details. > Direct all questions to syzkaller(a)googlegroups.com. > Please credit me with: Reported-by: syzbot <syzkaller(a)googlegroups.com> > > syzbot will keep track of this bug report. > Once a fix for this bug is committed, please reply to this email with: > #syz fix: exact-commit-title > To mark this as a duplicate of another syzbot report, please reply with: > #syz dup: exact-subject-of-another-report > If it's a one-off invalid bug report, please reply with: > #syz invalid > Note: if the crash happens again, it will cause creation of a new bug > report. > Note: all commands must start from beginning of the line. > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscribe(a)googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/001a1140b6b825822a055cf02f…. > For more options, visit https://groups.google.com/d/optout.

2 7

[alsa-devel] [alsa-lib][PATCH] pcm: route: Fix use_getput flag computation for 3 byte formats
by Maciej S. Szmigiero 20 Nov '17

20 Nov '17

Commit de63b942acf520 ("pcm: route: Use get/put labels for all 3 byte formats") wanted to make the route plugin use get / put labels not only for 24-bit physical width formats but also for 18 and 20-bit ones. There was, however, a typo in that commit so a check for these widths didn't really work. Let's fix it now. Signed-off-by: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name> --- src/pcm/pcm_route.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/pcm/pcm_route.c b/src/pcm/pcm_route.c index 999a2eed3a25..1f485a8e79f9 100644 --- a/src/pcm/pcm_route.c +++ b/src/pcm/pcm_route.c @@ -567,8 +567,8 @@ static int snd_pcm_route_hw_params(snd_pcm_t *pcm, snd_pcm_hw_params_t * params) return err; /* 3 bytes formats? */ route->params.use_getput = - (snd_pcm_format_physical_width(src_format) + 7) / 3 == 3 || - (snd_pcm_format_physical_width(dst_format) + 7) / 3 == 3; + (snd_pcm_format_physical_width(src_format) + 7) / 8 == 3 || + (snd_pcm_format_physical_width(dst_format) + 7) / 8 == 3; route->params.get_idx = snd_pcm_linear_get_index(src_format, SND_PCM_FORMAT_S32); route->params.put_idx = snd_pcm_linear_put_index(SND_PCM_FORMAT_S32, dst_format); route->params.conv_idx = snd_pcm_linear_convert_index(src_format, dst_format); -- 2.14.1

2 1

[alsa-devel] [RFC PATCH] ALSA: core: do not update tstamp when hw ptr has not moved
by Henrik Eriksson 20 Nov '17

20 Nov '17

Hello This reverts a change that was part of a larger commit. That change broke timestamps in some application code for us as outlined in the log, and reverting it obviously fixes this. Since the original change did not explain why the behaviour was modified I can't speak for the effects on that use case. Regards, /henrik >8------------------------------------------------------8< Commit 3179f62001880e588e229db3006a59ad87b7792a ("ALSA: core: add .get_time_info") made an undocumented change to the behaviour of the PCM runtime tstamp. Prior to this change the tstamp was not updated by snd_pcm_update_hw_ptr0() unless the hw ptr had moved, after this change the tstamp is always updated. For an application, using alsa-lib, doing snd_pcm_readi() followed by snd_pcm_status() to estimate the age of the read samples by subtracting status->avail * [sample rate] from status->tstamp this change degraded the accuracy of that estimate on devices where the pcm hw does not provide a granular hw pointer. On a device using soc-generic-dmaengine-pcm.c and a dma-engine with residue_granularity DMA_RESIDUE_GRANULARITY_DESCRIPTOR the accuracy of the estimate depended on the latency between the PCM hw completing a period and when the driver called snd_pcm_period_elapsed() to notify ALSA core, typically determined by interrupt handling latency. After this change the accuracy of the estimate is determined by the latency between the PCM hw completing a period and the application calling snd_pcm_status(), determined by the scheduling of the application process. Revert the part of commit 3179f62001880e588e229db3006a59ad87b7792a ("ALSA: core: add .get_time_info") that changed be behaviour of snd_pcm_update_hw_ptr0() when the PCM hw pointer has not moved. Fixes: 3179f6200188 ("ALSA: core: add .get_time_info") Signed-off-by: Henrik Eriksson <henrik.eriksson(a)axis.com> --- sound/core/pcm_lib.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c index a93a4235a332..2fbaf9a974cc 100644 --- a/sound/core/pcm_lib.c +++ b/sound/core/pcm_lib.c @@ -437,10 +437,8 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream, } no_delta_check: - if (runtime->status->hw_ptr == new_hw_ptr) { - update_audio_tstamp(substream, &curr_tstamp, &audio_tstamp); + if (runtime->status->hw_ptr == new_hw_ptr) return 0; - } if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK && runtime->silence_size > 0) -- 2.11.0 -- henrik eriksson fixed box cameras firmware, base video products, axis communications ab

3 6

[alsa-devel] strange code in pcm_route.c for 3 byte formats
by Maciej S. Szmigiero 20 Nov '17

20 Nov '17

Hi all, While reading alsa-lib sources I've spotted some strange code in src/pcm/pcm_route.c: /* 3 bytes formats? */ route->params.use_getput = (snd_pcm_format_physical_width(src_format) + 7) / 3 == 3 || (snd_pcm_format_physical_width(dst_format) + 7) / 3 == 3; Since snd_pcm_format_physical_width() returns a width in bits it seems to me that this would mean formats that are between 2 and 4 bits (inclusive) wide. Before commit de63b942acf520 ("pcm: route: Use get/put labels for all 3 byte formats") this read as: route->params.use_getput = snd_pcm_format_physical_width(src_format) == 24 || snd_pcm_format_physical_width(dst_format) == 24; The commit message of that commit says that this change was supposed to set this flag also for 18 and 20-bit physical width formats. Is there a mistake in this code or am I wrong somewhere in my thinking? Best regards, Maciej

2 2