Re: Proposal to modify: Working Sound Beta Release Criterion

[Kamil Paral]

On Thu, Jan 28, 2021 at 9:13 PM Kevin Fenzi  wrote:

> pipewire replaces completely pulseaudio and jack _daemons_
>
> ie, now you might have jackd or pulseaudio running, after the switch you
> will just have pipewire. All the pulseaudio clients and jack clients
> talk to pipewire, and think it's their daemon. They still use
> pulseaudio-libs and jack libs to talk it, but pipewire daemon "speaks"
> both those protocols, so as far as they know everything is exactly the
> same.
>
> So, you could adjust your table by making line 4 "Pulseaudio and jack
> clients" or merging 3 and 4 into "pulseaudio, jack or pipewire daemons".
>
> At least thats my understanding.
>

Yes, that's the same info that Lukas Ruzicka got from the Pipewire
developer. Client libraries stay, the daemons/servers are removed. So the
table is correct and incorrect at the same time - layer 4 gets trimmed to
the absolute minimum (just {libpulse,libjack}.so files).

There is also a Pipewire's own API, and so clients can skip layer 4
completely and connect directly to Pipewire.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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

Re: Proposal to modify: Working Sound Beta Release Criterion

[Kamil Paral]

On Fri, Jan 29, 2021 at 3:45 AM Robbi Nespu 
wrote:

> On Arch wiki mentioned "Firefox (84+) supports this method by default,
> while on Chromium (73+) one needs to enable WebRTC PipeWire support by
> setting the corresponding (experimental) flag" this is for WebRTC screen
> sharing, not sure it also can be part of audio testing or  not.
>

You haven't shared the link, but I assume this is all related to
Pipewire-provided screen sharing. Which is a new thing, yes, but it is not
directly relevant to our currently discussed criterion (just audio), IIUIC.


>
> Maybe can use https://test.webrtc.org/ to the the audio recording /
> capture work or not
>

That can be useful, but I guess I wouldn't limit us to just working WebRTC
support (the page can use a direct microphone access without WebRTC, I
don't know how the protocol/API is called), and I'd like to find a web test
which plays back the recorded audio back to you. If you have good
candidates (ideally without logging in), feel free to share them, thanks.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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

Re: Proposal to modify: Working Sound Beta Release Criterion

[Robbi Nespu]

On 28/1/2021 9:55 pm, Lukas Ruzicka wrote:
Ok, after an offline part of discussion with @Kamil Paral 
, we both have agreed that:


 1. The beta criterion for *Working sound *should remain as is now (no
change needed).
 2. We would like to introduce a *new final criterion *saying*: */"The
installed system must be able to record audio using the default web
browser (if applicable) and gstreamer-based applications."/

What do you think?



+1 for me..

On Arch wiki mentioned "Firefox (84+) supports this method by default, 
while on Chromium (73+) one needs to enable WebRTC PipeWire support by 
setting the corresponding (experimental) flag" this is for WebRTC screen 
sharing, not sure it also can be part of audio testing or  not.


Maybe can use https://test.webrtc.org/ to the the audio recording / 
capture work or not




--
Email: Robbi Nespu 
PGP fingerprint : D311 B5FF EEE6 0BE8 9C91 FA9E 0C81 FA30 3B3A 80BA
PGP key : https://keybase.io/robbinespu/pgp_keys.asc


OpenPGP_0x0C81FA303B3A80BA_and_old_rev.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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

Fedora-IoT-33-20210128.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/15 (aarch64)

Old failures (same test failed in Fedora-IoT-33-20210121.0):

ID: 764536  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/764536

Soft failed openQA tests: 1/16 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-IoT-33-20210121.0):

ID: 764520  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/764520

Passed openQA tests: 14/15 (aarch64), 15/16 (x86_64)

New passes (same test not passed in Fedora-IoT-33-20210121.0):

ID: 764538  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/764538
ID: 764549  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/764549
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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

Re: Proposal to modify: Working Sound Beta Release Criterion

[Kevin Fenzi]

