From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rn-mailsvcp-ppex-lapp45.apple.com (rn-mailsvcp-ppex-lapp45.apple.com [17.179.253.49]) by mx.groups.io with SMTP id smtpd.web09.432.1618596133241231871 for ; Fri, 16 Apr 2021 11:02:13 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=TJyuODcE; spf=pass (domain: apple.com, ip: 17.179.253.49, mailfrom: afish@apple.com) Received: from pps.filterd (rn-mailsvcp-ppex-lapp45.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp45.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 13GI2C52009998; Fri, 16 Apr 2021 11:02:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=+92kHGMIgyn1/193eU8k/XTsZwOx/GWTCyFeZ66u3Dk=; b=TJyuODcEcRLa4gHjqLhHYeZuq/HAqLEbzxTN+7HDOq8qYZhq6Yn4sy8jk+W39oSj/l65 AIUDAoB9pFWjX436/9VShgGavNCh/I/rBAWiz+0pCJ5zem4HXvezvPomMf26/Dc04vwV YdR8MQ57sDZeqnqcSbou3RMh5+iu43Eq5619qjKKh/e+A/zq50Qh8FtjJoSwhbdUiiYx QQxfdzwCOclHNpMjBUjvtzzNCfkgeSzIX1Q1fQ05ti0WOSJNOjgkJSAZWaNSgnT6k7li MS3KS9CDLDiECIgK29IYM7s6+DOKtqGQn7pXEAgpyfdZ1C2K9aEjsezuSHgWE3qhkc7C Gw== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by rn-mailsvcp-ppex-lapp45.rno.apple.com with ESMTP id 37yehfrnaw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 16 Apr 2021 11:02:12 -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-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPS id <0QRO0032I4ROSDC0@rn-mailsvcp-mta-lapp02.rno.apple.com>; Fri, 16 Apr 2021 11:02:12 -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 <0QRO002004DJMB00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Fri, 16 Apr 2021 11:02:12 -0700 (PDT) X-Va-A: X-Va-T-CD: b2a6e213b1e93bac3561a11ee6934d40 X-Va-E-CD: 4730c80ee67030d4f2c83e40b4ab0357 X-Va-R-CD: 6f0325faf294bd23a6d751c620be9d51 X-Va-CD: 0 X-Va-ID: 83c11ec3-bad4-4f56-b716-57f4f0f8dc10 X-V-A: X-V-T-CD: b2a6e213b1e93bac3561a11ee6934d40 X-V-E-CD: 4730c80ee67030d4f2c83e40b4ab0357 X-V-R-CD: 6f0325faf294bd23a6d751c620be9d51 X-V-CD: 0 X-V-ID: 0b338eda-47f2-4629-a5f1-9520d9c292f8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-04-16_09:2021-04-16,2021-04-16 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 <0QRO00A9N4RLQI00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Fri, 16 Apr 2021 11:02:11 -0700 (PDT) From: "Andrew Fish" Message-id: <98FE49DD-DE69-4A2B-B50F-E29BF53C7D12@apple.com> MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021) Date: Fri, 16 Apr 2021 11:02:09 -0700 In-reply-to: Cc: edk2-devel-groups-io , Leif Lindholm , Michael Brown , Mike Kinney , Laszlo Ersek , "Desimone, Nathaniel L" , Rafael Rodrigues Machado , Gerd Hoffmann To: Ethin Probst References: <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> <20210416113447.GG1664@vanye> <10E3436C-D743-4B2F-8E4B-7AD93B82FC92@apple.com> 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-16_09:2021-04-16,2021-04-16 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_0ACCA8D6-6F81-4BAE-BFB6-8EB24BC4790B" --Apple-Mail=_0ACCA8D6-6F81-4BAE-BFB6-8EB24BC4790B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 16, 2021, at 10:45 AM, Ethin Probst wro= te: >=20 > Yes, three APIs (maybe like this) would work well: > - Start, Stop: begin playback of a stream > - SetVolume, GetVolume, Mute, Unmute: control volume of output and enabl= e muting > - CreateStream, ReleaseStream, SetStreamSampleRate: Control sample > rate of stream (but not sample format since Signed 16-bit PCM is > enough) > Marvin, how do you suggest we make the events then? We need some way > of notifying the caller that the stream has concluded. We could make > the driver create the event and pass it back to the caller as an > event, but you'd still have dangling pointers (this is C, after all). > We could just make a IsPlaying() function and WaitForCompletion() > function and allow the driver to do the event handling -- would that > work? >=20 Ethin, I can adapt my example from earlier in the thread for how to do async EFI = APIs.=20 /** The struct of Audio Token. **/ typedef struct { /// /// Event will be signaled when the read audo has been played. /// If only synchronous playback is supported the Event must still get s= ignaled.=20 /// EFI_EVENT Event; /// /// Defines whether or not the signaled event encountered an error. /// EFI_STATUS TransactionStatus; } CODE_FIRST_HDA_AUDIO_TOKEN; /** Play synchronous or asynchronous audio. If Token is passed in the audio = is played asynchronously, if Token is NULL then this call blocks until the Audio i= s complete.=20 @param[in] This A pointer to the CODE_FIRST_HDA_AUDIO_PROTO= COL instance. @param[in, out] Token A pointer to the token associated with the = transaction. If NULL this functions blocks until audio p= lay back is complete. @retval EFI_SUCCESS The audio started playing.=20 @retval EFI_OUT_OF_RESOURCES The request could not be completed due to = a lack of resources. @retval EFI_INVALID_PARAMETER One or more parameters are invalid. **/ typedef EFI_STATUS (EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_PLAY_STREAM)( IN CODE_FIRST_HDA_AUDIO_PROTOCOL *This, IN OUT CODE_FIRST_HDA_AUDIO_TOKEN *Token OPTIONAL ); You can fake out the asynchronous interface in your synchronous flow by = =E2=80=A6. if (Token !=3D NULL) { Token->TransactionStatus =3D Status; // return value from sync call gBS->SignalEvent (Token->Event); } This just gives the caller the experience that the event was signaled befo= re the call returned, which is legal for an async API.=20 The caller allocates a CODE_FIRST_HDA_AUDIO_TOKEN and creates an Event tha= t has an associated callback function. Then calls gAudio->PlayStream (gAudi= o, Token); and the callers callback function fires when the audio stream co= mpletes.=20 Thanks, Andrew Fish > On 4/16/21, Andrew Fish wrote: >>=20 >>=20 >>> On Apr 16, 2021, at 4:34 AM, Leif Lindholm wrote: >>>=20 >>> Hi Ethin, >>>=20 >>> I think we also want to have a SetMode function, even if we don't get >>> around to implement proper support for it as part of GSoC (although I >>> expect at least for virtio, that should be pretty straightforward). >>>=20 >>=20 >> Leif, >>=20 >> I=E2=80=99m think if we have an API to load the buffer and a 2nd API to= play the >> buffer an optional 3rd API could configure the streams. >>=20 >>> It's quite likely that speech for UI would be stored as 8kHz (or >>> 20kHz) in some systems, whereas the example for playing a tune in GRUB >>> would more likely be a 44.1 kHz mp3/wav/ogg/flac. >>>=20 >>> For the GSoC project, I think it would be quite reasonable to >>> pre-generate pure PCM streams for testing rather than decoding >>> anything on the fly. >>>=20 >>> Porting/writing decoders is really a separate task from enabling the >>> output. I would much rather see USB *and* HDA support able to play pcm >>> streams before worrying about decoding. >>>=20 >>=20 >> I agree it might turn out it is easier to have the text to speech code = just >> encode a PCM directly. >>=20 >> Thanks, >>=20 >> Andrew Fish >>=20 >>> / >>> Leif >>>=20 >>> On Fri, Apr 16, 2021 at 00:33:06 -0500, Ethin Probst wrote: >>>> 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. >>>>=20 >>>> On 4/16/21, Andrew Fish via groups.io w= rote: >>>>>=20 >>>>>=20 >>>>>> 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 forma= t >>>>>>> on >>>>>>> everyone would complicate application code. From an application po= int >>>>>>> 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. >>>>>>=20 >>>>>> You have made an incorrect assumption that there exists a requireme= nt >>>>>> to >>>>>> be able to play audio files in arbitrary formats. This requirement >>>>>> does >>>>>> not 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 wo= uld >>>>>> be >>>>>> encoded in that format at *build* time, using tools entirely extern= al >>>>>> to >>>>>> UEFI. The application code is then trivially simple: it just does >>>>>> "load >>>>>> blob, pass blob to audio protocol". >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> Ethin, >>>>>=20 >>>>> Given the goal is an industry standard we value interoperability mor= e >>>>> that >>>>> flexibility. >>>>>=20 >>>>> How about another use case. Lets say the Linux OS loader (Grub) want= s >>>>> to >>>>> have an accessible UI so it decides to sore sound files on the EFI >>>>> System >>>>> 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 differ= ent >>>>> PCs >>>>> and a wide range of UEFI Audio driver implementations. It is a much >>>>> easier >>>>> 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 Lin= ux >>>>> proper but that falls down if you are booting from read only media l= ike >>>>> a >>>>> DVD or backup tape (yes people still do that in server land). >>>>>=20 >>>>> 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 yo= u >>>>> use >>>>> may impact the quality of the playback for a given board. Your EFI i= s >>>>> likely >>>>> 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. S= o >>>>> that >>>>> will required testing, and some one with audiophile ears (or an AI >>>>> program) >>>>> to test all the combinations. I=E2=80=99m not kidding I get BZs on t= he quality >>>>> of >>>>> the boot bong on our systems. >>>>>=20 >>>>>=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-ti= me >>>>>> firmware. :) >>>>>>=20 >>>>>=20 >>>>> 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 pla= y >>>>> the >>>>> 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 i= n >>>>> xyz >>>>> 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 go= ing >>>>> 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 >>>>> the >>>>> audio hardware that probably means we should have a library that doe= s >>>>> that >>>>> work, so other Audio drivers can share that code. Also having a libr= ary >>>>> makes it easier to write a unit test. We need to be security conscio= us >>>>> as we >>>>> need to treat the Audo file as attacker controlled data. >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Andrew Fish >>>>>=20 >>>>>> Michael >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Signed, >>>> Ethin D. Probst >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 > --=20 > Signed, > Ethin D. Probst --Apple-Mail=_0ACCA8D6-6F81-4BAE-BFB6-8EB24BC4790B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 16, 2= 021, at 10:45 AM, Ethin Probst <harlydavidsen@gmail.com> wrote:

