Emmanuel Maillard <mahanuu(a)opendarwin.org> 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. -- Alexandre Julliard julliard(a)winehq.org
Emmanuel Maillard <mahanuu(a)opendarwin.org> 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 julliard(a)winehq.org
Emmanuel Maillard <mahanuu(a)opendarwin.org> 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. -- Alexandre Julliard julliard(a)winehq.org
Le 25 mai 06 à 20:27, Alexandre Julliard a écrit :
Emmanuel Maillard <mahanuu(a)opendarwin.org> 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 julliard(a)winehq.org
------------------------------------------------------- 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 Darwine-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/darwine-devel
Emmanuel Maillard <mahanuu(a)opendarwin.org> 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 julliard(a)winehq.org
>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 <julliard(a)winehq.org> wrote: > Emmanuel Maillard <mahanuu(a)opendarwin.org> 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 > julliard(a)winehq.org > > > ------------------------------------------------------- > 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 > Darwine-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/darwine-devel > -- David Bialac dbialac(a)yahoo.com
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 <mahanuu(a)opendarwin.org> 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 julliard(a)winehq.org
Alexandre Julliard wrote:
Emmanuel Maillard <mahanuu(a)opendarwin.org> 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
participants (4)
-
Alexandre Julliard -
David Bialac -
Emmanuel Maillard -
Jim White