On Thu, Jan 28, 2021 at 02:10:47PM +0100, Lukas Ruzicka wrote:
> >
> >
> > I think there's a misunderstanding in how all the "frameworks" and stacked
> > on top of each other. I'm not very knowledgeable in this area, but I think
> > the layers are more or less like this:
> >
> > 6. Totem | Firefox | Rhythmbox | Audacity
> > --
> > 5. GStreamer | FFmpeg
> > --
> > 4. PulseAudio | JACK
> > --
> > 3. Pipewire
> > --
> > 2. ALSA | OSS
> > --
> > 1. Hardware
> >
> 
> This is from the headlines at pipewire.org:
> *PipeWire provides a low-latency, graph based processing engine on top of
> audio and video devices that can be used to support the use cases currently
> handled by both pulseaudio and JACK.*
> 
> To me, this sounds more like a replacement of the layer 4 (at least). Am I
> wrong to think that devices = hardware? Also, what Wim has told me "*PipeWire
> should be an under-the-hood change. No workflow or tools or apis are
> changed, so we still use pulseaudio API, jack API, jack tools and
> pulseaudio tools for everything. Evaluation of this should be on how
> similar the old setup was to the new one, there should ideally be no
> difference, nobody should notice a change, ideally.*" does not have to
> imply that "sound data" go to PulseAudio first and then to PipeWire. I
> believe that PipeWire mimics the PulseAudio ports to handle the situation
> by itself. However, I was not able to find any accurate description of how
> that actually works in the system, so if you have a link to a place where
> the above diagram is to be seen or confirmed, please share it.

pipewire replaces completely pulseaudio and jack _daemons_

ie, now you might have jackd or pulseaudio running, after the switch you
will just have pipewire. All the pulseaudio clients and jack clients
talk to pipewire, and think it's their daemon. They still use
pulseaudio-libs and jack libs to talk it, but pipewire daemon "speaks"
both those protocols, so as far as they know everything is exactly the
same. 

So, you could adjust your table by making line 4 "Pulseaudio and jack
clients" or merging 3 and 4 into "pulseaudio, jack or pipewire daemons".

At least thats my understanding. 

kevin


signature.asc
Description: PGP signature
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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

Re: Proposal to modify: Working Sound Beta Release Criterion

[Adam Williamson]

On Thu, 2021-01-28 at 14:55 +0100, Lukas Ruzicka wrote:
> Ok, after an offline part of discussion with @Kamil Paral
> , we both have agreed that:
> 
> 
>    1. The beta criterion for *Working sound *should remain as is now (no
>    change needed).
>    2. We would like to introduce a *new final criterion *saying*: **"The
>    installed system must be able to record audio using the default web browser
>    (if applicable) and gstreamer-based applications."*
> 
> What do you think?

+1 for me.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net


___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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

Re: Proposal to modify: Working Sound Beta Release Criterion

[Adam Williamson]

On Thu, 2021-01-28 at 13:27 +0100, Kamil Paral wrote:
> On Thu, Jan 28, 2021 at 12:36 PM Lukas Ruzicka  wrote:
> 
> > 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 think there's a misunderstanding in how all the "frameworks" and stacked
> on top of each other. I'm not very knowledgeable in this area, but I think
> the layers are more or less like this:
> 
> 6. Totem | Firefox | Rhythmbox | Audacity
> --
> 5. GStreamer | FFmpeg
> --
> 4. PulseAudio | JACK
> --
> 3. Pipewire
> --
> 2. ALSA | OSS
> --
> 1. Hardware

AIUI, PulseAudio, JACK and Pipewire are all alternatives at the level
between "ALSA | OSS" and "GStreamer | FFmpeg", and there is only one
level there. Pipewire does not "sit under" PulseAudio and/or JACK, it
is an alternative to them.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net


___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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

Re: Proposal to modify: Working Sound Beta Release Criterion

[Adam Williamson]

On Thu, 2021-01-28 at 12:33 +0100, Lukas Ruzicka wrote:
> 
> 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.*

...but for the last several years we've been in effectively the same
situation only with Pulseaudio, so this isn't much of a change at all?
You could just as well say of Fedora 33 "Pulseaudio is here to support
everything and if it does not, the operating system has major flaws".
The only real difference between PA and PW from that point of view is
that PW also replaces JACK, but JACK was only used by some very
'professional' things we wouldn't have blocked the release for anyway.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net


___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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