Yes, three APIs (may= be like this) would work well:
- Start, Stop: begin playback = of a stream
- SetVolume, GetVolume, Mute, Unmute: control vol= ume of output and enable muting
- CreateStream, ReleaseStream= , SetStreamSampleRate: Control sample
rate of stream (but not= sample format since Signed 16-bit PCM is
enough)
Marvin, how do you suggest we make the events then? We need some way
of notifying the caller that the stream has concluded. We could = make
the driver create the event and pass it back to the call= er as an
event, but you'd still have dangling pointers (this = is C, after all).
We could just make a IsPlaying() function a= nd WaitForCompletion()
function and allow the driver to do th= e event handling -- would that
work?


Ethin,
=

I can adapt my example from earlier in the t= hread for how to do async EFI APIs. 

/**
  The struct of Au= dio Token.
**/
typ= edef struct {

  ///
  /// Event will be signaled when the read audo has be= en played.
  /// If only synchronous playback is supported the Event must still= get signaled. 
  ///
  EFI_EVENT             &n= bsp; Event;

  ///
  /// Defines whether or not the signaled event encountere= d an error.
  ///
  EFI_STATUS              Tr= ansactionStatus;
} CODE_FIRST_HDA_AUDIO_TOKEN;

/**
  Play synchronous or as= ynchronous audio. If Token is passed in the audio is played
  asynchronously, if Token is NULL t= hen this call blocks until the Audio is complete. 
=

  @param[in]      This   &= nbsp;     A pointer to the CODE_FIRST_HDA_AUDIO_PROTOCOL instance= .
  @param[in, out] T= oken        A pointer to the token associated with the = transaction.
   =                     &nbs= p;      If NULL this functions blocks until audio play back = is complete.

  @retval EF= I_SUCCESS           The audio started playing.&nbs= p;
  @retva= l EFI_OUT_OF_RESOURCES  The request could not be completed due to a la= ck of resources.
  @retva= l EFI_INVALID_PARAMETER One or more parameters are invalid.

**/
typedef
EFI_STATUS
(EFIAPI *CODE_FIRST_HDA_AUDI= O_PROTOCOL_PLAY_STREAM)(
&= nbsp; IN     CODE_FIRST_HDA_AUDIO_PROTOCOL   *This,
  IN OUT CODE_FIRST_HDA_AUDIO= _TOKEN      *Token     OPTIONAL
  );


