winemp3.acm on the mac

[Aric Stewart]

Hello all,

  So I have been hacking on winemp3.acm on the mac to make use of 
CoreAudio for mp3 decoding and I have just gotten it working. So now I 
am faced with a questions.

   Do I setup winemp3.acm with #ifdefs to pick between the libmpg123 or 
CoreAudio paths, leaving us with 1 winemp3.acm that can do both.

   Or do I create a new winecoreaudio.acm (or such) that just contains 
the CoreAudio path.

   I see pluses and minuses to each and am unsure which would be better. 
  I think personally I would prefer the first option however that 
potentially really complicates the build system and then what happens if 
someone has a mac with the libmpg123 headers.

   Adding a new acm would not be too problematic if people feel that 
would be better. The advantage there is it would be possible to expand 
that acm to handle all the types the CoreAudio handles and not just mp3.

   thanks!
-aric

[Ben Klein]

On 12 March 2010 13:46, Aric Stewart <aric(a)codeweavers.com> wrote:
> Hello all,
>
>  So I have been hacking on winemp3.acm on the mac to make use of CoreAudio
> for mp3 decoding and I have just gotten it working. So now I am faced with a
> questions.
>
>  Do I setup winemp3.acm with #ifdefs to pick between the libmpg123 or
> CoreAudio paths, leaving us with 1 winemp3.acm that can do both.
>
>  Or do I create a new winecoreaudio.acm (or such) that just contains the
> CoreAudio path.

Is there other Mac-specific code in Wine? I think there is, so how is
it handled?

What defines, if any, does the configure script produce when coreaudio
is detected or enabled? I'd expect you would use those.

Of course, I'm not actually answering questions; I'll leave the
ultimate architectural decision to someone more experienced :D

[Charles Davis]

On 3/11/10 7:56 PM, Ben Klein wrote:
> Is there other Mac-specific code in Wine?
> Yes there is.
> how is
> it handled?
> With #ifdefs. Though it's not incompatible with defining our own ACM
> filter specifically for CoreAudio. In fact, all the modules in Wine are
> always built; they just get stubbed if the necessary functionality isn't
> present. For example, winealsa.drv always gets built, even on non-Linux
> systems or Linux systems without ALSA libs. (I know because I have a Mac
> myself.) It just doesn't do anything without ALSA.
> What defines, if any, does the configure script produce when coreaudio
> is detected or enabled? I'd expect you would use those.
> HAVE_COREAUDIO_COREAUDIO_H
> Of course, I'm not actually answering questions; I'll leave the
> ultimate architectural decision to someone more experienced :D
> And so shall I.

Chip

[Marcus Meissner]

On Thu, Mar 11, 2010 at 08:46:27PM -0600, Aric Stewart wrote:
> Hello all,
>
> So I have been hacking on winemp3.acm on the mac to make use of
> CoreAudio for mp3 decoding and I have just gotten it working. So now
> I am faced with a questions.
>
> Do I setup winemp3.acm with #ifdefs to pick between the libmpg123
> or CoreAudio paths, leaving us with 1 winemp3.acm that can do both.
>
> Or do I create a new winecoreaudio.acm (or such) that just
> contains the CoreAudio path.
>
> I see pluses and minuses to each and am unsure which would be
> better.  I think personally I would prefer the first option however
> that potentially really complicates the build system and then what
> happens if someone has a mac with the libmpg123 headers.
>
> Adding a new acm would not be too problematic if people feel that
> would be better. The advantage there is it would be possible to
> expand that acm to handle all the types the CoreAudio handles and
> not just mp3.

Well, perhaps handle it in the same directory, but with different sourcefiles,
selected depending on framework?

Or can we build winemp3.acm from two different directories?

#ifdef is ugly.

Ciao, Marcus