public inbox for igt-dev@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ser, Simon" <simon.ser@intel.com>
To: "igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>,
	"tvrtko.ursulin@linux.intel.com" <tvrtko.ursulin@linux.intel.com>,
	"martin.peres@linux.intel.com" <martin.peres@linux.intel.com>,
	"Peres, Martin" <martin.peres@intel.com>
Subject: Re: [igt-dev] [PATCH i-g-t v3 09/10] tests/kms_chamelium: add a flatline audio test
Date: Tue, 4 Jun 2019 14:06:40 +0000	[thread overview]
Message-ID: <5c72170b467e0e5b26b182fc670b551d56c1e8a1.camel@intel.com> (raw)
In-Reply-To: <65cc9e2e-30ad-11b2-5119-de41e402a543@linux.intel.com>

On Tue, 2019-06-04 at 13:59 +0100, Tvrtko Ursulin wrote:
> On 04/06/2019 13:26, Peres, Martin wrote:
> > On 04/06/2019 14:22, Ser, Simon wrote:
> > > On Tue, 2019-06-04 at 09:38 +0100, Tvrtko Ursulin wrote:
> > > > On 27/05/2019 15:34, Simon Ser wrote:
> > > > > This commit adds a flatline test alongside the existing frequencies test.
> > > > > 
> > > > > The test sends a constant value and checks that the amplitude is correct. A
> > > > > window is used to check that each sample is within acceptable bounds. The test
> > > > > is stopped as soon as 3 audio pages pass the test.
> > > > > 
> > > > > Signed-off-by: Simon Ser <simon.ser@intel.com>
> > > > > Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
> > > > > ---
> > > > >    tests/kms_chamelium.c | 101 ++++++++++++++++++++++++++++++++++++++++++
> > > > >    1 file changed, 101 insertions(+)
> > > > > 
> > > > > diff --git a/tests/kms_chamelium.c b/tests/kms_chamelium.c
> > > > > index 40ca93687c20..451a616f1a2e 100644
> > > > > --- a/tests/kms_chamelium.c
> > > > > +++ b/tests/kms_chamelium.c
> > > > > @@ -772,6 +772,9 @@ test_display_frame_dump(data_t *data, struct chamelium_port *port)
> > > > >    /* A streak of 3 gives confidence that the signal is good. */
> > > > >    #define MIN_STREAK 3
> > > > >    
> > > > > +#define FLATLINE_AMPLITUDE 0.9 /* normalized, ie. in [0, 1] */
> > > > 
> > > > I assume the test is making triple sure it only ever outputs this signal
> > > > to connectors connected to Chamelium, in all possible scenarios? (I am
> > > > thinking it could be dangerous to some amps/speakers if by some kind of
> > > > accident.)
> > > 
> > > Not at all. The signal is sent to all HDMI/DP ports.
> > > 
> > > I have to check whether it's easy to match ALSA outputs to monitor
> > > names.
> > > 
> > > Martin, is this a concern?
> > 
> > This is true that a non-zero constant voltage could be damaging for
> > speakers as it can make them overheat without us hearing anything
> > (constant position == no sound heard, but Ohm's law still applies). It
> > would take longer than 1s though... On top of this, all speakers (except
> > subwoofers) have high-pass filters that should remove the DC-offset so
> > all we should be left with is a nice pop which might or might not be
> > loud depending on how powerful the speakers are and how loud their
> > settings are. Multi-kW systems definitely don't like them, but how
> > likely is it that people would run IGT on it? :D
> 
> Why would all speakers have high-pass filters? I would be surprised if 
> full range ones do, and N-way definitely do not in their totality. 
> Considering the range of laptop speakers, monitor speakers, TVs, etc, 
> all of varying quality, I'd be quite conservative and cautious before 
> outputting even one second of +90% DC signal. I know it is just IGT and 
> so extremely unlikely that if anything fries it would be anyone apart 
> from us frying our own stuff, but, still, do we have to use DC as test 
> signal?

DC is just so simple. It also allows us to check that all samples are
in a very precise range.

Would it be fine to use a 25% DC?

> > That being said, if we can associate the alsa output to a certain
> > connector (the one we are reading the sound from), then it would
> > actually be a good thing to test the sound on this connector only, since
> > it would allow us to verify that the mapping is indeed correct!
> 
> Yeah.. and why do we even test this in such detail? I mean outputting 
> different signals and stuff. 

Because audio could be broken in a lot of different ways.

> Why not just send a sine wave beep or 
> something and check it was captured? I did not figure out from the 
> commit message why DC.

We already have sine wave tests, but sine waves make it complicated to
check that amplitude is correct for all samples.
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

  reply	other threads:[~2019-06-04 14:06 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-27 14:34 [igt-dev] [PATCH i-g-t v3 00/10] tests/kms_chamelium: add pulse test Simon Ser
2019-05-27 14:34 ` [igt-dev] [PATCH i-g-t v3 01/10] lib/igt_chamelium: introduce CHAMELIUM_MAX_AUDIO_CHANNELS Simon Ser
2019-05-27 14:41   ` Peres, Martin
2019-05-27 14:34 ` [igt-dev] [PATCH i-g-t v3 02/10] tests/kms_chamelium: refactor audio test Simon Ser
2019-05-27 14:34 ` [igt-dev] [PATCH i-g-t v3 03/10] tests/kms_chamelium: introduce audio_state_receive Simon Ser
2019-05-27 14:34 ` [igt-dev] [PATCH i-g-t v3 04/10] tests/kms_chamelium: rename do_test_display_audio and test_audio_configuration Simon Ser
2019-05-27 14:34 ` [igt-dev] [PATCH i-g-t v3 05/10] tests/kms_chamelium: explain why 8-channel tests aren't performed Simon Ser
2019-05-27 14:34 ` [igt-dev] [PATCH i-g-t v3 06/10] lib/igt_audio: introduce audio_convert_to Simon Ser
2019-05-27 14:34 ` [igt-dev] [PATCH i-g-t v3 07/10] tests/kms_chamelium: add name parameter to audio_state_start Simon Ser
2019-05-27 14:34 ` [igt-dev] [PATCH i-g-t v3 08/10] lib/igt_audio: make audio_extract_channel_s32_le support a NULL dst Simon Ser
2019-05-27 14:34 ` [igt-dev] [PATCH i-g-t v3 09/10] tests/kms_chamelium: add a flatline audio test Simon Ser
2019-06-04  8:38   ` Tvrtko Ursulin
2019-06-04 11:22     ` Ser, Simon
2019-06-04 12:26       ` Peres, Martin
2019-06-04 12:59         ` Tvrtko Ursulin
2019-06-04 14:06           ` Ser, Simon [this message]
2019-06-05 10:51             ` Tvrtko Ursulin
2019-06-05 13:04               ` Ser, Simon
2019-06-05 13:30                 ` Tvrtko Ursulin
2019-06-04 14:11         ` Ser, Simon
2019-05-27 14:34 ` [igt-dev] [PATCH i-g-t v3 10/10] tests/kms_chamelium: add audio channel alignment test Simon Ser
2019-05-27 16:03 ` [igt-dev] ✓ Fi.CI.BAT: success for tests/kms_chamelium: add pulse test (rev3) Patchwork
2019-05-28  4:48 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork

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=5c72170b467e0e5b26b182fc670b551d56c1e8a1.camel@intel.com \
    --to=simon.ser@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=martin.peres@intel.com \
    --cc=martin.peres@linux.intel.com \
    --cc=tvrtko.ursulin@linux.intel.com \
    /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