From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rn-mailsvcp-ppex-lapp24.apple.com (rn-mailsvcp-ppex-lapp24.apple.com [17.179.253.38]) by mx.groups.io with SMTP id smtpd.web10.4999.1618550039541575782 for ; Thu, 15 Apr 2021 22:13:59 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=MD2Qjy16; spf=pass (domain: apple.com, ip: 17.179.253.38, mailfrom: afish@apple.com) Received: from pps.filterd (rn-mailsvcp-ppex-lapp24.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp24.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 13G5BOEa015610; Thu, 15 Apr 2021 22:13:59 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=tAm+dJQiY+COYwTQ1jlg1k4oOHn6Bt6ZWVorXLiST1o=; b=MD2Qjy165+v/JOC/My2K4CdJGIkhgPufck06UU3PD+Vy7oQ7eo4tzad2LSgOEsikB2ni w4X2JCDv6sRWfX7ozX+8/rkVssmfZWZawN9laq2Tol7O1f7wjewIDOr4zp1+A7LjFV+O If4SnoFrD9hPhrYCwWjeu+0WTQss9unQtZTjl8Qx1EaH5D2FtWtJvGoZB6lIqf9UPYNC jxNunYnrEW/Ml4YaHWCWuk6cWnHzzrhlyl7hZ8LifFyzi9yXxmOhf20P+c1PfvX2XdX9 wGO4E0o5fgGNvSXIaOXF8nnnAnDcjuHUD8mDlVnWZsnh6dVlrIE7C8V6Pvk3TXPMTjql CQ== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp24.rno.apple.com with ESMTP id 37u9maqcsb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 15 Apr 2021 22:13:59 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPS id <0QRN00S2L57AUG30@rn-mailsvcp-mta-lapp04.rno.apple.com>; Thu, 15 Apr 2021 22:13:59 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) id <0QRN00Q004WTZG00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Thu, 15 Apr 2021 22:13:58 -0700 (PDT) X-Va-A: X-Va-T-CD: 3fdb4f627b010d00e96a5e6e5bd51aa5 X-Va-E-CD: 4730c80ee67030d4f2c83e40b4ab0357 X-Va-R-CD: 6f0325faf294bd23a6d751c620be9d51 X-Va-CD: 0 X-Va-ID: dcb7e1d3-524c-46d4-8dba-53a9477c819d X-V-A: X-V-T-CD: 3fdb4f627b010d00e96a5e6e5bd51aa5 X-V-E-CD: 4730c80ee67030d4f2c83e40b4ab0357 X-V-R-CD: 6f0325faf294bd23a6d751c620be9d51 X-V-CD: 0 X-V-ID: 4accc8d7-a551-42ff-b2d9-94e86aa5bd39 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-04-15_11:2021-04-15,2021-04-15 signatures=0 Received: from [17.235.19.21] (unknown [17.235.19.21]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPSA id <0QRN0030M579KE00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Thu, 15 Apr 2021 22:13:58 -0700 (PDT) MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) From: "Andrew Fish" In-reply-to: <33e37977-2d27-36a0-89a6-36e513d06b2f@ipxe.org> Date: Thu, 15 Apr 2021 22:13:57 -0700 Cc: Ethin Probst , Mike Kinney , Leif Lindholm , Laszlo Ersek , "Desimone, Nathaniel L" , Rafael Rodrigues Machado , Gerd Hoffmann Message-id: <6F69BEA6-5B7A-42E5-B6DA-D819ECC85EE5@apple.com> References: <16758FB6436B1195.32393@groups.io> <4AEC1784-99AF-47EF-B7DD-77F91EA3D7E9@apple.com> <309cc5ca-2ecd-79dd-b183-eec0572ea982@ipxe.org> <33e37977-2d27-36a0-89a6-36e513d06b2f@ipxe.org> To: edk2-devel-groups-io , mcb30@ipxe.org X-Mailer: Apple Mail (2.3654.20.0.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-04-15_11:2021-04-15,2021-04-15 signatures=0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Apr 15, 2021, at 5:59 PM, Michael Brown wrote: >=20 > 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 mechani= sm. >> 2) Decode the audio file format to extract the samples and audio metada= ta. >> 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. >=20 > You have made an incorrect assumption that there exists a requirement to= be able to play audio files in arbitrary formats. This requirement does n= ot exist. >=20 > 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 e= ncoded in that format at *build* time, using tools entirely external to UEF= I. The application code is then trivially simple: it just does "load blob,= pass blob to audio protocol". >=20 Ethin, Given the goal is an industry standard we value interoperability more that= flexibility.=20 How about another use case. Lets say the Linux OS loader (Grub) wants to h= ave an accessible UI so it decides to sore sound files on the EFI System Pa= rtition and use our new fancy UEFI Audio Protocol to add audio to the OS lo= ader GUI. So that version of Grub needs to work on 1,000 of different PCs a= nd a wide range of UEFI Audio driver implementations. It is a much easier w= orld if Wave PCM 16 bit just works every place. You could add a lot of comp= lexity and try to encode the audio on the fly, maybe even in Linux proper b= ut that falls down if you are booting from read only media like a DVD or ba= ckup tape (yes people still do that in server land).=20 The other problem with flexibility is you just made the test matrix very l= arge for every driver that needs to get implemented. For something as compl= ex as Intel HDA how you hook up the hardware and what CODECs you use may im= pact the quality of the playback for a given board. Your EFI is likely goin= g to pick a single encoding at that will get tested all the time if your sy= stem has audio, but all 50 other things you support not so much. So that wi= ll required testing, and some one with audiophile ears (or an AI program) t= o test all the combinations. I=E2=80=99m not kidding I get BZs on the quali= ty of the boot bong on our systems.=20 >> 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; >=20 > This is now starting to look like something that belongs in boot-time fi= rmware. :) >=20 I think that got a little too simple I=E2=80=99d go back and look at the e= xample I posted to the thread but add an API to load the buffer, and then p= lay the buffer (that way we can an API in the future to twiddle knobs). Tha= t API also implements the async EFI interface. Trust me the 1st thing that = is going to happen when we add audio is some one is going to complain in xy= z state we should mute audio, or we should honer audio volume and mute sett= ings from setup, or from values set in the OS. Or some one is going to want= the volume keys on the keyboard to work in EFI.=20 Also if you need to pick apart the Wave PCM 16 byte file to feed it into t= he audio hardware that probably means we should have a library that does th= at work, so other Audio drivers can share that code. Also having a library = makes it easier to write a unit test. We need to be security conscious as w= e need to treat the Audo file as attacker controlled data.=20 Thanks, Andrew Fish > Michael >=20 >=20 >=20 >=20 >=20