Merge lp://qastaging/~mixxxdevelopers/mixxx/features_m4a_win7 into lp://qastaging/mixxx/1.10

I missed this last night so I'll reply here:
[00:42] <Pegasus_RPG> just for my own knowledge, what would it take to make it a plugin?
Not much, it's a few build system changes and adding a handful of plugin metadata-providing statics.

[00:48] <Pegasus_RPG> (we could even pack in the Vista platform upgrade and auto-install that if needed)
It's a 5MB update for i386 and 12MB for x86-64, quite large.

Also, reminder to myself:
[00:32] <Pegasus_RPG> ok. Also, can you change the path to the SDK to use a variable? A bunch get set in the build env.
[00:33] <Pegasus_RPG> I'm not sure what they are though
[00:33] <Pegasus_RPG> check setenv.bat
[00:33] <Pegasus_RPG> something like %SDKPATH%
[00:38] <bkgood> Pegasus_RPG: %MSSdk% seems to point in the right direction, is there a more standard one?
[00:38] <bkgood> (that's in my SetEnv.cmd file)
[00:38] <Pegasus_RPG> I don't know. That sounds good

Let me first formally say here: thank you for your work on this, Bill!

Yeah, I saw the update sizes after I said that. We can (and should) provide a pop-up box with links to the updates when ppl click on the M4A build/plugin on the downloads page (like we did for PortAudio on Ubuntu 8.04.)

Also, I strongly recommend making this a plugin rather than a separate build for supportability and less confusion. That way, no matter where people get Mixxx, they can just download the plugin (and the OS update if needed) and they're good to go. And we can even ship the plugin with Mixxx (if it's legal to do so and it will just silently not load or do nothing on a system that doesn't have the OS support.)

I've pushed a branch (lp:~mixxxdevelopers/mixxx/features_m4a_win7_plugin) with the necessary changes to make this a plugin if that's really want we want to do, and fixed that fixed-path in the build script.

And for my last bit of spam for the moment, soundsource plugins allocate a array of cstrings which are then filled and returned to the caller (SoundSourceProxy), which then owns the memory and must free it; this is how plugins communicate the file name extensions of the respective file types they support. I tried using the plugin I built with my branch with the 1.9 distribution (figured I could post a link to it to mixxx-devel for people to try out) and it's failing because of this malloc/free across dll boundaries (different msvcrt versions linked between mixxx.exe and soundsourcemediafoundation.dll). IMO the plugin API needs to be modified such that it frees its own memory (and stupid stuff like this is why I don't really want to deal with plugins).

Yick...well IIRC the whole plugin system was knocked out very quickly by Albert in an effort to get M4A support to users as quickly as possible, so there's probably room for improvement. Mind filing a bug for that?

In the meantime, I can build the plugin for 1.9 since I did the main Mixxx binary. Just let me know.

Hey Sean- yeah, if you wouldn't mind building the plugin to match the 1.9 msvcrt links, I'd appreciate it. I'm thinking we're still a bit out from 1.10 so maybe we could push this on 1.9 (forum and ml I guess) users and see if there are any bugs in the code needing quashed before it gets put in a release.

Thanks!

Hrm, Mfreadwrite.lib is not in the Windows 6.0 (Vista) SDK (the one I use for 1.9.x) so I can't build the plugin for 1.9. I guess this will have to wait until 1.10.

Bill: Doesn't Media Foundation allow us to use WMA and other kinds of file types in addition to M4A? If so, how much work would be involved in adding all of them that we don't currently support? What about just WMA/ASF?

We still need an official decision on whether or not to do this as a plugin. So the questions are:
1) Can we legally distribute the MediaFoundation-using binary without cost or restriction?
2) Will a Mixxx binary that has it built-in (as opposed to a plugin) still run fine (just without M4A/WMA support) on systems without the required system libraries, such as Windows 2000 & XP?

If the answer to both is yes, and RJ has no issues, I'd say let's go ahead and merge this for 1.10.

Note to self : look into dynamic load of the mf DLL. I'll reply in full when
I'm not on my phone.
On Oct 4, 2011 8:57 AM, "Sean M. Pappalardo" <email address hidden> wrote:
> Hrm, Mfreadwrite.lib is not in the Windows 6.0 (Vista) SDK (the one I use
for 1.9.x) so I can't build the plugin for 1.9. I guess this will have to
wait until 1.10.
>
> Bill: Doesn't Media Foundation allow us to use WMA and other kinds of file
types in addition to M4A? If so, how much work would be involved in adding
all of them that we don't currently support? What about just WMA/ASF?
>
> We still need an official decision on whether or not to do this as a
plugin. So the questions are:
> 1) Can we legally distribute the MediaFoundation-using binary without cost
or restriction?
> 2) Will a Mixxx binary that has it built-in (as opposed to a plugin) still
run fine (just without M4A/WMA support) on systems without the required
system libraries, such as Windows 2000 & XP?
>
> If the answer to both is yes, and RJ has no issues, I'd say let's go ahead
and merge this for 1.10.
> --
>
https://code.launchpad.net/~mixxxdevelopers/mixxx/features_m4a_win7/+merge/67111
> Your team Mixxx Development Team is requested to review the proposed merge
of lp:~mixxxdevelopers/mixxx/features_m4a_win7 into lp:mixxx/1.10.

> Bill: Doesn't Media Foundation allow us to use WMA and other kinds of file types in addition to M4A? If so, how much work would be involved in adding all of them that we don't currently support? What about just WMA/ASF?

Media Foundation supports: http://msdn.microsoft.com/en-us/library/windows/desktop/dd757927(v=vs.85).aspx. It would have the same minimum requirements as the AAC/m4a functionality because all systems having the necessary SourceReader interface also have the AAC decoder (and vice versa). I don't think the amount of work would be overwhelming but as we don't even have a wishlist bug for wma support I don't know that it's worth the time.

> 1) Can we legally distribute the MediaFoundation-using binary without cost or restriction?

Yes, it's the same situation as the Core Audio SoundSource. We're just calling an OS interface. They've paid for the AAC codec.

> 2) Will a Mixxx binary that has it built-in (as opposed to a plugin) still run fine (just without M4A/WMA support) on systems without the required system libraries, such as Windows 2000 & XP?

In short, no. Vista/2008 without the "Platform Update Supplement" and earlier versions of Windows will fail at run-time linking because they're missing either Media Foundation itself or the SourceReader interface. If a system were to exist with the SourceReader interface but not have the AAC decoder, Mixxx would run and simply fail to decode AAC, although I'm not aware of any situations in which this can occur.

Then we have to do this as a plugin since we support Windows 2000 and up. (MANY of our users are on XP.) So maybe void this merge request and submit one on the plugin branch.

Continued at https://code.launchpad.net/~mixxxdevelopers/mixxx/features_m4a_win7_plugin/+merge/78777