From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) by mx.groups.io with SMTP id smtpd.web10.106.1618504984420102221 for ; Thu, 15 Apr 2021 09:43:04 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=mTTE1+gY; spf=pass (domain: apple.com, ip: 17.171.2.72, mailfrom: afish@apple.com) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 13FGd4br040486; Thu, 15 Apr 2021 09:43:03 -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=Hq6jYx33Zi4zXiNoCs0XGbBuDXDYXPiGfcp7XjuSObI=; b=mTTE1+gYnDB0/7fCB0RzzoyrETJbubPQXSReGNBsRdpTbkDXZiSrOlaDcVP3hNdrUeff QgTwwzwtS/3vNg89eTBGzN1LPlGmbvB6YIQ9lgx3WCVQ/0SaUeooKl54EDkfyRUCTEJJ dnh4ucKQG0JCSJyL+CJH/hnbJHusX7Lk7qbZ/bwMW5zL5pNHKXUmYO7z+zoeI2SGjIkE JefP14Pmq5bPcZ799ykYYCDvvz7lBYD9sx9Ep/8s0Ja4cnqKS/53QWeov2vI4GyaPIBe +mdquj5+KnqFjZZYZZJpdPuscyepGbnaEJig6SIXx7i80bO9MlT5uSXZxsVMpthmaWAH ag== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 37v1kq1y35-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 15 Apr 2021 09:43:03 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPS id <0QRM00ZRP6FPU810@rn-mailsvcp-mta-lapp02.rno.apple.com>; Thu, 15 Apr 2021 09:43:01 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) id <0QRM00Y006F4OZ00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Thu, 15 Apr 2021 09:43:01 -0700 (PDT) X-Va-A: X-Va-T-CD: d0f27b7cd504cdf3700b17f0ad8032bf X-Va-E-CD: 4730c80ee67030d4f2c83e40b4ab0357 X-Va-R-CD: 6f0325faf294bd23a6d751c620be9d51 X-Va-CD: 0 X-Va-ID: 9a3536c9-8ea2-4321-b230-17a348e3c217 X-V-A: X-V-T-CD: d0f27b7cd504cdf3700b17f0ad8032bf X-V-E-CD: 4730c80ee67030d4f2c83e40b4ab0357 X-V-R-CD: 6f0325faf294bd23a6d751c620be9d51 X-V-CD: 0 X-V-ID: d2d0cc28-d748-4a27-8fc9-fdb540c40533 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-04-15_06:2021-04-15,2021-04-15 signatures=0 Received: from [17.235.1.165] (unknown [17.235.1.165]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPSA id <0QRM00CDR6FND700@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Thu, 15 Apr 2021 09:43:01 -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: <309cc5ca-2ecd-79dd-b183-eec0572ea982@ipxe.org> Date: Thu, 15 Apr 2021 09:42:59 -0700 Cc: Ethin Probst , Mike Kinney , Leif Lindholm , Laszlo Ersek , "Desimone, Nathaniel L" , Rafael Rodrigues Machado , Gerd Hoffmann Message-id: References: <66e073bb-366b-0559-4a78-fc5e8215aca1@redhat.com> <16758FB6436B1195.32393@groups.io> <4AEC1784-99AF-47EF-B7DD-77F91EA3D7E9@apple.com> <309cc5ca-2ecd-79dd-b183-eec0572ea982@ipxe.org> To: edk2-devel-groups-io , Michael Brown 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_06: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:07 AM, Michael Brown wrote: >=20 > On 15/04/2021 06:28, Ethin Probst wrote: >> - I hoped to add recording in case we in future want to add >> accessibility aids like speech recognition (that was one of the todo >> tasks on the EDK2 tasks list) >=20 > Is there any necessity for audio input and output to be implemented with= in the same protocol? Unlike a network device (which is intrinsically bidi= rectional), it seems natural to conceptually separate audio input from audi= o output. >=20 >> - Muting and volume control could easily be added by just replacing >> the sample buffer with silence and by multiplying all the samples by a >> percentage. >=20 > The code controlling volume/mute may not have any access to the sample b= uffer. The most natural implementation would seem to allow for a platform = to notice volume up/down keypresses and use those to control the overall sy= stem volume, without any knowledge of which samples (if any) are currently = being played by other code in the system. >=20 I=E2=80=99ve also thought of adding NVRAM variable that would let setup, U= EFI Shell, or even the OS set the current volume, and Mute. This how it wou= ld be consumed concept is why I proposed mute and volume being separate API= s. The volume up/down API in addition to fixed percentage might be overkill= , but it does allow a non liner mapping to the volume up/down keys. You wou= ld be surprised how picky audiophiles can be and it seems they like to file= Bugzillas.=20 >> - Finally, the reason I used enumerations for specifying parameters >> like sample rate and stuff was that I was looking at this protocol >> from a general UEFI applications point of view. VirtIO supports all of >> the sample configurations listed in my gist, and it seems reasonable >> to allow the application to control those parameters instead of >> forcing a particular parameter configuration onto the developer. >=20 > Consider also the point of view of the developer implementing a driver f= or some other piece of audio hardware that happens not to support precisely= the same sample rates etc as VirtIO. It would be extremely ugly to force = all future hardware to pretend to have the same capabilities as VirtIO just= because the API was initially designed with VirtIO in mind. >=20 > As a developer on the other side of the API, writing code to play sound = files on an arbitrary unknown platform, I would prefer to simply consume as= simple as possible an abstraction of an audio output protocol and not have= to care about what hardware is actually implementing it. >=20 It may make sense to have an API to load the buffer/stream and other APIs = to play or pause. This could allow an optional API to configure how the str= eam is played back. If we add a version to the Protocol that would at least= future proof us.=20 We did get feedback that it is very common to speed up the auto playback r= ates for accessibility. I=E2=80=99m not sure if that is practical with a si= mple PCM 16 wave file with the firmware audio implementation. I guess that = is something we could investigate.=20 In terms of maybe adding text to speech there is an open source project th= at conceptually we could port to EFI. It would likely be a binary that woul= d have to live on the EFI System Partition due to size. I was thinking that= words per minute could be part of that API and it would produce a PCM 16 w= ave file that the audio protocol we are discussing could play.=20 > Both of these argue in favour of defining a very simple API that express= es only a common baseline capability that is plausibly implementable for ev= ery piece of audio hardware ever made. >=20 > Coupled with the relatively minimalistic requirements for boot-time audi= o, I'd probably suggest supporting only a single format for audio data, wit= h a fixed sample rate (and possibly only mono output). >=20 In my world the folks that work for Jony asked for a stereo boot bong to t= ransition from left to right :). This is not the CODEC you are looking for = was our response=E2=80=A6. I also did not mention that some languages are r= ight to left, as the only thing worse than one complex thing is two complex= things to implement. > As always: perfection is achieved, not when there is nothing more to add= , but when there is nothing left to take away. :) >=20 "Simplicity is the ultimate sophistication=E2=80=9D Thanks, Andrew Fish=20 > Thanks, >=20 > Michael >=20 >=20 >=20 >=20 >=20