public inbox for igt-dev@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Martin Peres <martin.peres@linux.intel.com>
To: "Ser, Simon" <simon.ser@intel.com>,
	"igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>
Subject: Re: [igt-dev] [PATCH i-g-t v4 1/5] tests/kms_chamelium: add dp-audio test
Date: Thu, 25 Apr 2019 12:52:30 +0300	[thread overview]
Message-ID: <b8fb31a3-6707-49cd-51f1-f23d921c301d@linux.intel.com> (raw)
In-Reply-To: <3d1384ab8766c9ad363cfaadd65863f06f19d107.camel@intel.com>

On 17/04/2019 15:57, Ser, Simon wrote:
> On Wed, 2019-04-17 at 15:17 +0300, Martin Peres wrote:
>>>>> +	if (dump_fd >= 0) {
>>>>> +		close(dump_fd);
>>>>> +		if (streak == MIN_STREAK) {
>>>>> +			/* Test succeeded, no need to keep the captured data */
>>>>> +			unlink(dump_path);
>>>>> +		} else
>>>>> +			igt_debug("Saved captured audio data to %s\n", dump_path);
>>>>> +		free(dump_path);
>>>>> +	}
>>>>> +
>>>>> +	free(recv);
>>>>> +	free(buf);
>>>>> +	free(channel);
>>>>> +
>>>>> +	ok = chamelium_stream_stop_realtime_audio(stream);
>>>>> +	igt_assert(ok);
>>>>> +
>>>>> +	audio_file = chamelium_stop_capturing_audio(data->chamelium,
>>>>> +						    port);
>>>>> +	if (audio_file) {
>>>>> +		igt_debug("Audio file saved on the Chamelium in %s\n",
>>>>> +			  audio_file->path);
>>>>> +		chamelium_destroy_audio_file(audio_file);
>>>>> +	}
>>>>
>>>> I would suggest to only dump this file on failure, not when having a
>>>> success.
>>>
>>> 1. We can't decide this after-the-fact: we can only decide whether we
>>>    dump or not before starting the capture.
>>> 2. There are two kinds of audio dumps: local (on the DUT, see dump_fd) 
>>>    and remote (on the Chamelium, see the last param of 
>>>    chamelium_start_capturing_audio). If the file has been dumped on the
>>>    Chamelium, chamelium_stop_capturing_audio will return the audio file
>>>    details. It's sometimes useful to enable Chamelium dumps for
>>>    debugging purposes.
>>
>> Of course! Sorry for the confusion! Where are we dumping the generated
>> and received WAVs when the test is failing then? Is that a TODO?
> 
> So, this is done a little earlier (see the quoted code above). We do
> also dump audio data for tests that succeed, but unlink the file in
> that case. This allows us not to keep all of the captured data in
> memory (dumps are generally worth a couple of MiB) and to keep the code
> simple (no dynamic memory allocation). But honestly I'm not feeling
> strongly about this and I'm open to change it.
> 

OK, so we dump the received the WAV file and we also dump which
frequencies we expected. That should be sufficient!

When IGT learns to store external files in the .json, we'll have to
revisit the test to embed these new files.

Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

  reply	other threads:[~2019-04-25  9:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-11 12:36 [igt-dev] [PATCH i-g-t v4 0/5] tests/kms_chamelium: add dp-audio test Simon Ser
2019-04-11 12:36 ` [igt-dev] [PATCH i-g-t v4 1/5] " Simon Ser
2019-04-16 12:02   ` Martin Peres
2019-04-17  8:40     ` Ser, Simon
2019-04-17 12:17       ` Martin Peres
2019-04-17 12:57         ` Ser, Simon
2019-04-25  9:52           ` Martin Peres [this message]
2019-04-11 12:36 ` [igt-dev] [PATCH i-g-t v4 2/5] tests/kms_chamelium: capture audio data in real-time Simon Ser
2019-04-11 12:36 ` [igt-dev] [PATCH i-g-t v4 3/5] tests/kms_chamelium: test we receive a signal from both audio channels Simon Ser
2019-04-11 12:36 ` [igt-dev] [PATCH i-g-t v4 4/5] tests/kms_chamelium: test audio channels are not mixed up Simon Ser
2019-04-11 12:36 ` [igt-dev] [PATCH i-g-t v4 5/5] tests/kms_chamelium: run audio test with multiple sampling rates Simon Ser
2019-04-11 16:43 ` [igt-dev] ✓ Fi.CI.BAT: success for tests/kms_chamelium: add dp-audio test (rev4) Patchwork
2019-04-11 21:28 ` [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=b8fb31a3-6707-49cd-51f1-f23d921c301d@linux.intel.com \
    --to=martin.peres@linux.intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=simon.ser@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