kernel.git/sound/core/pcm_lib.c, branch linux-4.1.y

ALSA: pcm: Remove yet superfluous WARN_ON()

2018-03-01T03:09:38Z

[ Upstream commit 23b19b7b50fe1867da8d431eea9cd3e4b6328c2c ] muldiv32() contains a snd_BUG_ON() (which is morphed as WARN_ON() with debug option) for checking the case of 0 / 0. This would be helpful if this happens only as a logical error; however, since the hw refine is performed with any data set provided by user, the inconsistent values that can trigger such a condition might be passed easily. Actually, syzbot caught this by passing some zero'ed old hw_params ioctl. So, having snd_BUG_ON() there is simply superfluous and rather harmful to give unnecessary confusions. Let's get rid of it. Reported-by: syzbot+7e6ee55011deeebce15d@syzkaller.appspotmail.com Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ALSA: pcm: Remove incorrect snd_BUG_ON() usages

2018-03-01T00:32:22Z

[ Upstream commit fe08f34d066f4404934a509b6806db1a4f700c86 ] syzkaller triggered kernel warnings through PCM OSS emulation at closing a stream: WARNING: CPU: 0 PID: 3502 at sound/core/pcm_lib.c:1635 snd_pcm_hw_param_first+0x289/0x690 sound/core/pcm_lib.c:1635 Call Trace: .... snd_pcm_hw_param_near.constprop.27+0x78d/0x9a0 sound/core/oss/pcm_oss.c:457 snd_pcm_oss_change_params+0x17d3/0x3720 sound/core/oss/pcm_oss.c:969 snd_pcm_oss_make_ready+0xaa/0x130 sound/core/oss/pcm_oss.c:1128 snd_pcm_oss_sync+0x257/0x830 sound/core/oss/pcm_oss.c:1638 snd_pcm_oss_release+0x20b/0x280 sound/core/oss/pcm_oss.c:2431 __fput+0x327/0x7e0 fs/file_table.c:210 .... This happens while it tries to open and set up the aloop device concurrently. The warning above (invoked from snd_BUG_ON() macro) is to detect the unexpected logical error where snd_pcm_hw_refine() call shouldn't fail. The theory is true for the case where the hw_params config rules are static. But for an aloop device, the hw_params rule condition does vary dynamically depending on the connected target; when another device is opened and changes the parameters, the device connected in another side is also affected, and it caused the error from snd_pcm_hw_refine(). That is, the simplest "solution" for this is to remove the incorrect assumption of static rules, and treat such an error as a normal error path. As there are a couple of other places using snd_BUG_ON() incorrectly, this patch removes these spurious snd_BUG_ON() calls. Reported-by: syzbot+6f11c7e2a1b91d466432@syzkaller.appspotmail.com Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ALSA: pcm: update tstamp only if audio_tstamp changed

2017-12-08T23:01:03Z

[ Upstream commit 20e3f985bb875fea4f86b04eba4b6cc29bfd6b71 ] 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 Signed-off-by: Henrik Eriksson Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ALSA: pcm: Avoid "BUG:" string for warnings again

2016-07-11T03:06:56Z

[ Upstream commit 0ab1ace856205d10cbc1924b2d931c01ffd216a6 ] The commit [d507941beb1e: ALSA: pcm: Correct PCM BUG error message] made the warning prefix back to "BUG:" due to its previous wrong prefix. But a kernel message containing "BUG:" seems taken as an Oops message wrongly by some brain-dead daemons, and it annoys users in the end. Instead of teaching daemons, change the string again to a more reasonable one. Fixes: 507941beb1e ('ALSA: pcm: Correct PCM BUG error message') Cc: # v3.19+ Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ALSA: pcm: Modify double acknowledged interrupts check condition

2015-05-19T07:32:29Z

Currently in snd_pcm_update_hw_ptr0 during interrupt, we consider there were double acknowledged interrupts when: 1. HW reported pointer is smaller than expected, and 2. Time from last update time (hdelta) is over half a buffer time. However, when HW reported pointer is only a few bytes smaller than expected, and when hdelta is just a little larger than half a buffer time (e.g. ping-pong buffer), it wrongly treats this IRQ as double acknowledged. The condition #2 uses jiffies, but jiffies is not high resolution since it is integer. We should consider jiffies inaccuracy. Signed-off-by: Koro Chen Signed-off-by: Takashi Iwai

ALSA: core: add .get_time_info

2015-02-20T16:30:05Z

Introduce more generic .get_time_info to retrieve system timestamp and audio timestamp in single routine. Backwards compatibility is preserved with same functionality as with .wall_clock method (to be removed in following commits to avoid breaking git bisect) Signed-off-by: Pierre-Louis Bossart Signed-off-by: Takashi Iwai

Merge tag 'asoc-v3.20-2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next

2015-02-05T06:08:35Z

ASoC: Updates for v3.20 More updates for v3.20: - Lots of refactoring from Lars-Peter Clausen, moving drivers to more data driven initialization and rationalizing a lot of DAPM usage. - Much improved handling of CDCLK clocks on Samsung I2S controllers. - Lots of driver specific cleanups and feature improvements. - CODEC support for TI PCM514x and TLV320AIC3104 devices. - Board support for Tegra systems with Realtek RT5677. Conflicts: sound/soc/intel/sst-mfld-platform-pcm.c

ALSA: pcm: Add snd_interval_ranges() and snd_pcm_hw_constraint_ranges()

2015-01-28T19:27:15Z

Add helper functions to allow drivers to specify several disjoint ranges for a variable. In particular, there is a codec (PCM512x) that has a hole in its supported range of rates, due to PLL and divider restrictions. This is like snd_pcm_hw_constraint_list(), but for ranges instead of points. Signed-off-by: Peter Rosin Reviewed-by: Lars-Peter Clausen Reviewed-by: Takashi Iwai Signed-off-by: Mark Brown

ALSA: Add support for wildcard msbits constraints

2014-12-30T15:27:47Z

Currently the msbits constraints requires to specify a specific sample format width for which the constraint should be applied. But often the number of most significant bits is not sample format specific, but rather a absolute limit. E.g. the PCM interface might accept 32-bit and 24-bit samples, but the DAC has a 16-bit resolution and throws away the LSBs. In this case for both 32-bit and 24-bit format msbits should be set to 16. This patch extends snd_pcm_hw_constraint_msbits() so that a wildcard constraint can be setup that is applied for all formats with a sample width larger than the specified msbits. Choosing the wildcard constraint is done by setting the sample width parameter of the function to 0. Signed-off-by: Lars-Peter Clausen Signed-off-by: Takashi Iwai

ALSA: Fix handling of multiple msbits constraints on the same runtime

2014-12-30T15:27:37Z

If the sound card is made up of discrete components, each with their own driver (e.g. like in the ASoC case), we might end up with multiple msbits constraint rules installed. Currently this will result in msbits being set to whatever the last rule set it to. This patch updates the behavior of the rule to choose the minimum (other than zero) of all the installed rules. Signed-off-by: Lars-Peter Clausen Signed-off-by: Takashi Iwai