From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jaroslav Kysela Subject: Re: PulseAudio and softvol Date: Wed, 15 May 2013 12:53:30 +0200 Message-ID: <5193692A.4060007@perex.cz> References: <1368611744.6590.8.camel@localhost> <519362EB.7050603@perex.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail1.perex.cz (mail1.perex.cz [77.48.224.245]) by alsa0.perex.cz (Postfix) with ESMTP id 973C42615D1 for ; Wed, 15 May 2013 12:53:34 +0200 (CEST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Takashi Iwai Cc: Arun Raghavan , alsa-devel@alsa-project.org, pulseaudio-discuss@lists.freedesktop.org List-Id: alsa-devel@alsa-project.org Date 15.5.2013 12:48, Takashi Iwai wrote: > At Wed, 15 May 2013 12:26:51 +0200, > Jaroslav Kysela wrote: >> >> Date 15.5.2013 11:55, Arun Raghavan wrote: >>> Hello, >>> A number of users have intermittently(?) been hitting a crash in >>> alsa-lib 1.0.27 [1, 2] related to the softvol plugin. I'm not able to >>> reproduce this reliably, so can't find an easy way to debug/fix. >> >> The problem is that the offsets are not in sync in this case [1]: >> >> src_offset = 38560 >> dst_offset = 38568 >> frames = 16374 >> >> Could you reproduce this bug in any way? At least snd_pcm_dump() before >> the failing snd_pcm_mmap_commit() call might help to determine what was >> the status before the assert() was entered. > > Yep. And this path is actually with volume 0dB, that is, a simply > passthrough in softvol. Thus the bug may hit essentially any > plugins, not specifically softvol. > > >>> However, this raises a tangential question - why do we need softvol to >>> be plugged for 'front' at all? David explained to me that this is to >>> guarantee the existence of a PCM control. Perhaps I don't fully >>> understand this, because I'm unconvinced by the reason. Could someone >>> explain/refute? >>> >>> This is especially bad for us, from PulseAudio's perspective, because we >>> aren't getting a zero-copy path. >> >> If the softvol is set to 0dB (no attenuation or gain), then the ring >> buffer pointers are moved without any sample processing, so the >> zero-copy functionality is kept. > > Yeah, a sort of. The mmap is cleared in the slave PCM, so actually > there will be copy operations in underlying layers even though softvol > itself does zero copy. > > Actually it makes no sense to keep softvol for PA, but the problem is > always the regression. There are certainly users without PA, which > might still rely on the softvol for such hardware without the amp > control. > > Maybe We can add some flag to indicate whether to handle softvol or > not, e.g. defaults.pcm.skip_softvol, and let PA set this in its config > space. Setting a config item itself would break anything, so it'll > still work with old alsa-lib (but with softvol). We have already SND_PCM_NO_SOFTVOL open mode for this purpose, so I wonder, why PA does not use it.. Jaroslav -- Jaroslav Kysela Linux Kernel Sound Maintainer ALSA Project; Red Hat, Inc.