Re: Proposal to modify: Working Sound Beta Release Criterion

[Jan K]

Sounds good to me.

Jan


From: Lukas Ruzicka 
Sent: Thursday, January 28, 2021 3:55 PM
To: For testing and quality assurance of Fedora releases 
; Kamil Paral 
Subject: Re: Proposal to modify: Working Sound Beta Release Criterion

Ok, after an offline part of discussion with @Kamil 
Paral, we both have agreed that:


  1.  The beta criterion for Working sound should remain as is now (no change 
needed).
  2.  We would like to introduce a new final criterion saying: "The installed 
system must be able to record audio using the default web browser (if 
applicable) and gstreamer-based applications."

What do you think?

On Thu, Jan 28, 2021 at 2:10 PM Lukas Ruzicka 
mailto:lruzi...@redhat.com>> wrote:



I think there's a misunderstanding in how all the "frameworks" and stacked on 
top of each other. I'm not very knowledgeable in this area, but I think the 
layers are more or less like this:

6. Totem | Firefox | Rhythmbox | Audacity
--
5. GStreamer | FFmpeg
--
4. PulseAudio | JACK
--
3. Pipewire
--
2. ALSA | OSS
--
1. Hardware

This is from the headlines at pipewire.org:
PipeWire provides a low-latency, graph based processing engine on top of audio 
and video devices that can be used to support the use cases currently handled 
by both pulseaudio and JACK.

To me, this sounds more like a replacement of the layer 4 (at least). Am I 
wrong to think that devices = hardware? Also, what Wim has told me "PipeWire 
should be an under-the-hood change. No workflow or tools or apis are changed, 
so we still use pulseaudio API, jack API, jack tools and pulseaudio tools for 
everything. Evaluation of this should be on how similar the old setup was to 
the new one, there should ideally be no difference, nobody should notice a 
change, ideally." does not have to imply that "sound data" go to PulseAudio 
first and then to PipeWire. I believe that PipeWire mimics the PulseAudio ports 
to handle the situation by itself. However, I was not able to find any accurate 
description of how that actually works in the system, so if you have a link to 
a place where the above diagram is to be seen or confirmed, please share it.



The application from layer 6 of course doesn't need to use any framework from 
layer 5, it can talk to lower layers directly (it can talk directly even to 
ALSA on layer 2, but then you lose some benefits, like software sound 
multiplexing). But the important thing to notice is that gstreamer, ffmpeg, etc 
are way above Pipewire.

If we pick a particular app and say "app X must be able to play sound at Beta" 
(or alternatively "you must be able to find an app that plays sound at Beta"), 
that app X might talk directly to e.g. PulseAudio and while it works, you might 
not detect that 90% of other apps using a framework like gstreamer don't work. 
That's why I believe gstreamer is mentioned in the criterion, because it 
ensures that a) hardware works properly, and b) that a large portion of our 
apps are likely to work properly as well (once you test at least one of them).

So ideally, I would like to avoid the situation where application X is fine, 
because it talks to a different layer than some other application, but the 
application Y has no sound as it talks to a different layer. However this could 
be tested in the scope of the Audio Test Day, because it creates quite a lot of 
combinations for daily validation testing.

Of course saying "at least one app must be able to produce sound" (which is 
basically what you proposed in the first email) is also valid, it's just a 
weaker version of that criterion (it will validate hardware and some low levels 
like Pipewire and ALSA, but it might or might not validate nothing above it). 
Audacity is a good example of an app using layer 4 at most, so layer 5 would 
not be covered.

Audacity basically could be an application that could check almost everything, 
because you can set it up to talk to ALSA directly, JACK or PulseAudio, 
depending on the settings. The quality of the recording experience might differ 
however.
This is of course above the scope of our testing.


Perhaps I'm misunderstanding you, but it seems to me that the current criterion 
is very much in line with what you're saying you want to do. It tests something 
from the (almost) very top all the way down to the bottom.

Originally, my motivation was to introduce a recording criterion and couple it 
with the playback criterion, but since there is no recording application 
installed by default and most audio applications with recording support do not 
rely on gstreamer, I thought decoupling the gstreamer thing would help it.

