- From: Chris Rogers <crogers@google.com>
- Date: Mon, 29 Oct 2012 21:47:32 -0700
- To: robert@ocallahan.org
- Cc: Joseph Berkovitz <joe@noteflight.com>, Ehsan Akhgari <ehsan.akhgari@gmail.com>, public-audio@w3.org
- Message-ID: <CA+EzO0mUEw+5TLfFM3FsEWtqHpqspvMozejT+BWZY1Bq1fY-zw@mail.gmail.com>
On Mon, Oct 29, 2012 at 9:12 PM, Robert O'Callahan <robert@ocallahan.org>wrote: > Yes, it would prevent reading the buffers. Why is that a big problem? > > A simple reason for reading a buffer would be to display its data as a waveform. A more complex reason would be to inspect the PCM data in JavaScript for analysis, possibly using the information to determine which portions of the buffer to play next. Since these buffers can be passed around as function arguments, it would be pretty confusing to developers that some of them became unreadable because of some previous activity using the buffer. This implies a statefulness to the buffer which is very likely to trip up developers. To be honest, it's quite a large limitation to remove readability. I'm not even very fond of the idea of crippling a buffer's write access. After all, an application might have used the buffer to play a sound in the past, but might wish to modify the data to play another sound at a later time. It's not that surprising that you might get unusual results if you modify the data at the same moment it's playing, and I've had nobody in the real world ever confused or complain about this. It's just common sense. Chris > > Rob > -- > Jesus called them together and said, “You know that the rulers of the > Gentiles lord it over them, and their high officials exercise authority > over them. Not so with you. Instead, whoever wants to become great among > you must be your servant, and whoever wants to be first must be your > slave — just as the Son of Man did not come to be served, but to serve, > and to give his life as a ransom for many.” [Matthew 20:25-28] > >
Received on Tuesday, 30 October 2012 04:47:59 UTC