Bug 51424 - Add WebKitClient::createAudioDevice() for Chromium port of web audio API
Summary: Add WebKitClient::createAudioDevice() for Chromium port of web audio API
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Other OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-21 14:55 PST by Chris Rogers
Modified: 2011-01-05 17:19 PST (History)
4 users (show)

See Also:


Attachments
Patch (15.56 KB, patch)
2010-12-21 15:04 PST, Chris Rogers
no flags Details | Formatted Diff | Diff
Patch (15.30 KB, patch)
2010-12-21 16:44 PST, Chris Rogers
fishd: review+
fishd: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Rogers 2010-12-21 14:55:50 PST
Add WebKitClient::createAudioDevice() for Chromium port of web audio API
Comment 1 Chris Rogers 2010-12-21 15:04:07 PST
Created attachment 77154 [details]
Patch
Comment 2 Chris Rogers 2010-12-21 15:07:34 PST
Darin, does the callback typedef in WebAudioDevice need to have the WEBKIT_API prefix?
Comment 3 WebKit Review Bot 2010-12-21 15:07:39 PST
Attachment 77154 [details] did not build on chromium:
Build output: http://queues.webkit.org/results/7252090
Comment 4 Chris Rogers 2010-12-21 15:29:16 PST
The Chromium build error I'll fix by landing AudioBusChromium in another patch.
Comment 5 Darin Fisher (:fishd, Google) 2010-12-21 15:46:24 PST
Comment on attachment 77154 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=77154&action=review

> WebKit/chromium/public/WebAudioDevice.h:45
> +    typedef void (*RenderCallback)(std::vector<float*>& audioData, size_t numberOfFrames, void* userData);

note: we do not use STL types in the WebKit API.  please use WebVector, or just use a raw float* here.  do you need the callee to allocate the audioData buffer, or will it be preallocated to the maximum size by the caller?  if it will be preallocated, then passing a raw float* would seem fine.

> WebKit/chromium/public/WebKitClient.h:282
> +    // Audio --------------------------------------------------------------
> +    virtual WebAudioDevice* createAudioDevice(size_t bufferSize, unsigned numberOfChannels, double sampleRate, WebAudioDevice::RenderCallback, void* userData) { return 0; }

nit: add a new line below the section header.

The C++ way of passing user data to a function pointer is to define an interface
that folks can subclass.  Why not do that here?

class WebAudioRenderCallback {
public:
    virtual void renderFrames(float* audioData, size_t numberOfFrames) = 0;
protected:
    virtual ~WebAudioRenderCallback() {}
};

or you could also do this as an inner class:

class WebAudioDevice {
public:
    class RenderCallback {
    public:
        ...
    };
};

however the downside to it being an inner class is that you force WebKitClient.h
to also #include WebAudioDevice.h.  it would be nice to avoid that.

> WebKit/chromium/src/AudioDestinationChromium.cpp:40
> +using namespace std;

please avoid using the "std" namespace for container types in webkit code.

> WebKit/chromium/src/AudioDestinationChromium.cpp:41
> +using WebKit::webKitClient;

it is more commonplace to just do "using namespace WebKit" in WebKit code.

> WebKit/chromium/src/AudioDestinationChromium.cpp:102
> +void AudioDestinationChromium::renderDispatch(vector<float*>& audioData, size_t numberOfFrames, void* userData)

if you define an interface for the render callback function, then you would
not need to implement this thunk function yourself.
Comment 6 WebKit Review Bot 2010-12-21 16:04:53 PST
Attachment 77154 [details] did not build on chromium:
Build output: http://queues.webkit.org/results/7275108
Comment 7 Chris Rogers 2010-12-21 16:36:09 PST
Comment on attachment 77154 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=77154&action=review

>> WebKit/chromium/public/WebAudioDevice.h:45
>> +    typedef void (*RenderCallback)(std::vector<float*>& audioData, size_t numberOfFrames, void* userData);
> 
> note: we do not use STL types in the WebKit API.  please use WebVector, or just use a raw float* here.  do you need the callee to allocate the audioData buffer, or will it be preallocated to the maximum size by the caller?  if it will be preallocated, then passing a raw float* would seem fine.

FIXED: I switched over to WebVector.  I can't use raw float* since it's an array of pointers to float (planar non-interleaved)

>> WebKit/chromium/public/WebKitClient.h:282
>> +    virtual WebAudioDevice* createAudioDevice(size_t bufferSize, unsigned numberOfChannels, double sampleRate, WebAudioDevice::RenderCallback, void* userData) { return 0; }
> 
> nit: add a new line below the section header.
> 
> The C++ way of passing user data to a function pointer is to define an interface
> that folks can subclass.  Why not do that here?
> 
> class WebAudioRenderCallback {
> public:
>     virtual void renderFrames(float* audioData, size_t numberOfFrames) = 0;
> protected:
>     virtual ~WebAudioRenderCallback() {}
> };
> 
> or you could also do this as an inner class:
> 
> class WebAudioDevice {
> public:
>     class RenderCallback {
>     public:
>         ...
>     };
> };
> 
> however the downside to it being an inner class is that you force WebKitClient.h
> to also #include WebAudioDevice.h.  it would be nice to avoid that.