However, if you suggest that a recording test should mean to check that a sound 
could be captured by Firefox, then we actually do not need anything. We say 
that capturing sound 

Fedora-Rawhide-20210128.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp
Xfce raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
7 of 43 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 34/181 (x86_64), 35/123 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20210127.n.1):

ID: 763643  Test: x86_64 Server-dvd-iso mediakit_fileconflicts
URL: https://openqa.fedoraproject.org/tests/763643
ID: 763690  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/763690
ID: 763692  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/763692
ID: 763704  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/763704
ID: 763735  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/763735
ID: 763749  Test: aarch64 Minimal-raw_xz-raw.xz 
base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/763749
ID: 763754  Test: aarch64 Server-dvd-iso mediakit_fileconflicts@uefi
URL: https://openqa.fedoraproject.org/tests/763754
ID: 763771  Test: aarch64 Server-dvd-iso 
server_role_deploy_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/763771
ID: 763778  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/763778
ID: 763786  Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/763786
ID: 763788  Test: aarch64 Server-dvd-iso modularity_tests@uefi
URL: https://openqa.fedoraproject.org/tests/763788
ID: 763789  Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/763789
ID: 763790  Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/763790
ID: 763819  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/763819

Old failures (same test failed in Fedora-Rawhide-20210127.n.1):

ID: 763652  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/763652
ID: 763657  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/763657
ID: 763669  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/763669
ID: 763670  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/763670
ID: 763673  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/763673
ID: 763679  Test: x86_64 Server-dvd-iso server_cockpit_updates
URL: https://openqa.fedoraproject.org/tests/763679
ID: 763680  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/763680
ID: 763681  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/763681
ID: 763683  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/763683
ID: 763695  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/763695
ID: 763703  Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/763703
ID: 763706  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/763706
ID: 763756  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/763756
ID: 763758  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/763758
ID: 763759  Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/763759
ID: 763763  Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/763763
ID: 763782  Test: aarch64 Server-dvd-iso install_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/763782
ID: 763785  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/763785
ID: 763824  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/763824
ID: 763826  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/763826
ID: 763827  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/763827
ID: 763829  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/763829
ID: 763830  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/763830
ID: 

Re: Proposal to modify: Working Sound Beta Release Criterion

[Lukas Ruzicka]

Ok, after an offline part of discussion with @Kamil Paral
, we both have agreed that:


   1. The beta criterion for *Working sound *should remain as is now (no
   change needed).
   2. We would like to introduce a *new final criterion *saying*: **"The
   installed system must be able to record audio using the default web browser
   (if applicable) and gstreamer-based applications."*

What do you think?

On Thu, Jan 28, 2021 at 2:10 PM Lukas Ruzicka  wrote:

