From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by mx.groups.io with SMTP id smtpd.web12.870.1618517519447912154 for ; Thu, 15 Apr 2021 13:11:59 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dsJg090+; spf=pass (domain: gmail.com, ip: 209.85.208.48, mailfrom: harlydavidsen@gmail.com) Received: by mail-ed1-f48.google.com with SMTP id s15so29603466edd.4 for ; Thu, 15 Apr 2021 13:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=qnsjWgPY4morSsM02SWhESvct37KgvDLDDVdLSSVcZ0=; b=dsJg090++xj338iTdTGqOmeYMgY8dRZakRkHjLO66Zb1sHxL0dHZ/lYPg8/jyXNVLa Roo9pR4ovY2IqvRkGFCl2m604a50HAkUjpxO8VJp7xjhR1J4i8whcmPm/zzzQJAqiNqS BI+6Pi8tD3Cn33Bp3PAVJgLvMlTVKJag70KAzC0XpUORy1MYK4YclVDzrna3ETWMgqGg GrJ+WXm1hBcR8ylekfmQLrKola70eOsgPVsrQnJYcQn5oWqBUWdcKywbLW+C5K9GBLNQ Zv7htUgzbcqqOE8uptxBvJesx3Mhqr+LgF1o1HuzdEuC15ikhVCEl1VXUGl3qfTq6neg AdXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=qnsjWgPY4morSsM02SWhESvct37KgvDLDDVdLSSVcZ0=; b=h024GsJk1ZqT1pEIGhMEGa759nFHs+rNpbpu/LP5wqYA36Z+APg5ryejNkA5JPHEyP MhBvMTnmvZhWtZ2Lz7vgApyrjwDz5T29CSNPxIZRce5A3BkSXWmJWHuoVCr0wq3od+KM DWd1Hdy/qvPdDNySsGgFUYlMTnOEHvBRXRz6/E9tMdsGj2wzNUaQ5szg13EDXHAT0tZG kDW1/4ldmrHLIXXeZXp+fIPWpFGpImvhVmE5ojeXcy1NRap6E3tz82UwCpoR8MiYtDBO 8C4XXEK07Re2rwU2R77Dnb/1zrG5zqH5aQURHOs6U3HHOwk/pVtKufbgnTSfBv2sR22u i8lg== X-Gm-Message-State: AOAM533rXXm6e8b6u1nTVQJ+J0BDcBvKPIWYpO5IKiQPCArklHgjX6B+ eqAv1QqjLb/0U77y7rtFOKDX86ScpPYCWvn7TR0= X-Google-Smtp-Source: ABdhPJydxwngfsYRapL1csVPt1eahoEhPmEfaYVBuy+ThoQCN2xd8wRV1TJhduvTjYc8SqOtJErUhEsIudR5CafPmqQ= X-Received: by 2002:a05:6402:1255:: with SMTP id l21mr5625321edw.362.1618517517971; Thu, 15 Apr 2021 13:11:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab4:9a0a:0:0:0:0:0 with HTTP; Thu, 15 Apr 2021 13:11:57 -0700 (PDT) In-Reply-To: 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> From: "Ethin Probst" Date: Thu, 15 Apr 2021 15:11:57 -0500 Message-ID: Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) To: Andrew Fish Cc: edk2-devel-groups-io , Michael Brown , Mike Kinney , Leif Lindholm , Laszlo Ersek , "Desimone, Nathaniel L" , Rafael Rodrigues Machado , Gerd Hoffmann Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Is there any necessity for audio input and output to be implemented withi= n the same protocol?=C2=A0 Unlike a network device (which is intrinsically = bidirectional), it seems natural to conceptually separate audio input from = audio output. Nope, there isn't a necessity to make them in one, they can be separated into two. > The code controlling volume/mute may not have any access to the sample b= uffer.=C2=A0 The most natural implementation would seem to allow for a plat= form to notice volume up/down keypresses and use those to control the overa= ll system volume, without any knowledge of which samples (if any) are curre= ntly being played by other code in the system. Your assuming that the audio device your implementing the volume/muting has volume control and muting functionality within itself, then. This may not be the case, and so we'd need to effectively simulate it within the driver, which isn't too hard to do. As an example, the VirtIO driver does not have a request type for muting or for volume control (this would, most likely, be within the VIRTIO_SND_R_PCM_SET_PARAMS request, see sec. 5.14.6.4.3). Therefore, either the driver would have to simulate the request or return EFI_UNSUPPORTED this instance. > 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.=C2=A0 It would be extremely ugly to f= orce all future hardware to pretend to have the same capabilities as VirtIO= just because the API was initially designed with VirtIO in mind. Precisely, but the brilliance of VirtIO is that the sample rate, sample format, &c., do not have to all be supported by a VirtIO device. Notice, also, how in my protocol proposal I noted that the sample rates, at least, were "recommended," not "required." Should a device not happen to support a sample rate or sample format, all it needs to do is return EFI_INVALID_PARAMETER. Section 5.14.6.2.1 (VIRTIO_SND_R_JACK_GET_CONFIG) describes how a jack tells you what sample rates it supports, channel mappings, &c. I do understand how just using a predefined sample rate and sample format might be a good idea, and if that's the best way, then that's what we'll do. The protocol can always be revised at a later time if necessary. I apologize if my stance seems obstinate. Also, thank you, Laszlo, for your advice -- I hadn't considered that a network driver would be another good way of figuring out how async works in UEFI. On 4/15/21, Andrew Fish wrote: > > >> On Apr 15, 2021, at 5:07 AM, Michael Brown wrote: >> >> 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 wit= hin >> the same protocol? Unlike a network device (which is intrinsically >> bidirectional), it seems natural to conceptually separate audio input f= rom >> 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 t= he >> overall system volume, without any knowledge of which samples (if any) = are >> currently being played by other code in the system. >> > > I=E2=80=99ve also thought of adding NVRAM variable that would let setup,= UEFI Shell, > or even the OS set the current volume, and Mute. This how it would be > consumed concept is why I proposed mute and volume being separate APIs. = The > volume up/down API in addition to fixed percentage might be overkill, bu= t it > does allow a non liner mapping to the volume up/down keys. You would be > surprised how picky audiophiles can be and it seems they like to file > Bugzillas. > >>> - 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 precisel= y >> the same sample rates etc as VirtIO. It would be extremely ugly to for= ce >> 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 consum= e >> as simple as possible an abstraction of an audio output protocol and no= t >> have to care about what hardware is actually implementing it. >> > > It may make sense to have an API to load the buffer/stream and other API= s 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. > > We did get feedback that it is very common to speed up the auto playback > rates for accessibility. I=E2=80=99m not sure if that is practical with = a simple PCM > 16 wave file with the firmware audio implementation. I guess that is > something we could investigate. > > In terms of maybe adding text to speech there is an open source project = that > 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 tha= t > words per minute could be part of that API and it would produce a PCM 16 > wave file that the audio protocol we are discussing could play. > >> Both of these argue in favour of defining a very simple API that expres= ses >> 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 aud= io, >> I'd probably suggest supporting only a single format for audio data, wi= th >> a fixed sample rate (and possibly only mono output). >> > > In my world the folks that work for Jony asked for a stereo boot bong to > transition 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 ar= e right to > left, as the only thing worse than one complex thing is two complex thin= gs > to implement. > >> As always: perfection is achieved, not when there is nothing more to ad= d, >> but when there is nothing left to take away. :) >> > > "Simplicity is the ultimate sophistication=E2=80=9D > > Thanks, > > Andrew Fish > >> Thanks, >> >> Michael >> >> >>=20 >> >> > > --=20 Signed, Ethin D. Probst