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) lukexipd@gmail.com 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:junkf' 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 1Looks 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 tim@klingt.org 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
-- tim@klingt.org 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