may be you could send a specific msg to pd (from within patch) specifying the audio API to use ..
looks like pd defaults to OSS in every posible way you cannot even attempt to ./configure --without-oss so i think you should be able to set the API within a patch and then turn the dsp on. anyway it's what you want to be sure that you are using that particular alsa device. On Wed, Jan 27, 2010 at 11:16:58PM +0000, Florian Hollerweger wrote: > Hi Hans, > > Hans-Christoph Steiner wrote: > > I think I got it to work by putting a [delay 1000] between the > > [loadbang] and the [; pd dsp 1( > > Thanks for your help; I have actually just come up with the same > workaround, but I was wondering whether there might be a less hacky > solution (especially since for my application a rapid startup time is > somewhat critical). > > Anyone else? > > best, > flo.H > > > > On Jan 27, 2010, at 5:56 PM, Florian Hollerweger wrote: > > >> For > >> > >> pd -nogui mypatch.pd > >> > >> I get a > >> > >> /dev/dsp (read/write): Device or resource busy > >> [...] > >> audio I/O stuck... closing audio > >> > >> if, and only if, mypatch.pd contains a > >> > >> [loadbang] > >> | > >> [; > >> pd dsp 1< > >> > >> The same patch loads fine if I omit the -nogui flag. The problem can not > >> only be produced by loadbanging the DSP, but also like this: > >> > >> pd -nogui -send "pd dsp 1" mypatch.pd > >> > >> The problem can *not* be solved by specifying further flags such as > >> -alsa > >> -r 44100 > >> -audiodev [...] > >> > >> as suggested at [1], [2] and possibly elsewhere. The only workaround for > >> me so far is to turn on the DSP later using a message from pdsend to > >> [netreceive]. > > _______________________________________________ > 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