From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from blyat.fensystems.co.uk (blyat.fensystems.co.uk [54.246.183.96])
 by mx.groups.io with SMTP id smtpd.web12.2956.1618534770852441087
 for <devel@edk2.groups.io>;
 Thu, 15 Apr 2021 17:59:31 -0700
Authentication-Results: mx.groups.io;
 dkim=missing; spf=pass (domain: ipxe.org, ip: 54.246.183.96, mailfrom: mcb30@ipxe.org)
Received: from dolphin.home (unknown [IPv6:2a00:23c6:5495:5e00:72b3:d5ff:feb1:e101])
	by blyat.fensystems.co.uk (Postfix) with ESMTPSA id DEDFF441FC;
	Fri, 16 Apr 2021 00:59:26 +0000 (UTC)
Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
To: Ethin Probst <harlydavidsen@gmail.com>, Andrew Fish <afish@apple.com>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>,
 Mike Kinney <michael.d.kinney@intel.com>, Leif Lindholm <leif@nuviainc.com>,
 Laszlo Ersek <lersek@redhat.com>,
 "Desimone, Nathaniel L" <nathaniel.l.desimone@intel.com>,
 Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com>,
 Gerd Hoffmann <kraxel@redhat.com>
References: <CAJQtwF2aOTztmMOW-QFHovdFkoQHZnPqPxgSbKd+HfqeumD2Fw@mail.gmail.com>
 <BE3D8FA9-1BFE-43C3-B69F-38A44EA36ACE@apple.com>
 <16758FB6436B1195.32393@groups.io>
 <CAJQtwF0pcYzFHjNp5JWqNDecwcxuAM3_MbUkZ5FruBUGp=BSCw@mail.gmail.com>
 <A454E2B2-7569-443D-AADF-60384005BE47@apple.com>
 <CAJQtwF0wVsXvN3uHHHmWzHPTmh-Mkyei4mpc_bsaP21bMB9+PA@mail.gmail.com>
 <CO1PR11MB4929B44F6CC94FA661AA1055D24E9@CO1PR11MB4929.namprd11.prod.outlook.com>
 <B2260448-028D-4659-98D6-C695CF3D738A@apple.com>
 <CAJQtwF3-REoeETR46BKr0Q6=b6ZHALbeiBBFtp4fEdFxKz8gwA@mail.gmail.com>
 <4AEC1784-99AF-47EF-B7DD-77F91EA3D7E9@apple.com>
 <CAJQtwF2e4dACRVyibbLOmOEmy34xMdGb1s0YdPFcHmZ2NMoBDA@mail.gmail.com>
 <309cc5ca-2ecd-79dd-b183-eec0572ea982@ipxe.org>
 <A139650C-A76F-4471-AFCC-FFF1BE2E35BB@apple.com>
 <CAJQtwF3kuOD3C2arUfZu_xDbkHq5HHz+LYNB2=AeV8x+q_cPtw@mail.gmail.com>
 <CCB65CBC-304C-42B3-810D-0AC8BEAE29D1@apple.com>
 <CAJQtwF08Apihdsitw2Vs-+iV9rrqgpqkwONSbaY-yb_BP1xCYw@mail.gmail.com>
From: "Michael Brown" <mcb30@ipxe.org>
Message-ID: <33e37977-2d27-36a0-89a6-36e513d06b2f@ipxe.org>
Date: Fri, 16 Apr 2021 01:59:26 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.7.0
MIME-Version: 1.0
In-Reply-To: <CAJQtwF08Apihdsitw2Vs-+iV9rrqgpqkwONSbaY-yb_BP1xCYw@mail.gmail.com>
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00
	autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
	blyat.fensystems.co.uk
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit

On 16/04/2021 00:42, Ethin Probst wrote:
> Forcing a particular channel mapping, sample rate and sample format on
> everyone would complicate application code. From an application point
> of view, one would, with that type of protocol, need to do the
> following:
> 1) Load an audio file in any audio file format from any storage mechanism.
> 2) Decode the audio file format to extract the samples and audio metadata.
> 3) Resample the (now decoded) audio samples and convert (quantize) the
> audio samples into signed 16-bit PCM audio.
> 4) forward the samples onto the EFI audio protocol.

You have made an incorrect assumption that there exists a requirement to 
be able to play audio files in arbitrary formats.  This requirement does 
not exist.

With a protocol-mandated fixed baseline set of audio parameters (sample 
rate etc), what would happen in practice is that the audio files would 
be encoded in that format at *build* time, using tools entirely external 
to UEFI.  The application code is then trivially simple: it just does 
"load blob, pass blob to audio protocol".

> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>    EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>    EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>    EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
> } EFI_SIMPLE_AUDIO_PROTOCOL;

This is now starting to look like something that belongs in boot-time 
firmware.  :)

Michael