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.web09.5898.1618488431198385276 for ; Thu, 15 Apr 2021 05:07:12 -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 4E2774419F; Thu, 15 Apr 2021 12:07:07 +0000 (UTC) Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) To: devel@edk2.groups.io, harlydavidsen@gmail.com, Andrew Fish Cc: Mike Kinney , Leif Lindholm , Laszlo Ersek , "Desimone, Nathaniel L" , Rafael Rodrigues Machado , Gerd Hoffmann References: <66e073bb-366b-0559-4a78-fc5e8215aca1@redhat.com> <16758FB6436B1195.32393@groups.io> <4AEC1784-99AF-47EF-B7DD-77F91EA3D7E9@apple.com> From: "Michael Brown" Message-ID: <309cc5ca-2ecd-79dd-b183-eec0572ea982@ipxe.org> Date: Thu, 15 Apr 2021 13:07:06 +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: 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 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) Is there any necessity for audio input and output to be implemented within the same protocol? Unlike a network device (which is intrinsically bidirectional), it seems natural to conceptually separate audio input from audio output. > - 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. The code controlling volume/mute may not have any access to the sample buffer. The most natural implementation would seem to allow for a platform to notice volume up/down keypresses and use those to control the overall system volume, without any knowledge of which samples (if any) are currently being played by other code in the system. > - 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. Consider also the point of view of the developer implementing a driver for 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. 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. Both of these argue in favour of defining a very simple API that expresses only a common baseline capability that is plausibly implementable for every piece of audio hardware ever made. Coupled with the relatively minimalistic requirements for boot-time audio, I'd probably suggest supporting only a single format for audio data, with a fixed sample rate (and possibly only mono output). As always: perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. :) Thanks, Michael