FIXED: added the new line and changed this to use an inner class as you suggest instead of old-fashioned callback

>> WebKit/chromium/src/AudioDestinationChromium.cpp:40
>> +using namespace std;
> 
> please avoid using the "std" namespace for container types in webkit code.

FIXED

>> WebKit/chromium/src/AudioDestinationChromium.cpp:41
>> +using WebKit::webKitClient;
> 
> it is more commonplace to just do "using namespace WebKit" in WebKit code.

FIXED

>> WebKit/chromium/src/AudioDestinationChromium.cpp:102
>> +void AudioDestinationChromium::renderDispatch(vector<float*>& audioData, size_t numberOfFrames, void* userData)
> 
> if you define an interface for the render callback function, then you would
> not need to implement this thunk function yourself.

FIXED
Comment 8 Darin Fisher (:fishd, Google) 2010-12-21 16:41:44 PST
(In reply to comment #7)
> >> WebKit/chromium/public/WebAudioDevice.h:45
> >> +    typedef void (*RenderCallback)(std::vector<float*>& audioData, size_t numberOfFrames, void* userData);
> > 
> > note: we do not use STL types in the WebKit API.  please use WebVector, or just use a raw float* here.  do you need the callee to allocate the audioData buffer, or will it be preallocated to the maximum size by the caller?  if it will be preallocated, then passing a raw float* would seem fine.
> 
> FIXED: I switched over to WebVector.  I can't use raw float* since it's an array of pointers to float (planar non-interleaved)

oh, right!  what about float** then?  aren't you concerned about the overhead of copying the buffers that a WebVector imposes?


> > however the downside to it being an inner class is that you force WebKitClient.h
> > to also #include WebAudioDevice.h.  it would be nice to avoid that.
> 
> FIXED: added the new line and changed this to use an inner class as you suggest instead of old-fashioned callback

i also suggested not using inner classes since it forces a #include.  any thoughts
on that?
Comment 9 Chris Rogers 2010-12-21 16:44:14 PST
Created attachment 77165 [details]
Patch
Comment 10 Chris Rogers 2010-12-21 16:49:38 PST
(In reply to comment #8)
> (In reply to comment #7)
> > >> WebKit/chromium/public/WebAudioDevice.h:45
> > >> +    typedef void (*RenderCallback)(std::vector<float*>& audioData, size_t numberOfFrames, void* userData);
> > > 
> > > note: we do not use STL types in the WebKit API.  please use WebVector, or just use a raw float* here.  do you need the callee to allocate the audioData buffer, or will it be preallocated to the maximum size by the caller?  if it will be preallocated, then passing a raw float* would seem fine.
> > 
> > FIXED: I switched over to WebVector.  I can't use raw float* since it's an array of pointers to float (planar non-interleaved)
> 
> oh, right!  what about float** then?  aren't you concerned about the overhead of copying the buffers that a WebVector imposes?

The only overhead is copying the pointers, but not the actual PCM data.  But, if you really don't like WebVector, then we can switch to float**.
WebVector just seems a little safer, since we can check its size...



> 
> > > however the downside to it being an inner class is that you force WebKitClient.h
> > > to also #include WebAudioDevice.h.  it would be nice to avoid that.
> > 
> > FIXED: added the new line and changed this to use an inner class as you suggest instead of old-fashioned callback
> 
> i also suggested not using inner classes since it forces a #include.  any thoughts
> on that?

It's up to you.  I like the inner class since it seems cleaner, but if you feel the extra include is too big a build-time penalty then I can change it...
Comment 11 WebKit Review Bot 2010-12-21 16:51:23 PST
Attachment 77165 [details] did not build on chromium:
Build output: http://queues.webkit.org/results/7255096
Comment 12 Darin Fisher (:fishd, Google) 2011-01-05 15:54:08 PST
Comment on attachment 77165 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=77165&action=review

> WebKit/chromium/src/AudioDestinationChromium.cpp:47
> +const unsigned CallbackBufferSize = 2048;

I'm pretty sure the preferred style for constants is to use variableNaming style.

> WebKit/chromium/src/AudioDestinationChromium.cpp:105
> +    if (!isNumberOfChannelsGood)

nit: instead of repeating the expression, use ASSERT_NOT_REACHED if the branch is taken.

> WebKit/chromium/src/AudioDestinationChromium.cpp:110
> +    if (!isBufferSizeGood)

ditto
Comment 13 Chris Rogers 2011-01-05 17:19:45 PST
Committed r75118: <http://trac.webkit.org/changeset/75118>