Hi list,
I apologize for bringing up an old issue, but although I have found others with the same problem [1,2], I cannot seem to find a solution in the list archive:
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].
Any ideas?
best, flo.H
References: [1] http://lists.puredata.info/pipermail/pd-list/2004-04/019305.html [2] http://lists.puredata.info/pipermail/pd-list/2006-07/039698.html
I think I got it to work by putting a [delay 1000] between the
[loadbang] and the [; pd dsp 1(
.hc
On Jan 27, 2010, at 5:56 PM, Florian Hollerweger wrote:
Hi list,
I apologize for bringing up an old issue, but although I have found others with the same problem [1,2], I cannot seem to find a solution
in the list archive: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].Any ideas?
best, flo.H
References: [1] http://lists.puredata.info/pipermail/pd-list/2004-04/019305.html [2] http://lists.puredata.info/pipermail/pd-list/2006-07/039698.html
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
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.pdI get a
/dev/dsp (read/write): Device or resource busy [...] audio I/O stuck... closing audioif, 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.pdThe 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].
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.pdI get a
/dev/dsp (read/write): Device or resource busy [...] audio I/O stuck... closing audioif, 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.pdThe 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
-
errordeveloper＠gmail.com -
Florian Hollerweger -
Hans-Christoph Steiner