>
>
>>
>> I think there's a misunderstanding in how all the "frameworks" and
>> stacked on top of each other. I'm not very knowledgeable in this area, but
>> I think the layers are more or less like this:
>>
>> 6. Totem | Firefox | Rhythmbox | Audacity
>> --
>> 5. GStreamer | FFmpeg
>> --
>> 4. PulseAudio | JACK
>> --
>> 3. Pipewire
>> --
>> 2. ALSA | OSS
>> --
>> 1. Hardware
>>
>
> This is from the headlines at pipewire.org:
> *PipeWire provides a low-latency, graph based processing engine on top of
> audio and video devices that can be used to support the use cases currently
> handled by both pulseaudio and JACK.*
>
> To me, this sounds more like a replacement of the layer 4 (at least). Am I
> wrong to think that devices = hardware? Also, what Wim has told me "*PipeWire
> should be an under-the-hood change. No workflow or tools or apis are
> changed, so we still use pulseaudio API, jack API, jack tools and
> pulseaudio tools for everything. Evaluation of this should be on how
> similar the old setup was to the new one, there should ideally be no
> difference, nobody should notice a change, ideally.*" does not have to
> imply that "sound data" go to PulseAudio first and then to PipeWire. I
> believe that PipeWire mimics the PulseAudio ports to handle the situation
> by itself. However, I was not able to find any accurate description of how
> that actually works in the system, so if you have a link to a place where
> the above diagram is to be seen or confirmed, please share it.
>
>
>
>>
>> The application from layer 6 of course doesn't need to use any framework
>> from layer 5, it can talk to lower layers directly (it can talk directly
>> even to ALSA on layer 2, but then you lose some benefits, like software
>> sound multiplexing). But the important thing to notice is that gstreamer,
>> ffmpeg, etc are way above Pipewire.
>>
>> If we pick a particular app and say "app X must be able to play sound at
>> Beta" (or alternatively "you must be able to find an app that plays sound
>> at Beta"), that app X might talk directly to e.g. PulseAudio and while it
>> works, you might not detect that 90% of other apps using a framework like
>> gstreamer don't work. That's why I believe gstreamer is mentioned in the
>> criterion, because it ensures that a) hardware works properly, and b) that
>> a large portion of our apps are likely to work properly as well (once you
>> test at least one of them).
>>
>
> So ideally, I would like to avoid the situation where application X is
> fine, because it talks to a different layer than some other application,
> but the application Y has no sound as it talks to a different layer.
> However this could be tested in the scope of the Audio Test Day, because it
> creates quite a lot of combinations for daily validation testing.
>
> Of course saying "at least one app must be able to produce sound" (which
>> is basically what you proposed in the first email) is also valid, it's just
>> a weaker version of that criterion (it will validate hardware and some low
>> levels like Pipewire and ALSA, but it might or might not validate nothing
>> above it). Audacity is a good example of an app using layer 4 at most, so
>> layer 5 would not be covered.
>>
>
> Audacity basically could be an application that could check almost
> everything, because you can set it up to talk to ALSA directly, JACK or
> PulseAudio, depending on the settings. The quality of the recording
> experience might differ however.
> This is of course above the scope of our testing.
>
>
>>
>> Perhaps I'm misunderstanding you, but it seems to me that the current
>> criterion is very much in line with what you're saying you want to do. It
>> tests something from the (almost) very top all the way down to the bottom.
>>
>
> Originally, my motivation was to introduce a recording criterion and
> couple it with the playback criterion, but since there is no recording
> application installed by default and most audio applications with recording
> support do not rely on gstreamer, I thought decoupling the gstreamer thing
> would help it.
>
> However, if you suggest that a recording test should mean to check that a
> sound could be captured by Firefox, then we actually do not need anything.
> We say that capturing sound is the "default functionality" of firefox and
> hey, we are set. no changes needed.
>
>
>
>> ___
>> test 

Re: Proposal to modify: Working Sound Beta Release Criterion

[Lukas Ruzicka]

>
>
> I think there's a misunderstanding in how all the "frameworks" and stacked
> on top of each other. I'm not very knowledgeable in this area, but I think
> the layers are more or less like this:
>
> 6. Totem | Firefox | Rhythmbox | Audacity
> --
> 5. GStreamer | FFmpeg
> --
> 4. PulseAudio | JACK
> --
> 3. Pipewire
> --
> 2. ALSA | OSS
> --
> 1. Hardware
>

This is from the headlines at pipewire.org:
*PipeWire provides a low-latency, graph based processing engine on top of
audio and video devices that can be used to support the use cases currently
handled by both pulseaudio and JACK.*

To me, this sounds more like a replacement of the layer 4 (at least). Am I
wrong to think that devices = hardware? Also, what Wim has told me "*PipeWire
should be an under-the-hood change. No workflow or tools or apis are
changed, so we still use pulseaudio API, jack API, jack tools and
pulseaudio tools for everything. Evaluation of this should be on how
similar the old setup was to the new one, there should ideally be no
difference, nobody should notice a change, ideally.*" does not have to
imply that "sound data" go to PulseAudio first and then to PipeWire. I
believe that PipeWire mimics the PulseAudio ports to handle the situation
by itself. However, I was not able to find any accurate description of how
that actually works in the system, so if you have a link to a place where
the above diagram is to be seen or confirmed, please share it.



>
> The application from layer 6 of course doesn't need to use any framework
> from layer 5, it can talk to lower layers directly (it can talk directly
> even to ALSA on layer 2, but then you lose some benefits, like software
> sound multiplexing). But the important thing to notice is that gstreamer,
> ffmpeg, etc are way above Pipewire.
>
> If we pick a particular app and say "app X must be able to play sound at
> Beta" (or alternatively "you must be able to find an app that plays sound
> at Beta"), that app X might talk directly to e.g. PulseAudio and while it
> works, you might not detect that 90% of other apps using a framework like
> gstreamer don't work. That's why I believe gstreamer is mentioned in the
> criterion, because it ensures that a) hardware works properly, and b) that
> a large portion of our apps are likely to work properly as well (once you
> test at least one of them).
>

