Include audio firmware with libfreenect as function calls.

[ofTheo]

In openFrameworks we have the audio firmware binaries for 1473 and 1517 as functions which are loaded into libfreenect on runtime.

See: https://github.com/openframeworks/openFrameworks/blob/master/addons/ofxKinect/src/extra/ofxKinectExtras.h

I know it may be a bit controversial to including the audio firmware in the repo, but I don't see MSFT having issue with it and the plus side is that there is less needed in the way of setup steps.

Given as LED, Accel and Motor controls are dependent on having the audio firmware loaded for newer devices it seems that it might be worth considering this approach.

Feel free to close this if you strongly disagree :)
Theo

[JoshBlake]

Let me look into whether MSFT would have issue with it, but I would presume the default is they would have issue.

[piedar]

@JoshBlake Did you ever hear back on this? Missing firmware is still the number one source of bug reports.

[ofTheo]

Maybe it could be included but later removed if Microsoft requests it? For what its worth its been in OF for the last 3+ years

…

On Oct 10, 2017, at 10:38 AM, piedar ***@***.***> wrote: @JoshBlake Did you ever hear back on this? Missing firmware is still the number one source of bug reports. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[JoshBlake]

@piedar Haha, no I didn't. But I think at this point @ofTheo is right. There isn't really a Kinect team anymore -- they're all now part of the larger Analog team that includes Hololens. I think libfreenect could include the audio firmware as long as the README etc. make it clear that binary blob is copyright (c) Microsoft and not subject to the OSS license. You may also consider whether the firmware binary should be in a separate repo and included via a submodule, which would keep this repository history pure in case the binary must be removed later.

[piedar]

Thanks for the feedback! Looks like I have a project for the weekend. I'm thinking a submodule is a good idea, and I'll use the BUILD_REDIST_PACKAGE build flag to decide whether to bundle the firmware.

One thing I've yet to decide is whether to use the memory or file loading scheme. The memory strategy is easier to code, but it would be nice if end-users can drop in the firmware later, especially since Debian, Fedora, etc. are not likely to want to bundle this stuff. Either way, I think the old audios.bin way has got to go...