On Thu, Jan 28, 2021 at 11:16 AM Kamil Paral <kparal@redhat.com> wrote:
On Wed, Jan 27, 2021 at 7:35 PM Adam Williamson <adamwill@fedoraproject.org> wrote:
The reason the current criterion specifies "with gstreamer-based
applications" is to avoid being too broad and vague. It really *means*
"sound must basically work", but we're referring to gstreamer on the
basis that:


I do understand the audio criterion quite differently. I believe that an application is an application, while an audio framework is an audio framework. I think that the working sound criterion should apply to audio as in audio framework and not to individual applications, that might be judged according to the "default application functionality" criterion. Therefore, limiting to gstreamer based applications is not important for my point of view.

Currently, a new situation is happening when we will have a new audio framework that should be able to support all kind of applications from gstreamer over alsa to jack, the working sound criterion at the Beta stage should actually read something like: "is the audio server working to produce audio?" Basically, what we are doing now is to test that some default application, like Videos or Rythmbox plays back music, which of course is not much different from "when I go to Gnome Settings and hit TEST on audio tab, I can hear sound coming from the speakers". The criterion I am proposing does not mention any application specifically, so basically it could be met when Gnome Session does "splash splash". We could perhaps automate some tests to check the technical stuff of PipeWire - the services are running, the info commands actually return some info.

What I am trying to say is that if some application does not play sound, while others do, it is clearly a problem in the application and not the sound framework, but if all applications based on one backend (alsa, gstreamer, jack) do not play, the framework might be to blame and therefore the situation might be regarded as blocking even if those applications are not based on gstreamer.

The most important change we are facing now is that PipeWire is here to support everything and if it does not, the operating system has major flaws.


 

I went through several iterations, each time proposing the new criteria completely differently, then realizing something, deleting everything and getting back to the drawing board. I ended up with basically agreeing to keep the Beta criterion untouched :-D It would be too much of a wall of text to explain all my thoughts, but the key takeaways are:
* At Beta, we can't tie this criterion to a specific app (the default video/audio player) or all relevant apps installed by default, because we don't even require them to start. All which must start and function on a *basic* level is a terminal, a web browser (with very limited functionality) and a graphical package manager, that's it. So instead defining this as a class of applications relying on the most common multimedia framework (regardless of whether they are preinstalled or not, because those preinstalled are not required to work) makes sense. Not only that it requires hardware to work, but it also requires at least one app (and the framework) of this class to work, which is fine.
* The default web browser (Firefox) is not among the specified class of applications (it doesn't seem to use gstreamer, according to rpm deps). But that's probably fine, because at Beta we don't really require most apps to work anyway (not even a file browser, haha:)), so requiring working sound in the browser would probably be a stretch anyway (at Beta, it doesn't even have to display video properly atm).
* At Final, everything changes due to the Default application functionality criterion. That takes care of a working sound output for all preinstalled apps on Workstation, and at least the web browser on other desktops.

So, it seems that a working sound output is actually covered well-enough in our criteria (unless we want to be more strict in Beta, but that should be coupled with further changes, if it should make sense).

The recording criterion could then be added into Final:
Final: "The installed system must be able to record audio using the default web browser (if applicable) and gstreamer-based applications."

I chose to call out the web browser, because while most people would probably agree that a working sound output is the expected Default application functionality nowadays, it might not be that clear-cut with a sound input. I believe we really want this due to current teleconferencing needs. Additionally, I used the same approach as with the sound output criterion - refer to gstreamer. Mostly because sound recording apps are not generally pre-installed, so it doesn't make sense to depend on those. This approach also works well with text-based environments (like Server), because the web-browser part doesn't apply there and so you can go and install some of the apps from the covered set and test it.

We should again understand this as "some (not all) gstreamer-based apps must work, showing that the gstreamer framework works and hardware works", so a similar footnote as in the existing Beta criterion ("System-specific bugs") might be needed here as well.

Thoughts?
_______________________________________________
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org


--

Lukáš Růžička

FEDORA QE, RHCE

Red Hat

Purkyňova 115

612 45 Brno - Královo Pole

lruzicka@redhat.com