All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ricard Wanderlof <ricard.wanderlof@axis.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Richard Fitzgerald <rf@opensource.wolfsonmicro.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	David Henningsson <david.henningsson@canonical.com>,
	James Cameron <quozl@laptop.org>
Subject: Re: Splitting out controls
Date: Sun, 18 Oct 2015 08:41:42 +0200	[thread overview]
Message-ID: <alpine.DEB.2.02.1510180836390.24963@lnxricardw1.se.axis.com> (raw)
In-Reply-To: <s5h6125cwl2.wl-tiwai@suse.de>


On Sat, 17 Oct 2015, Takashi Iwai wrote:

> I won't say that we can always save the world.  But there is certainly
> a room for improvement for a little bit more safety than now.  At
> least, if hardware manufacturer or system integrator already knows the
> dangerous part, we should provide some easy way to paper over it.

Is there any form of statistics on more precisely what type of failures in 
this area occur in the real world? Speakers have been mentioned (and I 
think were the original issue that started the discussion) and are a clear 
case. One could imagine output stages being overdriven (even with no load) 
in some way, or mismatched signal levels which could cause an opamp to 
fail for instance. But have any such cases been reported? It would seem 
very hard to diagnose for one thing, unless a hardware manufacturer 
explicitly noted it in some documentation (which I suspect would be very 
unlikely for say a motherboard or sound card manufacturer).

My point is really that it might be a good idea to get some idea of the 
potential failure modes before introducing a mechanism to protect us from 
them.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

  reply	other threads:[~2015-10-18  6:41 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-12 13:49 [Minutes] ELCE Audio mini conf Liam Girdwood
2015-10-12 15:30 ` Jaroslav Kysela
2015-10-12 20:59 ` Splitting out controls James Cameron
2015-10-13  7:07   ` David Henningsson
2015-10-13  8:27     ` Keyon
2015-10-13 14:55     ` Pierre-Louis Bossart
2015-10-13 15:56       ` David Henningsson
2015-10-13 16:08         ` Pierre-Louis Bossart
2015-10-16  6:41           ` David Henningsson
2015-10-16 14:49             ` Pierre-Louis Bossart
2015-10-16 15:24               ` Richard Fitzgerald
2015-10-30  2:48                 ` Mark Brown
2015-10-16 15:28               ` Takashi Iwai
2015-10-14 18:20         ` Liam Girdwood
2015-10-16 15:35     ` Richard Fitzgerald
2015-10-16 16:00       ` Takashi Iwai
2015-10-16 16:31         ` Richard Fitzgerald
2015-10-16 17:00           ` Takashi Iwai
2015-10-17 15:54         ` Pierre-Louis Bossart
2015-10-17 16:02           ` Takashi Iwai
2015-10-18  6:41             ` Ricard Wanderlof [this message]
2015-10-30  2:57               ` Mark Brown
2015-10-17 16:25           ` Alexander E. Patrakov
2015-10-30  2:50       ` Mark Brown
2015-10-30  2:36     ` Mark Brown
2015-10-30  8:36       ` David Henningsson
2015-10-30  8:53         ` James Cameron
2015-10-30  9:04           ` David Henningsson
2015-11-01  2:45             ` Mark Brown
2015-10-13 14:09 ` 'BATCH flag for USB' and 'ALSA Core Challenges' Takashi Sakamoto
2015-10-13 14:44   ` Alexander E. Patrakov
2015-10-18  3:22     ` Takashi Sakamoto
2015-10-13 16:01   ` Pierre-Louis Bossart
2015-10-14 12:27   ` Liam Girdwood
2015-10-22 17:10 ` [Minutes] ELCE Audio mini conf Mark Brown
2015-10-22 17:14 ` DP hotplug on USB C Mark Brown

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=alpine.DEB.2.02.1510180836390.24963@lnxricardw1.se.axis.com \
    --to=ricard.wanderlof@axis.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=david.henningsson@canonical.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=quozl@laptop.org \
    --cc=rf@opensource.wolfsonmicro.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.