From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by mx.groups.io with SMTP id smtpd.web09.5083.1618551189313812272 for ; Thu, 15 Apr 2021 22:33:09 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=UqvXXEj9; spf=pass (domain: gmail.com, ip: 209.85.218.44, mailfrom: harlydavidsen@gmail.com) Received: by mail-ej1-f44.google.com with SMTP id e14so40256676ejz.11 for ; Thu, 15 Apr 2021 22:33:09 -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=BZe0EuBcvzg69JiWBFntjBufBAc2b+GsVQWoXU62Jwo=; b=UqvXXEj92M8BQhHRTPOAbkXQA3hXN83otsevXLo/hGQYTEKGpBRWWovbUPKDsYFU/W /rLchbMRFT8C1s6rbSOZnjAj6X0FTz0jc8I81eIM0CNRl/C8w/Om6hnNSMZahUJ+yn2d Nt5JDP5qR3a76LQdQrtQBVtCuniSkNAnT5pSUdVseaDkHeQHFEJkUXA7Qnr9fIbl7fDY HxX0kE+oZmMw9OkWLU1HWxb/zuXmTBn0MqybMr8HA0XnuPi41uHi7E8QT/31EZCYP/aR 3X5/EQn2c0or5EN35IfEKgWrMToqqrVz08WIxL5h10wE0vmOW16qRZuUDGC7Tbh46XbV fNYg== 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=BZe0EuBcvzg69JiWBFntjBufBAc2b+GsVQWoXU62Jwo=; b=tYta42tIpx2y286Id6wEWCQ27s0CPdZSlDNBal9Ic7+GDx8tmvchcu4IYbwGnEMIzx RkXAmfrh8hXiDcxIQlHqpDfy37FP7LCDZM8ZJkPtKeTW3cRE5jV4ChgjaLK1LMKngKO1 cDJWj7lPAHAYNdmzAEViHF12T+YtRoQ5Es1r/PXOhuHR2lVmvyC+xtz+VYfQEXDTULBn UlPoOZHEbf4BnOge0P+3qvKZkqEtLxcJJ/zZJlrk5yHVYjbN0BGpL9qX9Slsx2LdC5BV S4PJsZvPwOMLabC/Cyd0IES8gWH0UUOJ7tPJZxsvBXcCHtMFhVWa5NpYt3nQ38iRBYIC DqYw== X-Gm-Message-State: AOAM531gjOaIyvNjAx3Q8zBs4nxQvVpqUXLpBs3qW3wJ11jxM9wurEIR Aajd3fK6oYFVk0mqCDQkGGmJb+D0A6SPIp7Uh3VCUMv6M1qjVA== X-Google-Smtp-Source: ABdhPJw+rTXFJb84+DxPe9N0FbJ4gm7ZKid6ncY33jOP372QCZYfZCP7E+EzovO+AKG2kvgUTB6nbd3MALxQ6sx0tzs= X-Received: by 2002:a17:906:48c4:: with SMTP id d4mr6936255ejt.548.1618551187621; Thu, 15 Apr 2021 22:33:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab4:9a0a:0:0:0:0:0 with HTTP; Thu, 15 Apr 2021 22:33:06 -0700 (PDT) In-Reply-To: <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> <6F69BEA6-5B7A-42E5-B6DA-D819ECC85EE5@apple.com> From: "Ethin Probst" Date: Fri, 16 Apr 2021 00:33:06 -0500 Message-ID: Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) To: devel@edk2.groups.io, afish@apple.com Cc: mcb30@ipxe.org, 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 Thanks for that explanation (I missed Mike's message). Earlier I sent a summary of those things that we can agree on: mainly, that we have mute, volume control, a load buffer, (maybe) an unload buffer, and a start/stop stream function. Now that I fully understand the ramifications of this I don't mind settling for a specific format and sample rate, and signed 16-bit PCM audio is, I think, the most widely used one out there, besides 64-bit floating point samples, which I've only seen used in DAWs, and that's something we don't need. Are you sure you want the firmware itself to handle the decoding of WAV audio? I can make a library class for that, but I'll definitely need help with the security aspect. On 4/16/21, Andrew Fish via groups.io wrote: > > >> On Apr 15, 2021, at 5:59 PM, Michael Brown wrote: >> >> 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 t= o >> be able to play audio files in arbitrary formats. This requirement doe= s >> 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 t= o >> UEFI. The application code is then trivially simple: it just does "loa= d >> blob, pass blob to audio protocol". >> > > > Ethin, > > Given the goal is an industry standard we value interoperability more th= at > flexibility. > > How about another use case. Lets say the Linux OS loader (Grub) wants to > have an accessible UI so it decides to sore sound files on the EFI Syste= m > Partition and use our new fancy UEFI Audio Protocol to add audio to the = OS > loader GUI. So that version of Grub needs to work on 1,000 of different = PCs > and a wide range of UEFI Audio driver implementations. It is a much easi= er > world if Wave PCM 16 bit just works every place. You could add a lot of > complexity and try to encode the audio on the fly, maybe even in Linux > proper but that falls down if you are booting from read only media like = a > DVD or backup tape (yes people still do that in server land). > > The other problem with flexibility is you just made the test matrix very > large for every driver that needs to get implemented. For something as > complex as Intel HDA how you hook up the hardware and what CODECs you us= e > may impact the quality of the playback for a given board. Your EFI is li= kely > going to pick a single encoding at that will get tested all the time if = your > system has audio, but all 50 other things you support not so much. So th= at > will required testing, and some one with audiophile ears (or an AI progr= am) > to test all the combinations. I=E2=80=99m not kidding I get BZs on the q= uality of > the boot bong on our systems. > > >>> 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. :) >> > > I think that got a little too simple I=E2=80=99d go back and look at the= example I > posted to the thread but add an API to load the buffer, and then play th= e > buffer (that way we can an API in the future to twiddle knobs). That 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 > settings 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. > > Also if you need to pick apart the Wave PCM 16 byte file to feed it into= the > 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 a= s we > need to treat the Audo file as attacker controlled data. > > Thanks, > > Andrew Fish > >> Michael >> >> >> >> >> > > > >=20 > > > --=20 Signed, Ethin D. Probst