Should we stop linking to FAudio for our XAudio implementation?
Hi all, This may seem something of a controversial question, but I am concerned that FAudio is not a good fit for Wine, mainly because of its licensing considerations. Recently I found a bug in FAudio wherein it does not properly handle unaligned buffers. While in the process of drafting a fix, I was stymied multiple times by its rather broken resampler, and when I sought to try to fix that, I found that it was a rather difficult endeavour, which led me to propose replacing it with an external library such as GStreamer. Unfortunately FAudio cannot, counterintuitively, link to LGPL code, because it needs to be able to run on embedded platforms, which (for reasons I do not understand) cannot ship any LGPL code. While I can to some degree respect the decision of FAudio to target platforms that forbid copyleft licensing, I do not think this aligns well with the interests of the Wine project—a project which specifically chose copyleft licensing. More personally, I do not want to have to fix the FAudio resampler or implement another resampler with a non-copyleft license (and I am not even particularly sure that I can, given my familiarity with resamplers in LGPL projects such as GStreamer and Wine). Besides this, it is probably worth noting that we do not seem to gain much from continuing to rely on FAudio. There would be the usual benefit of relying on upstream development, but development on FAudio seems very scarce, especially when restricted to parts relevant to Wine, and much of that is from Wine contributors anyway. (And, of course, due to our bundling practices, there is hardly the usual benefit of size or modularity in linking to external libraries.) Of course we would be well served by simply importing the current version of FAudio; I do not mean to propose that we reimplement XAudio entirely, but rather begin to modify it in ways that would not be acceptable upstream. This would mean replacing the resampler, as well as perhaps also the mixer, and probably with the ones from GStreamer, which is already a dependency of ours, and which has a very featureful resampler and mixer, and a much higher rate of development overall. Do others in the Wine community have thoughts or opinions on this matter? ἔρρωσθε, Zeb
On 3/29/23 02:31, Zebediah Figura wrote:
Hi all,
This may seem something of a controversial question, but I am concerned that FAudio is not a good fit for Wine, mainly because of its licensing considerations.
Recently I found a bug in FAudio wherein it does not properly handle unaligned buffers. While in the process of drafting a fix, I was stymied multiple times by its rather broken resampler, and when I sought to try to fix that, I found that it was a rather difficult endeavour, which led me to propose replacing it with an external library such as GStreamer. Unfortunately FAudio cannot, counterintuitively, link to LGPL code, because it needs to be able to run on embedded platforms, which (for reasons I do not understand) cannot ship any LGPL code.
While I can to some degree respect the decision of FAudio to target platforms that forbid copyleft licensing, I do not think this aligns well with the interests of the Wine project—a project which specifically chose copyleft licensing. More personally, I do not want to have to fix the FAudio resampler or implement another resampler with a non-copyleft license (and I am not even particularly sure that I can, given my familiarity with resamplers in LGPL projects such as GStreamer and Wine).
Besides this, it is probably worth noting that we do not seem to gain much from continuing to rely on FAudio. There would be the usual benefit of relying on upstream development, but development on FAudio seems very scarce, especially when restricted to parts relevant to Wine, and much of that is from Wine contributors anyway. (And, of course, due to our bundling practices, there is hardly the usual benefit of size or modularity in linking to external libraries.)
Of course we would be well served by simply importing the current version of FAudio; I do not mean to propose that we reimplement XAudio entirely, but rather begin to modify it in ways that would not be acceptable upstream.
This would mean replacing the resampler, as well as perhaps also the mixer, and probably with the ones from GStreamer, which is already a dependency of ours, and which has a very featureful resampler and mixer, and a much higher rate of development overall.
Do others in the Wine community have thoughts or opinions on this matter?
ἔρρωσθε, Zeb
Fwiw FAudio has linked with GStreamer in the past, conditionally at least. -- Rémi Bernon <rbernon(a)codeweavers.com>
Not only did FAudio link to gstreamer but prior to this it linked to FFmpeg. The gstreamer backend was removed in 22.02, FAudio, there assumption seems to be that wine wouldn’t require the gstreamer backend and will be using MediaFoundation… On Wed, Mar 29, 2023 at 2:52 AM Rémi Bernon <rbernon(a)codeweavers.com> wrote:
On 3/29/23 02:31, Zebediah Figura wrote:
Hi all,
This may seem something of a controversial question, but I am concerned that FAudio is not a good fit for Wine, mainly because of its licensing considerations.
Recently I found a bug in FAudio wherein it does not properly handle unaligned buffers. While in the process of drafting a fix, I was stymied multiple times by its rather broken resampler, and when I sought to try to fix that, I found that it was a rather difficult endeavour, which led me to propose replacing it with an external library such as GStreamer. Unfortunately FAudio cannot, counterintuitively, link to LGPL code, because it needs to be able to run on embedded platforms, which (for reasons I do not understand) cannot ship any LGPL code.
While I can to some degree respect the decision of FAudio to target platforms that forbid copyleft licensing, I do not think this aligns well with the interests of the Wine project—a project which specifically chose copyleft licensing. More personally, I do not want to have to fix the FAudio resampler or implement another resampler with a non-copyleft license (and I am not even particularly sure that I can, given my familiarity with resamplers in LGPL projects such as GStreamer and Wine).
Besides this, it is probably worth noting that we do not seem to gain much from continuing to rely on FAudio. There would be the usual benefit of relying on upstream development, but development on FAudio seems very scarce, especially when restricted to parts relevant to Wine, and much of that is from Wine contributors anyway. (And, of course, due to our bundling practices, there is hardly the usual benefit of size or modularity in linking to external libraries.)
Of course we would be well served by simply importing the current version of FAudio; I do not mean to propose that we reimplement XAudio entirely, but rather begin to modify it in ways that would not be acceptable upstream.
This would mean replacing the resampler, as well as perhaps also the mixer, and probably with the ones from GStreamer, which is already a dependency of ours, and which has a very featureful resampler and mixer, and a much higher rate of development overall.
Do others in the Wine community have thoughts or opinions on this matter?
ἔρρωσθε, Zeb
Fwiw FAudio has linked with GStreamer in the past, conditionally at least.
-- Rémi Bernon <rbernon(a)codeweavers.com>
On 3/29/23 17:09, Dean Greer wrote:
Not only did FAudio link to gstreamer but prior to this it linked to FFmpeg.
The gstreamer backend was removed in 22.02, FAudio, there assumption seems to be that wine wouldn’t require the gstreamer backend and will be using MediaFoundation…
Indeed, BTW it could also use that backend to get through to some GStreamer audio resampler plugin on Wine, although that adds a bit of indirection (maybe not so much). -- Rémi Bernon <rbernon(a)codeweavers.com>
On 3/29/23 01:51, Rémi Bernon wrote:
On 3/29/23 02:31, Zebediah Figura wrote:
Hi all,
This may seem something of a controversial question, but I am concerned that FAudio is not a good fit for Wine, mainly because of its licensing considerations.
Recently I found a bug in FAudio wherein it does not properly handle unaligned buffers. While in the process of drafting a fix, I was stymied multiple times by its rather broken resampler, and when I sought to try to fix that, I found that it was a rather difficult endeavour, which led me to propose replacing it with an external library such as GStreamer. Unfortunately FAudio cannot, counterintuitively, link to LGPL code, because it needs to be able to run on embedded platforms, which (for reasons I do not understand) cannot ship any LGPL code.
While I can to some degree respect the decision of FAudio to target platforms that forbid copyleft licensing, I do not think this aligns well with the interests of the Wine project—a project which specifically chose copyleft licensing. More personally, I do not want to have to fix the FAudio resampler or implement another resampler with a non-copyleft license (and I am not even particularly sure that I can, given my familiarity with resamplers in LGPL projects such as GStreamer and Wine).
Besides this, it is probably worth noting that we do not seem to gain much from continuing to rely on FAudio. There would be the usual benefit of relying on upstream development, but development on FAudio seems very scarce, especially when restricted to parts relevant to Wine, and much of that is from Wine contributors anyway. (And, of course, due to our bundling practices, there is hardly the usual benefit of size or modularity in linking to external libraries.)
Of course we would be well served by simply importing the current version of FAudio; I do not mean to propose that we reimplement XAudio entirely, but rather begin to modify it in ways that would not be acceptable upstream.
This would mean replacing the resampler, as well as perhaps also the mixer, and probably with the ones from GStreamer, which is already a dependency of ours, and which has a very featureful resampler and mixer, and a much higher rate of development overall.
Do others in the Wine community have thoughts or opinions on this matter?
ἔρρωσθε, Zeb
Fwiw FAudio has linked with GStreamer in the past, conditionally at least.
That came up in the discussion, I think (sorry, I should have thought to mention it.) The problem I see is that while FAudio can *optionally* link to GStreamer, that still means the old backend will need to be kept around. In the case of the bug I'm trying to fix, I don't think it's particularly possible to do that without fixing the old resampler as well.
Unfortunately FAudio cannot, counterintuitively, link to LGPL code, because it needs to be able to run on embedded platforms, which (for reasons I do not understand) cannot ship any LGPL code.
It's quite simple. If a platform (such as Nintendo Switch) does not allow users to sideload their own code on it, it's not possible to comply with the terms of the LGPL while shipping LGPL code on that platform, because the user cannot install their own modified version of the LGPL library.
On 3/29/23 12:00, Esme Povirk wrote:
Unfortunately FAudio cannot, counterintuitively, link to LGPL code, because it needs to be able to run on embedded platforms, which (for reasons I do not understand) cannot ship any LGPL code.
It's quite simple. If a platform (such as Nintendo Switch) does not allow users to sideload their own code on it, it's not possible to comply with the terms of the LGPL while shipping LGPL code on that platform, because the user cannot install their own modified version of the LGPL library.
Isn't that what tivoization is, or do I misunderstand? And if so, I would assume that only restricts (L)GPL v3, whereas LGPL v2 would still be fine.
OK, maybe it's more complicated than I thought. Here's my best guess from what I know: In the case of Tivoization, the GPL code isn't linked with any proprietary code. The user can still build the program as a whole, but is unable to sign it so that the device will execute it. In this case, LGPL code is linked with proprietary code: both the game itself and the vendor's libraries. In this situation, section 6 requires a way for the user to relink the rest of the code to their modified version of the library: either source code, object code, or a dynamically linked binary. A game developer could theoretically distribute their game's source code or object code without the assets, but they cannot redistribute the tools and libraries from the platform vendor to the general public. On Wed, Mar 29, 2023 at 1:28 PM Zebediah Figura <zfigura(a)codeweavers.com> wrote:
On 3/29/23 12:00, Esme Povirk wrote:
Unfortunately FAudio cannot, counterintuitively, link to LGPL code, because it needs to be able to run on embedded platforms, which (for reasons I do not understand) cannot ship any LGPL code.
It's quite simple. If a platform (such as Nintendo Switch) does not allow users to sideload their own code on it, it's not possible to comply with the terms of the LGPL while shipping LGPL code on that platform, because the user cannot install their own modified version of the LGPL library.
Isn't that what tivoization is, or do I misunderstand? And if so, I would assume that only restricts (L)GPL v3, whereas LGPL v2 would still be fine.
On 3/29/23 15:33, Esme Povirk wrote:
OK, maybe it's more complicated than I thought. Here's my best guess from what I know:
In the case of Tivoization, the GPL code isn't linked with any proprietary code. The user can still build the program as a whole, but is unable to sign it so that the device will execute it.
In this case, LGPL code is linked with proprietary code: both the game itself and the vendor's libraries. In this situation, section 6 requires a way for the user to relink the rest of the code to their modified version of the library: either source code, object code, or a dynamically linked binary. A game developer could theoretically distribute their game's source code or object code without the assets, but they cannot redistribute the tools and libraries from the platform vendor to the general public.
Oh, interesting, so I guess LGPL 2 effectively also prevents tivoization. Actually, now that you've explained it, I vaguely remember that being discussed last Wineconf (either as part of Bradley Kuhn's talk or a more informal conversation).
participants (4)
-
Dean Greer -
Esme Povirk -
Rémi Bernon -
Zebediah Figura