So ideally, I would like to avoid the situation where application X is
fine, because it talks to a different layer than some other application,
but the application Y has no sound as it talks to a different layer.
However this could be tested in the scope of the Audio Test Day, because it
creates quite a lot of combinations for daily validation testing.

Of course saying "at least one app must be able to produce sound" (which is
> basically what you proposed in the first email) is also valid, it's just a
> weaker version of that criterion (it will validate hardware and some low
> levels like Pipewire and ALSA, but it might or might not validate nothing
> above it). Audacity is a good example of an app using layer 4 at most, so
> layer 5 would not be covered.
>

Audacity basically could be an application that could check almost
everything, because you can set it up to talk to ALSA directly, JACK or
PulseAudio, depending on the settings. The quality of the recording
experience might differ however.
This is of course above the scope of our testing.


>
> Perhaps I'm misunderstanding you, but it seems to me that the current
> criterion is very much in line with what you're saying you want to do. It
> tests something from the (almost) very top all the way down to the bottom.
>

Originally, my motivation was to introduce a recording criterion and couple
it with the playback criterion, but since there is no recording application
installed by default and most audio applications with recording support do
not rely on gstreamer, I thought decoupling the gstreamer thing would help
it.

However, if you suggest that a recording test should mean to check that a
sound could be captured by Firefox, then we actually do not need anything.
We say that capturing sound is the "default functionality" of firefox and
hey, we are set. no changes needed.



> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@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

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 

Fedora rawhide compose report: 20210128.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20210127.n.1
NEW: Fedora-Rawhide-20210128.n.0

= SUMMARY =
Added images:2
Dropped images:  0
Added packages:  0
Dropped packages:1
Upgraded packages:   156
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:53.45 KiB
Size of upgraded packages:   4.52 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -130.86 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: KDE_Appliance raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20210128.n.0-sda.raw.xz
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20210128.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: golang-gopkg-ldap-3-3.2.4-1.fc34
Summary: Basic LDAP v3 functionality for the GO programming language
RPMs:golang-gopkg-ldap-3-devel
Size:53.45 KiB


= UPGRADED PACKAGES =
Package:  dl-fedora-0.7.6-1.fc34
Old package:  dl-fedora-0.7.5-1.fc34
Summary:  Fedora image download tool
RPMs: dl-fedora
Size: 28.28 MiB
Size change:  3.80 KiB
Changelog:
  * Tue Jan 26 2021 Fedora Release Engineering  - 