You can fake out= the asynchronous interface in your synchronous flow by =E2=80=A6.


if (Token !=3D NULL) {<= /div>
  Token->= ;Tr= ansactionStatus =3D Status;  // return value from sync call
  gBS->SignalEvent (Token->Event);
}

<= /span>
This just gives the caller the experience that the e= vent was signaled before the call returned, which is legal for an async API= . 

The caller allocates a COD= E_FIRST_HDA_AUDIO_TOKEN and creates an Event that has an associated callbac= k function. Then calls gAudio->PlayStream (gAudio, Token); and the calle= rs callback function fires when the audio stream completes. 

Thanks,

Andr= ew Fish

On 4/16/21, Andrew Fish <afish@apple.com> wrote:


On Apr 16, 2021, at 4:34 AM, Leif Lindholm <leif@nuviainc.com> wrote:<= br class=3D"">
Hi Ethin,

I think= we also want to have a SetMode function, even if we don't get
around to implement proper support for it as part of GSoC (although I
expect at least for virtio, that should be pretty straightforwar= d).


Leif,

I=E2=80=99m think if we have an API to load the buffe= r and a 2nd API to play the
buffer an optional 3rd API could = configure the streams.

It's quite likely that speech for UI would be stored as 8kHz = (or
20kHz) in some systems, whereas the example for playing a= tune in GRUB
would more likely be a 44.1 kHz mp3/wav/ogg/fla= c.

