Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jaroslav Kysela <perex@perex.cz>
To: Takashi Iwai <tiwai@suse.de>
Cc: Arun Raghavan <arun.raghavan@collabora.co.uk>,
	alsa-devel@alsa-project.org,
	pulseaudio-discuss@lists.freedesktop.org
Subject: Re: PulseAudio and softvol
Date: Wed, 15 May 2013 12:53:30 +0200	[thread overview]
Message-ID: <5193692A.4060007@perex.cz> (raw)
In-Reply-To: <s5hd2ssmsd2.wl%tiwai@suse.de>

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 <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.

  reply	other threads:[~2013-05-15 10:53 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-15  9:55 PulseAudio and softvol Arun Raghavan
2013-05-15 10:26 ` Jaroslav Kysela
2013-05-15 10:48   ` Takashi Iwai
2013-05-15 10:53     ` Jaroslav Kysela [this message]
2013-05-15 10:56       ` Takashi Iwai
2013-05-15 11:03       ` David Henningsson
2013-05-15 11:22         ` Jaroslav Kysela
2013-05-15 11:33           ` David Henningsson
2013-05-15 12:44             ` Takashi Iwai
2013-05-15 12:42           ` Takashi Iwai
2013-05-15 12:47             ` David Henningsson
2013-05-15 12:49               ` Takashi Iwai
2013-05-15 12:52               ` Jaroslav Kysela
2013-05-15 13:05                 ` Takashi Iwai
2013-05-15 13:12                   ` Jaroslav Kysela
2013-05-15 13:26                     ` Takashi Iwai
2013-05-15 14:55                       ` Jaroslav Kysela
2013-05-15 15:06                         ` Takashi Iwai
2013-05-15 15:25                           ` Jaroslav Kysela
2013-05-15 16:28                             ` Takashi Iwai
2013-05-16  6:31                               ` David Henningsson
2013-05-16 10:58                                 ` Jaroslav Kysela
2013-06-26  6:59                                 ` [alsa-devel] " Arun Raghavan
2013-06-26  8:35                                   ` David Henningsson
2013-05-15 13:01   ` Arun Raghavan
2013-05-15 16:34 ` [pulseaudio-discuss] " Raymond Yau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5193692A.4060007@perex.cz \
    --to=perex@perex.cz \
    --cc=alsa-devel@alsa-project.org \
    --cc=arun.raghavan@collabora.co.uk \
    --cc=pulseaudio-discuss@lists.freedesktop.org \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox