Re: Fedora Audio Test Cases for Test Day (a proposal)

[Brandon Nielsen]

On 1/20/21 6:56 AM, Kamil Paral wrote:
> On Tue, Jan 19, 2021 at 2:26 PM Lukas Ruzicka <[e-mail] 
> > wrote:
> Hello friends of Fedora,
>
> the following is a proposal for the test scope of PipeWire audio
> in Fedora, which could be tested as part of Fedora Audio Test
> Days. Please let me know what you think about it.
> Particular test cases have not been developed yet, but as soon as
> I have the idea what is actually desired for testing, I will
> develop them and prepare them as a material for test days.
>
> Thanks for cooperation,
> Lukas
>
>
> ====
>
>
>   Test Cases for Test Days (proposal)
>
>
>     Description
>
> The following is a proposal for test cases that could be tested as
> a part of a Fedora Audio Test Day.
>
>
>     Possible test cases
>
> 1.
>
>     *PipeWire is used by default.* This test case should test that
>     audio is controlled by PipeWire by default.
>
> 2.
>
>     *There are GUI and CLI tools to control sound available to the
>     user*. This test case tests that sound production can be
>     controlled using different tools.
>
> 3.
>
>     *Sound can be played back from all applications* – this test
>     case tests that any audio application installable from Fedora
>     repositories with a proper setup must produce audible sounds
>     of expected quality using the selected hardware. This will
>     cover the majority of JACK or ALSA based applications.
>
> 4.
>
>     *Sound can be recorded in all applications* – this test case
>     tests that any audio application installable from Fedora
>     repositories is able to record sound from the external sources
>     in expected quality. This will also affect default
>     applications, such as Firefox, that is used for conferencing
>     and the ability to receive sound is crucial for this use case.
>
> 5.
>
>     *Dedicated hardware can be used to produce or record audio* –
>     any dedicated audio hardware, especially soundcards, must play
>     audible sounds of expected quality, as well as record them, if
>     they have been successfully recognized by the operating system.
>
> 6.
>
>     *MIDI capable hardware communicates with the MIDI capable
>     applications* – if the MIDI capable hardware is properly
>     recognized by the system, it must be able to communicate with
>     an application. However, it should not ever be required that
>     the application understands that communication fully and
>     without issues.
>
>
>
> I'm not a sound expert, but the list looks reasonable.

Would some kind of device switching test case be feasible? In my 
experience that's where a lot of weird behavior creeps in. For example, 
plugging in a USB interface, using it, and unplugging it. Or switching 
back and forth between Bluetooth and wired hardware (or even changing 
Bluetooth headset mode back and forth between A2DP / HFP).