Also, this has obviously been fixed in later revisions of the pd source, but as m_fifo.c seems to no longer be in the source I am unsure of how to proceed.
On 11/14/06, Luke Iannini (pd) <[EMAIL PROTECTED]> wrote:
I'm trying to get DD to compile on OS X Intel (as usual : ) ) and am getting the following: gcc -g -Wall -fnested-functions -fasm-blocks -DPD -DDL_OPEN -DNEWHASH -DLOCKFREE -DDESIRE -DPABLIO -DPA_LOG_API_CALLS -DUNISTD -DPA_USE_COREAUDIO -DMACOSX -DUSEAPI_JACK -DUSEAPI_PORTAUDIO -DPA19 -DDEBUG -DHAVE_ALLOCA -DPD_INTERNAL -I/Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/Tcl.framework/Headers -I/usr/include/tcl8.4 -Isrc -Iportmidi_osx -Iportmidi_osx/pm_common -Iportmidi_osx/porttime -Iportmidi_osx/pm_mac -Iportaudio/include -Iportaudio/src/common -c -o src/m_fifo.o src/m_fifo.c /var/tmp//cc9fyyxN.s:26:junk `f' after expression /var/tmp//cc9fyyxN.s:27:Spurious digit 1. /var/tmp//cc9fyyxN.s:27:Rest of line ignored. 1st junk character valued 48 (0). /var/tmp//cc9fyyxN.s:31:junk `f' after expression /var/tmp//cc9fyyxN.s:33:junk `b' after expression /var/tmp//cc9fyyxN.s:34:Spurious digit 2. /var/tmp//cc9fyyxN.s:34:Rest of line ignored. 1st junk character valued 48 (0). scons: *** [src/m_fifo.o] Error 1 Looks like there is a lot of processor specific assembler in there - is this another case of assuming PPC on the OS X platform? On 11/14/06, Tim Blechmann <[EMAIL PROTECTED]> wrote: > > >> ...one last question: are we now using s_audio_pa.c or > > >> s_audio_portaudio.c? > > >> > > > Tim Blechmann has coded the s_audio_portaudio.c interface for the > > > vibrez project, that's why i am using it. I run it under OSX and > > > Windows and due to callback scheduling it has far lower latency > > > than Miller's implementation. > > i just want to mention, it also beats wini's alsa implementation, that > has scheduling problems, when running below around 8 ms > > > ...hmm, I guess someone needs to make a patch for inclusion in main > > pd: thanks for the clarification! > > it's not that easy ... from my understanding of miller's pd, he > considers pd as synchronous application. to achieve these latencies, i > had to rewrite the scheduler, to work asynchronously, which is not the > 'pd way'. > thus i think, it's not going to be included into main pd and submitting > a patch would be a waste of time. > > cheers ... tim > > -- > [EMAIL PROTECTED] ICQ: 96771783 > http://www.mokabar.tk > > The aim of education is the knowledge, not of facts, but of values > William S. Burroughs > > > _______________________________________________ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > > > >
_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list