For the GSoC project, I think it would be q= uite reasonable to
pre-generate pure PCM streams for testing = rather than decoding
anything on the fly.

Porting/writing decoders is really a separate task from enabling = the
output. I would much rather see USB *and* HDA support abl= e to play pcm
streams before worrying about decoding.


I agree it might turn out= it is easier to have the text to speech code just
encode a P= CM directly.

Thanks,

Andrew Fish

/
  Leif

On= Fri, Apr 16, 2021 at 00:33:06 -0500, Ethin Probst wrote:
Thanks for that explanation (I missed Mik= e's message). Earlier I sent
a summary of those things that w= e can agree on: mainly, that we have
mute, volume control, a = load buffer, (maybe) an unload buffer, and a
start/stop strea= m function. Now that I fully understand the
ramifications of = this I don't mind settling for a specific format and
sample r= ate, 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 o= f
WAV audio? I can make a library class for that, but I'll de= finitely
need help with the security aspect.
On 4/16/21, Andrew Fish via groups.io <afish=3Dapple.com@groups.io> wrote:


On Apr 15, 2021, at 5:59 PM, Michael Brown <mcb30@ipxe.org> wrote:

On 16/04/2021 00:42, Ethin Probst wrote:
Forcing a particular channel mappin= g, sample rate and sample format
on
everyone wo= uld 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 fro= m any storage
mechanism.
2) Decode the audio fi= le 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.<= br class=3D"">4) forward the samples onto the EFI audio protocol.

You have made an incorrect assumption th= at there exists a requirement
to
be able to pla= y audio files in arbitrary formats.  This requirement
do= es
not exist.

With a protocol-ma= ndated fixed baseline set of audio parameters
(sample
rate etc), what would happen in practice is that the audio files wou= ld
be
encoded in that format at *build* time, u= sing tools entirely external
to
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
that
flexibility.

How about another use case. Lets say the Linux OS loader (Grub) want= s
to
have an accessible UI so it decides to sor= e sound files on the EFI
System
Partition and u= se our new fancy UEFI Audio Protocol to add audio to the
OSloader GUI. So that version of Grub needs to work on 1,000 of = different
PCs
and a wide range of UEFI Audio dr= iver implementations. It is a much
easier
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 Lin= ux
proper but that falls down if you are booting from read on= ly media like
a
DVD or backup tape (yes people = still do that in server land).

The other probl= em with flexibility is you just made the test matrix
very
large for every driver that needs to get implemented. For someth= ing as
complex as Intel HDA how you hook up the hardware and = what CODECs you
use
may impact the quality of t= he playback for a given board. Your EFI is
likely
going to pick a single encoding at that will get tested all the time if<= br class=3D"">your
system has audio, but all 50 other things = you support not so much. So
that
will required = testing, and some one with audiophile ears (or an AI
program)=
to test all the combinations. I=E2=80=99m not kidding I get = BZs on the quality
of
the boot bong on our syst= ems.


typedef struct EFI_SIMPLE_A= UDIO_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 somet= hing 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 pla= y
the
buffer (that way we can an API in the fut= ure to twiddle knobs). That
API
also implements= the async EFI interface. Trust me the 1st thing that is
goin= g to happen when we add audio is some one is going to complain in
xyz
state we should mute audio, or we should honer aud= io volume and mute
settings from setup, or from values set in= the OS. Or some one is going
to
want the volum= e 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
that
work, so other Audio d= rivers can share that code. Also having a library
makes it ea= sier 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 F= ish

Micha= el








=




--
Signed,
Ethin D.= Probst









--
Signed,=
Ethin D. Probst

--Apple-Mail=_0ACCA8D6-6F81-4BAE-BFB6-8EB24BC4790B--