0.7.5-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

  * Wed Jan 27 2021 Jens Petersen  - 0.7.6-1
  - improve help text for releases related for Beta and RCs (#1)
  - if ~/Downloads/iso/ exists then download to it otherwise ~/Downloads/
  - support ELN boot.iso


Package:  dummy-test-package-gloster-0-2529.fc34
Old package:  dummy-test-package-gloster-0-2527.fc34
Summary:  Dummy Test Package called Gloster
RPMs: dummy-test-package-gloster
Size: 159.56 KiB
Size change:  112 B
Changelog:
  * Wed Jan 27 2021 packagerbot  - 0-2528
  - rebuilt

  * Wed Jan 27 2021 packagerbot  - 0-2529
  - rebuilt


Package:  fennel-0.8.0-1.fc34
Old package:  fennel-0.7.0-2.fc34
Summary:  A Lisp that compiles to Lua
RPMs: fennel
Size: 83.54 KiB
Size change:  4.35 KiB
Changelog:
  * Tue Jan 26 2021 Fedora Release Engineering  - 
0.7.0-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

  * Wed Jan 27 2021 Michel Alexandre Salim  - 0.8.0-1
  - Update to 0.8.0
  - Add Requires on lua(abi) for older releases


Package:  golang-github-ldap-3.2.4-4.fc34
Old package:  golang-github-ldap-3.2.4-2.fc34
Summary:  Basic LDAP v3 functionality for the GO programming language
RPMs: compat-golang-gopkg-ldap-3-devel golang-github-ldap-3-devel
Added RPMs:   golang-github-ldap-3-devel
Dropped RPMs: golang-github-ldap-devel
Size: 56.98 KiB
Size change:  -14.46 KiB
Changelog:
  * Tue Jan 26 2021 Fedora Release Engineering  - 
3.2.4-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

  * Wed Jan 27 2021 Robert-Andr?? Mauchin  - 3.2.4-4
  - Add proper import path


Package:  golang-github-moby-sys-0.2.0-3.git5a29239.20210127git5a29239.fc34
Old package:  golang-github-moby-sys-0.2.0-1.fc34
Summary:  Moby sys package for Go
RPMs: golang-github-moby-sys-devel
Size: 54.06 KiB
Size change:  6.81 KiB
Changelog:
  * Tue Jan 26 2021 Fedora Release Engineering  - 
0.2.0-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

  * Wed Jan 27 2021 Olivier Lemasle  - 0.3.0-2.git5a29239
  - Update to latest upstream commit


Package:  golang-github-nxadm-tail-1.4.6-2.fc34
Old package:  golang-github-nxadm-tail-1.4.6-1.fc34
Summary:  Read from continously updated files (tail -f)
RPMs: golang-github-nxadm-tail golang-github-nxadm-tail-devel
Size: 3.27 MiB
Size change:  6.91 KiB
Changelog:
  * Tue Jan 26 2021 Fedora Release Engineering  - 
1.4.6-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild


Package:  golang-github-siddontang-0-0.2.20210111gitbdc7756.fc34
Old package:  golang-github-siddontang-0-0.1.20210111gitbdc7756.fc34
Summary:  Golang lib for ledisdb
RPMs: golang-github-siddontang-devel
Size: 74.77 KiB
Size change:  151 B
Changelog:
  * Tue Jan 26 2021 Fedora Release Engineering  - 
0-0.2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild


Package:  golang-google-grpc-1.35.0-2.fc34
Old package:  golang-google-grpc-1.35.0-1.fc34
Summary:  Go language implementation of GRPC
RPMs: golang-google-grpc-devel golang-google-grpc-status-devel
Size: 887.94 KiB
Size change:  356 B
Changelog:
  * Tue Jan 26 2021 Fedora Release Engineering  - 
1.35.0-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild


Package:  golang-gopkg-playground-validator-8-8.18.2-5.fc34
Old package:  golang-gopkg-playground-validator-8-8.18.2-4.fc33
Summary:  Go struct and field validation
RPMs: golang-gopkg-playground-validator-8-devel
Size: 48.26 KiB
Size change:  170 B
Changelog:
  * Tue Jan 26 2021 Fedora Release Engineering

Fedora-IoT-34-20210128.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd aarch64
Iot dvd x86_64

Failed openQA tests: 3/16 (x86_64), 7/15 (aarch64)

New failures (same test not failed in Fedora-IoT-34-20210124.0):

ID: 763622  Test: x86_64 IoT-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/763622
ID: 763627  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/763627
ID: 763630  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/763630
ID: 763633  Test: aarch64 IoT-dvd_ostree-iso base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/763633
ID: 763636  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi
URL: https://openqa.fedoraproject.org/tests/763636

Old failures (same test failed in Fedora-IoT-34-20210124.0):

ID: 763616  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/763616
ID: 763620  Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_overlay
URL: https://openqa.fedoraproject.org/tests/763620
ID: 763624  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/763624
ID: 763631  Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/763631
ID: 763635  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/763635

Soft failed openQA tests: 1/16 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-IoT-34-20210124.0):

ID: 763608  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/763608

Passed openQA tests: 8/15 (aarch64), 12/16 (x86_64)

New passes (same test not passed in Fedora-IoT-34-20210124.0):

ID: 763638  Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/763638

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
System load changed from 0.20 to 0.37
Previous test data: https://openqa.fedoraproject.org/tests/761403#downloads
Current test data: https://openqa.fedoraproject.org/tests/763609#downloads

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
Mount /run contents changed to 85.01342446% of previous size
Mount /boot contents changed to 136.8907862% of previous size
Used mem changed from 168 MiB to 312 MiB
System load changed from 0.15 to 0.62
Previous test data: https://openqa.fedoraproject.org/tests/761419#downloads
Current test data: https://openqa.fedoraproject.org/tests/763625#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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

