Over the past months I've been refining the web audio API implementation that I've been developing in the 'audio' branch of WebKit (per Maciej's recommendation). The API has been through a good amount of review by WebKit developers at Apple, Google, and in the W3C Audio Incubator group. For those who are interested, the draft specification is here: http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specifi... I have working demos here: http://chromium.googlecode.com/svn/trunk/samples/audio/index.html I'll be posting a series of patches to migrate the working code from the audio branch to WebKit trunk. Most of the files are new, with only a few places which will touch existing WebKit files (such as EventTarget, Event). The files will be conditionally compiled. I'm considering using the following enable: #if ENABLE(AUDIOCONTEXT) After discussing the directory layout in some detail with Eric Carlson, Chris Marrin, Simon Fraser, and Jer Noble, we've decided that the files will primarily live in two places: WebCore/audio WebCore/platform/audio I know that some had expressed concern that a directory called 'audio' in WebCore would be confused with the audio element. The reason I think 'audio' would be a good name is because the API does have a direct relationship to the audio element and, over time, when the API becomes more broadly used will be associated with the audio capabilities of the web platform. That said, if anybody has grave concerns over this name, then we can discuss alternatives. Anyway, I just wanted to bring these coming changes to everyone's attention. Regards, Chris Rogers
On Aug 24, 2010, at 12:05 PM, Chris Rogers wrote:
Over the past months I've been refining the web audio API implementation that I've been developing in the 'audio' branch of WebKit (per Maciej's recommendation). The API has been through a good amount of review by WebKit developers at Apple, Google, and in the W3C Audio Incubator group. For those who are interested, the draft specification is here: http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specifi...
I have working demos here: http://chromium.googlecode.com/svn/trunk/samples/audio/index.html
I'll be posting a series of patches to migrate the working code from the audio branch to WebKit trunk. Most of the files are new, with only a few places which will touch existing WebKit files (such as EventTarget, Event). The files will be conditionally compiled. I'm considering using the following enable:
#if ENABLE(AUDIOCONTEXT)
After discussing the directory layout in some detail with Eric Carlson, Chris Marrin, Simon Fraser, and Jer Noble, we've decided that the files will primarily live in two places:
WebCore/audio WebCore/platform/audio
I know that some had expressed concern that a directory called 'audio' in WebCore would be confused with the audio element. The reason I think 'audio' would be a good name is because the API does have a direct relationship to the audio element and, over time, when the API becomes more broadly used will be associated with the audio capabilities of the web platform. That said, if anybody has grave concerns over this name, then we can discuss alternatives.
I'd rather see the directories named webaudio and the enabled named WEBAUDIO. This would match the naming of 'websockets' (although not web workers, which is simply named 'workers'. I agree that this is directly related to the audio element, but it is an optional piece (hence the enable flag) and so I think it should have its own naming. ----- ~Chris cmarrin@apple.com
Hi Chris, That also sounds like a reasonable naming scheme. The only counter-argument I would have is that we have several directories in WebCore which don't have the 'web' prefix such as: WebCore/notifications WebCore/storage WebCore/workers (and not webnotifications, webstorage, webworkers) I guess I'm just trying to keep to a simpler naming convention. Since WebKit is all about the web, it seems like 'web' is implied. Either way is fine with me, but I have a preference for the simpler 'audio'. Chris On Tue, Aug 24, 2010 at 3:10 PM, Chris Marrin <cmarrin@apple.com> wrote:
On Aug 24, 2010, at 12:05 PM, Chris Rogers wrote:
#if ENABLE(AUDIOCONTEXT)
After discussing the directory layout in some detail with Eric Carlson, Chris Marrin, Simon Fraser, and Jer Noble, we've decided that the files will primarily live in two places:
WebCore/audio WebCore/platform/audio
I know that some had expressed concern that a directory called 'audio' in
WebCore would be confused with the audio element. The reason I think 'audio' would be a good name is because the API does have a direct relationship to the audio element and, over time, when the API becomes more broadly used will be associated with the audio capabilities of the web platform. That said, if anybody has grave concerns over this name, then we can discuss alternatives.
I'd rather see the directories named webaudio and the enabled named WEBAUDIO. This would match the naming of 'websockets' (although not web workers, which is simply named 'workers'. I agree that this is directly related to the audio element, but it is an optional piece (hence the enable flag) and so I think it should have its own naming.
----- ~Chris cmarrin@apple.com
On Aug 24, 2010, at 3:53 PM, Chris Rogers wrote:
Hi Chris,
That also sounds like a reasonable naming scheme. The only counter-argument I would have is that we have several directories in WebCore which don't have the 'web' prefix such as:
WebCore/notifications WebCore/storage WebCore/workers
(and not webnotifications, webstorage, webworkers)
I guess I'm just trying to keep to a simpler naming convention. Since WebKit is all about the web, it seems like 'web' is implied.
Either way is fine with me, but I have a preference for the simpler 'audio'.
Yes, WebKit it not consistent. But websockets does follow this model. And the word 'audio' is so generic, I think making it more specific would help people understand what it is better. Also, the name of the spec is "Web Audio API", so using the "web" prefix seems like the best choice. ----- ~Chris cmarrin@apple.com
On Aug 24, 2010, at 12:05 PM, Chris Rogers wrote:
Over the past months I've been refining the web audio API implementation that I've been developing in the 'audio' branch of WebKit (per Maciej's recommendation). The API has been through a good amount of review by WebKit developers at Apple, Google, and in the W3C Audio Incubator group. For those who are interested, the draft specification is here: http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specifi...
I have working demos here: http://chromium.googlecode.com/svn/trunk/samples/audio/index.html
I'll be posting a series of patches to migrate the working code from the audio branch to WebKit trunk. Most of the files are new, with only a few places which will touch existing WebKit files (such as EventTarget, Event). The files will be conditionally compiled. I'm considering using the following enable:
#if ENABLE(AUDIOCONTEXT)
Didn't we decide that WEBAUDIO was a better #ifdef? Simon
Hi Simon, #if WEBAUDIO is fine. Do you also prefer WebCore/webaudio like Chris Marrin, or WebCore/audio? Chris On Tue, Aug 24, 2010 at 4:04 PM, Simon Fraser <simon.fraser@apple.com>wrote:
On Aug 24, 2010, at 12:05 PM, Chris Rogers wrote:
Over the past months I've been refining the web audio API implementation that I've been developing in the 'audio' branch of WebKit (per Maciej's recommendation). The API has been through a good amount of review by WebKit developers at Apple, Google, and in the W3C Audio Incubator group. For those who are interested, the draft specification is here:
http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specifi...
I have working demos here: http://chromium.googlecode.com/svn/trunk/samples/audio/index.html
I'll be posting a series of patches to migrate the working code from the audio branch to WebKit trunk. Most of the files are new, with only a few places which will touch existing WebKit files (such as EventTarget, Event). The files will be conditionally compiled. I'm considering using the following enable:
#if ENABLE(AUDIOCONTEXT)
Didn't we decide that WEBAUDIO was a better #ifdef?
Simon
My only concern with using the Web* prefix in WebCore is that the Web* prefix is commonly used in WebKit APIs as a namespace for API types. It seems like it could lead to some confusion. -Darin On Tue, Aug 24, 2010 at 4:15 PM, Chris Rogers <crogers@google.com> wrote:
Hi Simon,
#if WEBAUDIO is fine.
Do you also prefer WebCore/webaudio like Chris Marrin, or WebCore/audio?
Chris
On Tue, Aug 24, 2010 at 4:04 PM, Simon Fraser <simon.fraser@apple.com>wrote:
On Aug 24, 2010, at 12:05 PM, Chris Rogers wrote:
Over the past months I've been refining the web audio API implementation that I've been developing in the 'audio' branch of WebKit (per Maciej's recommendation). The API has been through a good amount of review by WebKit developers at Apple, Google, and in the W3C Audio Incubator group. For those who are interested, the draft specification is here:
http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specifi...
I have working demos here: http://chromium.googlecode.com/svn/trunk/samples/audio/index.html
I'll be posting a series of patches to migrate the working code from the audio branch to WebKit trunk. Most of the files are new, with only a few places which will touch existing WebKit files (such as EventTarget, Event). The files will be conditionally compiled. I'm considering using the following enable:
#if ENABLE(AUDIOCONTEXT)
Didn't we decide that WEBAUDIO was a better #ifdef?
Simon
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Aug 24, 2010, at 4:15 PM, Chris Rogers wrote:
Hi Simon,
#if WEBAUDIO is fine.
Do you also prefer WebCore/webaudio like Chris Marrin, or WebCore/audio?
I am ambivalent. Everything in WebCore is ultimately web-related, so 'web' prefixes on the directories seem redundant. One direction would be to use /webaudio for a directory that contains files specifically related to the API, and /audio for platform directories that contain audio-related code that could be reused for other purposes. Simon
Hi Simon, thanks for helping here. By the way, anybody who is interested can look at the files in: https://svn.webkit.org/repository/webkit/branches/audio/WebCore/audio/ There are actually a number of audio files which could be considered re-usable, although I know of nothing at this time other than the web audio API which would use them: AudioBus.cpp Biquad.cpp Reverb.cpp FFTConvolver.cpp (and other FFT-related files) possibly also in this category are: Cone.cpp Distance.cpp MidSide.cpp SinWave.cpp Panner.cpp (and subclasses) (maybe a few others I've missed) Basically, these are the lowest-level building blocks which the higher-level parts (such as AudioContext, and AudioNode) use. These lowest-level building blocks do not (or should not) have any dependencies to the higher-level code which implement the actual API (and have IDL files). They also don't have any dependencies on other parts of WebCore, although they do use stuff in wtf. So are you suggesting: WebCore/webaudio <--- IDL files and API implementation WebCore/platform/audio <--- lower-level building blocks such as AudioBus.cpp then with the conditional #if WEB_AUDIO <----- I added an underscore here Chris On Tue, Aug 24, 2010 at 4:22 PM, Simon Fraser <simon.fraser@apple.com>wrote:
On Aug 24, 2010, at 4:15 PM, Chris Rogers wrote:
Hi Simon,
#if WEBAUDIO is fine.
Do you also prefer WebCore/webaudio like Chris Marrin, or WebCore/audio?
I am ambivalent. Everything in WebCore is ultimately web-related, so 'web' prefixes on the directories seem redundant.
One direction would be to use /webaudio for a directory that contains files specifically related to the API, and /audio for platform directories that contain audio-related code that could be reused for other purposes.
Simon
On Aug 24, 2010, at 4:47 PM, Chris Rogers wrote:
Hi Simon, thanks for helping here.
By the way, anybody who is interested can look at the files in: https://svn.webkit.org/repository/webkit/branches/audio/WebCore/audio/
There are actually a number of audio files which could be considered re-usable, although I know of nothing at this time other than the web audio API which would use them:
AudioBus.cpp Biquad.cpp Reverb.cpp FFTConvolver.cpp (and other FFT-related files)
possibly also in this category are: Cone.cpp Distance.cpp MidSide.cpp SinWave.cpp Panner.cpp (and subclasses) (maybe a few others I've missed)
Basically, these are the lowest-level building blocks which the higher-level parts (such as AudioContext, and AudioNode) use. These lowest-level building blocks do not (or should not) have any dependencies to the higher-level code which implement the actual API (and have IDL files). They also don't have any dependencies on other parts of WebCore, although they do use stuff in wtf.
So are you suggesting:
WebCore/webaudio <--- IDL files and API implementation WebCore/platform/audio <--- lower-level building blocks such as AudioBus.cpp
Fine by me!
then with the conditional
#if WEB_AUDIO <----- I added an underscore here
That would be #if ENABLE(WEB_AUDIO) in the code. Simon
Good, it looks like we're getting close. So we've agreed to how the files should be split up, but Darin Fisher still was concerned about the 'web' prefix. Darin, was it the directory name WebCore/webaudio that you didn't like or: #if ENABLE(WEB_AUDIO) Alternatives might be: WebCore/audio or WebCore/audiocontext #if ENABLE(AUDIO_CONTEXT) or #if ENABLE(AUDIO_API) I'm assuming that WebCore/platform/audio we can all agree on... Chris On Tue, Aug 24, 2010 at 5:20 PM, Simon Fraser <simon.fraser@apple.com>wrote:
On Aug 24, 2010, at 4:47 PM, Chris Rogers wrote:
Hi Simon, thanks for helping here.
By the way, anybody who is interested can look at the files in: https://svn.webkit.org/repository/webkit/branches/audio/WebCore/audio/
There are actually a number of audio files which could be considered re-usable, although I know of nothing at this time other than the web audio API which would use them:
AudioBus.cpp Biquad.cpp Reverb.cpp FFTConvolver.cpp (and other FFT-related files)
possibly also in this category are: Cone.cpp Distance.cpp MidSide.cpp SinWave.cpp Panner.cpp (and subclasses) (maybe a few others I've missed)
Basically, these are the lowest-level building blocks which the higher-level parts (such as AudioContext, and AudioNode) use. These lowest-level building blocks do not (or should not) have any dependencies to the higher-level code which implement the actual API (and have IDL files). They also don't have any dependencies on other parts of WebCore, although they do use stuff in wtf.
So are you suggesting:
WebCore/webaudio <--- IDL files and API implementation WebCore/platform/audio <--- lower-level building blocks such as AudioBus.cpp
Fine by me!
then with the conditional
#if WEB_AUDIO <----- I added an underscore here
That would be #if ENABLE(WEB_AUDIO) in the code.
Simon
My objection (and it's only a slight one) was about using "Web" as a prefix for class names defined in WebCore. WebSockets is the main example of the Web prefix used in WebCore, and that's probably because "sockets" by itself would be too confusing. However, I have found the use of the Web prefix in WebCore to lead to some confusion by itself since WebKit layers tend to use the Web prefix for their classes/interfaces. I realize that the WebCore:: namespace makes this issue technically moot. I'm just concerned about it being confusing to have WebCore::WebFoo and WebKit API level WebFoo. Regards, -Darin On Tue, Aug 24, 2010 at 5:29 PM, Chris Rogers <crogers@google.com> wrote:
Good, it looks like we're getting close. So we've agreed to how the files should be split up, but Darin Fisher still was concerned about the 'web' prefix.
Darin, was it the directory name WebCore/webaudio that you didn't like or: #if ENABLE(WEB_AUDIO)
Alternatives might be:
WebCore/audio or WebCore/audiocontext #if ENABLE(AUDIO_CONTEXT) or #if ENABLE(AUDIO_API)
I'm assuming that WebCore/platform/audio we can all agree on...
Chris
On Tue, Aug 24, 2010 at 5:20 PM, Simon Fraser <simon.fraser@apple.com>wrote:
On Aug 24, 2010, at 4:47 PM, Chris Rogers wrote:
Hi Simon, thanks for helping here.
By the way, anybody who is interested can look at the files in: https://svn.webkit.org/repository/webkit/branches/audio/WebCore/audio/
There are actually a number of audio files which could be considered re-usable, although I know of nothing at this time other than the web audio API which would use them:
AudioBus.cpp Biquad.cpp Reverb.cpp FFTConvolver.cpp (and other FFT-related files)
possibly also in this category are: Cone.cpp Distance.cpp MidSide.cpp SinWave.cpp Panner.cpp (and subclasses) (maybe a few others I've missed)
Basically, these are the lowest-level building blocks which the higher-level parts (such as AudioContext, and AudioNode) use. These lowest-level building blocks do not (or should not) have any dependencies to the higher-level code which implement the actual API (and have IDL files). They also don't have any dependencies on other parts of WebCore, although they do use stuff in wtf.
So are you suggesting:
WebCore/webaudio <--- IDL files and API implementation WebCore/platform/audio <--- lower-level building blocks such as AudioBus.cpp
Fine by me!
then with the conditional
#if WEB_AUDIO <----- I added an underscore here
That would be #if ENABLE(WEB_AUDIO) in the code.
Simon
On Aug 24, 2010, at 8:39 PM, Darin Fisher wrote:
My objection (and it's only a slight one) was about using "Web" as a prefix for class names defined in WebCore.
WebSockets is the main example of the Web prefix used in WebCore, and that's probably because "sockets" by itself would be too confusing. However, I have found the use of the Web prefix in WebCore to lead to some confusion by itself since WebKit layers tend to use the Web prefix for their classes/interfaces.
I realize that the WebCore:: namespace makes this issue technically moot. I'm just concerned about it being confusing to have WebCore::WebFoo and WebKit API level WebFoo.
I don't think there is any plan to give the *class* name a "Web" prefix, we are just talking about the names of the WebKit folders and the compile flag. eric
On Tue, Aug 24, 2010 at 5:29 PM, Chris Rogers <crogers@google.com> wrote: Good, it looks like we're getting close. So we've agreed to how the files should be split up, but Darin Fisher still was concerned about the 'web' prefix.
Darin, was it the directory name WebCore/webaudio that you didn't like or: #if ENABLE(WEB_AUDIO)
Alternatives might be:
WebCore/audio or WebCore/audiocontext #if ENABLE(AUDIO_CONTEXT) or #if ENABLE(AUDIO_API)
I'm assuming that WebCore/platform/audio we can all agree on...
Chris
On Tue, Aug 24, 2010 at 5:20 PM, Simon Fraser <simon.fraser@apple.com> wrote: On Aug 24, 2010, at 4:47 PM, Chris Rogers wrote:
Hi Simon, thanks for helping here.
By the way, anybody who is interested can look at the files in: https://svn.webkit.org/repository/webkit/branches/audio/WebCore/audio/
There are actually a number of audio files which could be considered re-usable, although I know of nothing at this time other than the web audio API which would use them:
AudioBus.cpp Biquad.cpp Reverb.cpp FFTConvolver.cpp (and other FFT-related files)
possibly also in this category are: Cone.cpp Distance.cpp MidSide.cpp SinWave.cpp Panner.cpp (and subclasses) (maybe a few others I've missed)
Basically, these are the lowest-level building blocks which the higher-level parts (such as AudioContext, and AudioNode) use. These lowest-level building blocks do not (or should not) have any dependencies to the higher-level code which implement the actual API (and have IDL files). They also don't have any dependencies on other parts of WebCore, although they do use stuff in wtf.
So are you suggesting:
WebCore/webaudio <--- IDL files and API implementation WebCore/platform/audio <--- lower-level building blocks such as AudioBus.cpp
Fine by me!
then with the conditional
#if WEB_AUDIO <----- I added an underscore here
That would be #if ENABLE(WEB_AUDIO) in the code.
Simon
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Tue, Aug 24, 2010 at 8:55 PM, Eric Carlson <eric.carlson@apple.com>wrote:
On Aug 24, 2010, at 8:39 PM, Darin Fisher wrote:
My objection (and it's only a slight one) was about using "Web" as a prefix for class names defined in WebCore.
WebSockets is the main example of the Web prefix used in WebCore, and that's probably because "sockets" by itself would be too confusing. However, I have found the use of the Web prefix in WebCore to lead to some confusion by itself since WebKit layers tend to use the Web prefix for their classes/interfaces.
I realize that the WebCore:: namespace makes this issue technically moot. I'm just concerned about it being confusing to have WebCore::WebFoo and WebKit API level WebFoo.
I don't think there is any plan to give the *class* name a "Web" prefix, we are just talking about the names of the WebKit folders and the compile flag.
eric
Ah, OK. Thanks for clearing that up for me. It seemed like things were headed toward Web* classes given the contents of this folder: http://trac.webkit.org/browser/trunk/WebCore/websockets -Darin
On Tue, Aug 24, 2010 at 5:29 PM, Chris Rogers <crogers@google.com> wrote:
Good, it looks like we're getting close. So we've agreed to how the files should be split up, but Darin Fisher still was concerned about the 'web' prefix.
Darin, was it the directory name WebCore/webaudio that you didn't like or: #if ENABLE(WEB_AUDIO)
Alternatives might be:
WebCore/audio or WebCore/audiocontext #if ENABLE(AUDIO_CONTEXT) or #if ENABLE(AUDIO_API)
I'm assuming that WebCore/platform/audio we can all agree on...
Chris
On Tue, Aug 24, 2010 at 5:20 PM, Simon Fraser <simon.fraser@apple.com>wrote:
On Aug 24, 2010, at 4:47 PM, Chris Rogers wrote:
Hi Simon, thanks for helping here.
By the way, anybody who is interested can look at the files in: https://svn.webkit.org/repository/webkit/branches/audio/WebCore/audio/
There are actually a number of audio files which could be considered re-usable, although I know of nothing at this time other than the web audio API which would use them:
AudioBus.cpp Biquad.cpp Reverb.cpp FFTConvolver.cpp (and other FFT-related files)
possibly also in this category are: Cone.cpp Distance.cpp MidSide.cpp SinWave.cpp Panner.cpp (and subclasses) (maybe a few others I've missed)
Basically, these are the lowest-level building blocks which the higher-level parts (such as AudioContext, and AudioNode) use. These lowest-level building blocks do not (or should not) have any dependencies to the higher-level code which implement the actual API (and have IDL files). They also don't have any dependencies on other parts of WebCore, although they do use stuff in wtf.
So are you suggesting:
WebCore/webaudio <--- IDL files and API implementation WebCore/platform/audio <--- lower-level building blocks such as AudioBus.cpp
Fine by me!
then with the conditional
#if WEB_AUDIO <----- I added an underscore here
That would be #if ENABLE(WEB_AUDIO) in the code.
Simon
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Ok, then it looks like we'll go with this for the directory names: WebCore/webaudio WebCore/platform/audio And this for the feature define: #if ENABLE(WEB_AUDIO) Thanks everybody, Chris On Tue, Aug 24, 2010 at 9:02 PM, Darin Fisher <darin@chromium.org> wrote:
On Tue, Aug 24, 2010 at 8:55 PM, Eric Carlson <eric.carlson@apple.com>wrote:
On Aug 24, 2010, at 8:39 PM, Darin Fisher wrote:
My objection (and it's only a slight one) was about using "Web" as a prefix for class names defined in WebCore.
WebSockets is the main example of the Web prefix used in WebCore, and that's probably because "sockets" by itself would be too confusing. However, I have found the use of the Web prefix in WebCore to lead to some confusion by itself since WebKit layers tend to use the Web prefix for their classes/interfaces.
I realize that the WebCore:: namespace makes this issue technically moot. I'm just concerned about it being confusing to have WebCore::WebFoo and WebKit API level WebFoo.
I don't think there is any plan to give the *class* name a "Web" prefix, we are just talking about the names of the WebKit folders and the compile flag.
eric
Ah, OK. Thanks for clearing that up for me. It seemed like things were headed toward Web* classes given the contents of this folder: http://trac.webkit.org/browser/trunk/WebCore/websockets -Darin
On Tue, Aug 24, 2010 at 5:29 PM, Chris Rogers <crogers@google.com> wrote:
Good, it looks like we're getting close. So we've agreed to how the files should be split up, but Darin Fisher still was concerned about the 'web' prefix.
Darin, was it the directory name WebCore/webaudio that you didn't like or: #if ENABLE(WEB_AUDIO)
Alternatives might be:
WebCore/audio or WebCore/audiocontext #if ENABLE(AUDIO_CONTEXT) or #if ENABLE(AUDIO_API)
I'm assuming that WebCore/platform/audio we can all agree on...
Chris
On Tue, Aug 24, 2010 at 5:20 PM, Simon Fraser <simon.fraser@apple.com>wrote:
On Aug 24, 2010, at 4:47 PM, Chris Rogers wrote:
Hi Simon, thanks for helping here.
By the way, anybody who is interested can look at the files in: https://svn.webkit.org/repository/webkit/branches/audio/WebCore/audio/
There are actually a number of audio files which could be considered re-usable, although I know of nothing at this time other than the web audio API which would use them:
AudioBus.cpp Biquad.cpp Reverb.cpp FFTConvolver.cpp (and other FFT-related files)
possibly also in this category are: Cone.cpp Distance.cpp MidSide.cpp SinWave.cpp Panner.cpp (and subclasses) (maybe a few others I've missed)
Basically, these are the lowest-level building blocks which the higher-level parts (such as AudioContext, and AudioNode) use. These lowest-level building blocks do not (or should not) have any dependencies to the higher-level code which implement the actual API (and have IDL files). They also don't have any dependencies on other parts of WebCore, although they do use stuff in wtf.
So are you suggesting:
WebCore/webaudio <--- IDL files and API implementation WebCore/platform/audio <--- lower-level building blocks such as AudioBus.cpp
Fine by me!
then with the conditional
#if WEB_AUDIO <----- I added an underscore here
That would be #if ENABLE(WEB_AUDIO) in the code.
Simon
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Chris - On Aug 24, 2010, at 4:47 PM, Chris Rogers wrote:
Hi Simon, thanks for helping here.
By the way, anybody who is interested can look at the files in: https://svn.webkit.org/repository/webkit/branches/audio/WebCore/audio/
There are actually a number of audio files which could be considered re-usable, although I know of nothing at this time other than the web audio API which would use them:
AudioBus.cpp Biquad.cpp Reverb.cpp FFTConvolver.cpp (and other FFT-related files)
possibly also in this category are: Cone.cpp Distance.cpp MidSide.cpp SinWave.cpp Panner.cpp (and subclasses) (maybe a few others I've missed)
Basically, these are the lowest-level building blocks which the higher-level parts (such as AudioContext, and AudioNode) use. These lowest-level building blocks do not (or should not) have any dependencies to the higher-level code which implement the actual API (and have IDL files). They also don't have any dependencies on other parts of WebCore, although they do use stuff in wtf.
So are you suggesting:
WebCore/webaudio <--- IDL files and API implementation WebCore/platform/audio <--- lower-level building blocks such as AudioBus.cpp
This sounds good to me! eric
This is fantastically wonderful. Let me know what I can do to help. I'm happy to do reviews for what I can. -eric On Tue, Aug 24, 2010 at 12:05 PM, Chris Rogers <crogers@google.com> wrote:
Over the past months I've been refining the web audio API implementation that I've been developing in the 'audio' branch of WebKit (per Maciej's recommendation). The API has been through a good amount of review by WebKit developers at Apple, Google, and in the W3C Audio Incubator group. For those who are interested, the draft specification is here: http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specifi... I have working demos here: http://chromium.googlecode.com/svn/trunk/samples/audio/index.html I'll be posting a series of patches to migrate the working code from the audio branch to WebKit trunk. Most of the files are new, with only a few places which will touch existing WebKit files (such as EventTarget, Event). The files will be conditionally compiled. I'm considering using the following enable: #if ENABLE(AUDIOCONTEXT) After discussing the directory layout in some detail with Eric Carlson, Chris Marrin, Simon Fraser, and Jer Noble, we've decided that the files will primarily live in two places: WebCore/audio WebCore/platform/audio I know that some had expressed concern that a directory called 'audio' in WebCore would be confused with the audio element. The reason I think 'audio' would be a good name is because the API does have a direct relationship to the audio element and, over time, when the API becomes more broadly used will be associated with the audio capabilities of the web platform. That said, if anybody has grave concerns over this name, then we can discuss alternatives. Anyway, I just wanted to bring these coming changes to everyone's attention. Regards, Chris Rogers
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
This sounds like a reasonable plan. I have no strong feelings about any of the naming options, but I like the overall idea of getting this code into trunk now, using a feature define, and separating the Web-facing parts from the "platform" implementation parts. - Maciej On Aug 24, 2010, at 12:05 PM, Chris Rogers wrote:
Over the past months I've been refining the web audio API implementation that I've been developing in the 'audio' branch of WebKit (per Maciej's recommendation). The API has been through a good amount of review by WebKit developers at Apple, Google, and in the W3C Audio Incubator group. For those who are interested, the draft specification is here: http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specifi...
I have working demos here: http://chromium.googlecode.com/svn/trunk/samples/audio/index.html
I'll be posting a series of patches to migrate the working code from the audio branch to WebKit trunk. Most of the files are new, with only a few places which will touch existing WebKit files (such as EventTarget, Event). The files will be conditionally compiled. I'm considering using the following enable:
#if ENABLE(AUDIOCONTEXT)
After discussing the directory layout in some detail with Eric Carlson, Chris Marrin, Simon Fraser, and Jer Noble, we've decided that the files will primarily live in two places:
WebCore/audio WebCore/platform/audio
I know that some had expressed concern that a directory called 'audio' in WebCore would be confused with the audio element. The reason I think 'audio' would be a good name is because the API does have a direct relationship to the audio element and, over time, when the API becomes more broadly used will be associated with the audio capabilities of the web platform. That said, if anybody has grave concerns over this name, then we can discuss alternatives.
Anyway, I just wanted to bring these coming changes to everyone's attention.
Regards, Chris Rogers
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
participants (8)
-
Chris Marrin
-
Chris Rogers
-
Darin Fisher
-
Darin Fisher
-
Eric Carlson
-
Eric Seidel
-
Maciej Stachowiak
-
Simon Fraser