Re: Mac OS X Audio driver

[Alexandre Julliard]

Emmanuel Maillard  writes:
> Authors:
>    Ken Thomases <ken at codeweavers dot com>
>    Emmanuel Maillard <mahanuu at opendarwin dot org>
>
> Changelog:
>    Initial Audio Driver for Mac OS X.

Could you please replace the fprintfs by the proper Wine debug macros?

Also it would be nice if you could send only your own code; I can then
merge Ken's patches on top of it, this way we get a proper record of
the development in the git history.

Mac OS X Audio driver

[Emmanuel Maillard]

> Emmanuel Maillard  writes:
> > Authors:
> >    Ken Thomases <ken at codeweavers dot com>
> >    Emmanuel Maillard <mahanuu at opendarwin dot org>
> >
> > Changelog:
> >    Initial Audio Driver for Mac OS X.
>
> Could you please replace the fprintfs by the proper Wine debug macros?

Sadly no, i can't, Wine debug channels relays on NtCurrentTeb which  
can't be call in AudioUnit IO thread, make it crash or worse.
But I can remove them all.
> Also it would be nice if you could send only your own code; I can then
> merge Ken's patches on top of it, this way we get a proper record of
> the development in the git history.

OK, i will split this and resend the patch.

Emmanuel
> -- 
> Alexandre Julliard
> [e-mail]

Mac OS X Audio driver

[Alexandre Julliard]

Emmanuel Maillard  writes:
> Sadly no, i can't, Wine debug channels relays on NtCurrentTeb which
> can't be call in AudioUnit IO thread, make it crash or worse.
> But I can remove them all.

Is the audio library really calling our code in a thread that we
haven't created ourselves?  That can't work, you need to find another
way to do that.

[Darwine] Re: Mac OS X Audio driver

[Emmanuel Maillard]

Le 25 mai 06 à 20:27, Alexandre Julliard a écrit :
> Emmanuel Maillard  writes:
> > Sadly no, i can't, Wine debug channels relays on NtCurrentTeb which
> > can't be call in AudioUnit IO thread, make it crash or worse.
> > But I can remove them all.
>
> Is the audio library really calling our code in a thread that we
> haven't created ourselves?  That can't work, you need to find another
> way to do that.

All callback used by CoreAudio/AudioUnit are call from a thread  
created by CoreAudio.
Its why i can't use debug channels, critical section and call  
DriverCallback directly ...

Emmanuel
> -- 
> Alexandre Julliard
> [e-mail]
>
> All the advantages of Linux Managed Hosting--Without the Cost and  
> Risk!
> Fully trained technicians. The highest number of Red Hat  
> certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> Darwine-devel mailing list
> [e-mail]
> https://lists.sourceforge.net/lists/listinfo/darwine-devel

[Darwine] Re: Mac OS X Audio driver

[Alexandre Julliard]

Emmanuel Maillard  writes:
> All callback used by CoreAudio/AudioUnit are call from a thread
> created by CoreAudio.
> Its why i can't use debug channels, critical section and call
> DriverCallback directly ...

Yes, you can't do much without a valid thread. That's really a broken
API if you ask me... Anyway, please remove the #ifdefs, and add
comments to the functions that run in a foreign thread to ensure that
no one tries to call Windows APIs from there.

[Darwine] Re: Mac OS X Audio driver

[David Bialac]

> From trying to build this I also found that

1) @COREAUDIO@ isn't defined to '-framework CoreAudio'
anywhere in the build system.
2) The driver doesn't appear in the list of audio
drivers in winecfg

Right now when trying to play audio in winamp, it
crashes, though getting #2 cleaned up may fix this. 
Or perhaps there is more I need to do to get this to
work?

Dave

--- Alexandre Julliard  wrote:
> Emmanuel Maillard  writes:
> > All callback used by CoreAudio/AudioUnit are call
>
> from a thread
> > created by CoreAudio.
> > Its why i can't use debug channels, critical
>
> section and call
> > DriverCallback directly ...
>
> Yes, you can't do much without a valid thread.
> That's really a broken
> API if you ask me... Anyway, please remove the
> #ifdefs, and add
> comments to the functions that run in a foreign
> thread to ensure that
> no one tries to call Windows APIs from there.
>
> -- 
> Alexandre Julliard
> [e-mail]

-------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without
> the Cost and Risk!
> Fully trained technicians. The highest number of Red
> Hat certifications in
> the hosting industry. Fanatical Support. Click to
> learn more

http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&da...
> Darwine-devel mailing list
> [e-mail]

https://lists.sourceforge.net/lists/listinfo/darwine-devel
>

--
David Bialac
[e-mail]

[Darwine] Re: Mac OS X Audio driver

[Emmanuel Maillard]

Here it come, I remove Ken's patches, remove ifdefs and add some  
comments.

Changelog :
    Initial Audio Driver for Mac OS X

Emmanuel

Le 25 mai 06 à 20:59, Alexandre Julliard a écrit :
> Emmanuel Maillard  writes:
> > All callback used by CoreAudio/AudioUnit are call from a thread
> > created by CoreAudio.
> > Its why i can't use debug channels, critical section and call
> > DriverCallback directly ...
>
> Yes, you can't do much without a valid thread. That's really a broken
> API if you ask me... Anyway, please remove the #ifdefs, and add
> comments to the functions that run in a foreign thread to ensure that
> no one tries to call Windows APIs from there.
>
> -- 
> Alexandre Julliard
> [e-mail]

[Darwine] Re: Mac OS X Audio driver

[Jim White]

Alexandre Julliard wrote:
> Emmanuel Maillard  writes:
> > All callback used by CoreAudio/AudioUnit are call from a thread
> > created by CoreAudio.
> > Its why i can't use debug channels, critical section and call
> > DriverCallback directly ...
>
> Yes, you can't do much without a valid thread. That's really a broken
> API if you ask me... Anyway, please remove the #ifdefs, and add
> comments to the functions that run in a foreign thread to ensure that
> no one tries to call Windows APIs from there.

Well, given the demands of real-time programming, such a design is to be
expected.  It's called an interrupt.

If you want to run code on your own thread, create it and block on a
semaphore.  The interrupt sets the semaphore and returns.

Jim