The goal of openQA is "test as a QA engineer". But openQA has no ears - all we can test for are DTMF sounds. And even those are very bad.

So my hackweek project is to do research on how to do proper sound verification. The keys are proper normalization of the volume and the sample rate.

Looking for hackers with the skills:

Nothing? Add some keywords!

This project is part of:

Hack Week 13

Activity

  • about 9 years ago: fcrozat liked this project.
  • about 9 years ago: mlin7442 liked this project.
  • about 9 years ago: RBrownSUSE liked this project.
  • about 9 years ago: sbahling liked this project.
  • about 9 years ago: dwaas liked this project.
  • about 9 years ago: pgonin liked this project.
  • about 9 years ago: ancorgs liked this project.
  • about 9 years ago: coolo started this project.
  • about 9 years ago: coolo originated this project.

  • Comments

    • tiwai
      about 9 years ago by tiwai | Reply

      There is a new program, BAT, included in alsa-utils and now built as a sub-package on FACTORY. It's designed for the sound verification on the real hardware with the analog loopback, but it might work with QEMU, too.

    • coolo
      about 9 years ago by coolo | Reply

      bat is useful to test within the SUT. But for openQA we also test e.g. firefox and amarok and there bat fails to help me. https://openqa.opensuse.org/tests/103319/modules/firefox_audio/steps/4 shows the typical sound we're playing.

      https://w3.suse.de/~coolo/wavs/ shows the FFT images of both the original and a recorded sound

    • coolo
      about 9 years ago by coolo | Reply

      https://plus.google.com/+StephanKulow/posts/ECfeiT6Je5c

    • coolo
      about 9 years ago by coolo | Reply

      https://openqa.opensuse.org/tests/103530/modules/amarok/steps/18 shows 94% but it looks like a rounding error

    Similar Projects

    This project is one of its kind!