[Test-Announce] Fedora 34 Rawhide 20210128.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 34 Rawhide 20210128.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
parted - 20210124.n.0: parted-3.3.52-1.fc34.src, 20210128.n.0: 
parted-3.4-1.fc34.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/34

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210128.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210128.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210128.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210128.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210128.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210128.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20210128.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-announce@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@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-announce@lists.fedoraproject.org

Re: Proposal to modify: Working Sound Beta Release Criterion

[Kamil Paral]

On Thu, Jan 28, 2021 at 12:36 PM Lukas Ruzicka  wrote:

> 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 think there's a misunderstanding in how all the "frameworks" and stacked
on top of each other. I'm not very knowledgeable in this area, but I think
the layers are more or less like this:

6. Totem | Firefox | Rhythmbox | Audacity
--
5. GStreamer | FFmpeg
--
4. PulseAudio | JACK
--
3. Pipewire
--
2. ALSA | OSS
--
1. Hardware

The application from layer 6 of course doesn't need to use any framework
from layer 5, it can talk to lower layers directly (it can talk directly
even to ALSA on layer 2, but then you lose some benefits, like software
sound multiplexing). But the important thing to notice is that gstreamer,
ffmpeg, etc are way above Pipewire.

If we pick a particular app and say "app X must be able to play sound at
Beta" (or alternatively "you must be able to find an app that plays sound
at Beta"), that app X might talk directly to e.g. PulseAudio and while it
works, you might not detect that 90% of other apps using a framework like
gstreamer don't work. That's why I believe gstreamer is mentioned in the
criterion, because it ensures that a) hardware works properly, and b) that
a large portion of our apps are likely to work properly as well (once you
test at least one of them).

Of course saying "at least one app must be able to produce sound" (which is
basically what you proposed in the first email) is also valid, it's just a
weaker version of that criterion (it will validate hardware and some low
levels like Pipewire and ALSA, but it might or might not validate nothing
above it). Audacity is a good example of an app using layer 4 at most, so
layer 5 would not be covered.

Perhaps I'm misunderstanding you, but it seems to me that the current
criterion is very much in line with what you're saying you want to do. It
tests something from the (almost) very top all the way down to the bottom.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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

Re: Proposal to modify: Working Sound Beta Release Criterion

[Lukas Ruzicka]

On Thu, Jan 28, 2021 at 11:16 AM Kamil Paral  wrote:

> On Wed, Jan 27, 2021 at 7:35 PM Adam Williamson <
> adamw...@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 

Re: Proposal to modify: Working Sound Beta Release Criterion

[Kamil Paral]

On Wed, Jan 27, 2021 at 7:35 PM Adam Williamson 
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:
>
> 1. It's the framework our primary desktops and apps use
> 2. It is actively maintained and can reasonably be expected to keep
> working *as a framework*
>

> ...so it excludes problems like "this app's audio code just doesn't
> work" or "this app uses some obscure framework that isn't maintained
> properly and isn't working" from being potentially considered blockers
>
while making sure that if *some* random app can play audio but all
> gstreamer apps are broken, we should consider *that* a blocker.
>

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-le...@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

Re: Proposal to modify: Working Sound Beta Release Criterion

[Kamil Paral]

On Wed, Jan 27, 2021 at 7:39 PM Jan K  wrote:

> It would be nice to have working sound on virtual machines as well. If you
> could add instructions or note(s) whether this would be possible at this
> stage it would be appreciated.
> If it should work, it could be tested as well.
>

Hi Jan,
unless explicitly specified, the release criteria apply both to bare metal
and virtual machines, so this criterion would apply to both as well. If it
happens that sound from VMs is broken in general, but works on bare metal,
it's a similar situation as when e.g. a certain audio chipset is affected
on bare metal and all others work fine - it's a conditional violation. We
would consider the problem during a blocker-review meeting, try to guess
how many people it affects and whether there are some workarounds, and
decide whether it should be a blocker (and at which stage) or not.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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