A student in my class is having recurrent problems with pd-0.39-2 on
Windows - a message that says
audio I/O stuck ... closing audio
When he closes Pd and restarts, he gets a dialogue that says "pd.exe
has generated errors and will be closed by Windows. You will need to
restart the program. An error log is being created." This is about
all he can get Pd to do.
As far as I know, his Audio Preferences are set correctly.
Suggestions?
Tia,
Mp
On Thu Feb 23, 2006 at 09:14:45PM -0500, Mark Polishook wrote:
A student in my class is having recurrent problems with pd-0.39-2 on
Windows - a message that saysaudio I/O stuck ... closing audio
When he closes Pd and restarts, he gets a dialogue that says "pd.exe
has generated errors and will be closed by Windows.
this could be a pd compiled with -march=i686 and running on a non-SSE cpu.
You will need to
restart the program. An error log is being created." This is about
all he can get Pd to do.As far as I know, his Audio Preferences are set correctly.
if youer using DS/MME try ASIO, and vice versa, and try specifying a samplerate, and be sure the devices are what you expect (run pd with -listdev first to check)
Suggestions?
Tia,
Mp
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Feb 23, 2006, at 11:26 PM, cdr wrote:
On Thu Feb 23, 2006 at 09:14:45PM -0500, Mark Polishook wrote:
A student in my class is having recurrent problems with pd-0.39-2 on Windows - a message that says
audio I/O stuck ... closing audio
When he closes Pd and restarts, he gets a dialogue that says "pd.exe has generated errors and will be closed by Windows.
this could be a pd compiled with -march=i686 and running on a non- SSE cpu.
Pd-0.38.4-extended was compiled with these flags:
-mcpu=i586 -mtune=pentium3 -O3 -funroll-loops -fomit-frame-pointer
That should work with AMD CPUs, right?
.hc
You will need to restart the program. An error log is being created." This is about all he can get Pd to do.
As far as I know, his Audio Preferences are set correctly.
if youer using DS/MME try ASIO, and vice versa, and try specifying
a samplerate, and be sure the devices are what you expect (run pd
with -listdev first to check)Suggestions?
Tia,
Mp
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
There is no way to peace, peace is the way.
-A.J. Muste
On Sunday 26 Feb 2006 00:32, Hans-Christoph Steiner wrote:
Pd-0.38.4-extended was compiled with these flags:
-mcpu=i586 -mtune=pentium3 -O3 -funroll-loops -fomit-frame-pointer
That should work with AMD CPUs, right?
.hc
Yes. It will work with Intel > Pentium 1, AMD > K6, and all (most) the obscure processors from people like VIA.
Additionally, -march=i686 _will_ work on non-SSE cpus, such as the Pentium II, Pentium Pro and early Athlons.
(You _can_ actually run -march=pentium3 on i686s unless you've put handwritten SSE assembler code in or are using a new (>= 4) gcc. Bad practice though.)
robert
-mcpu=i586 -mtune=pentium3 -O3 -funroll-loops -fomit-frame-pointer
That should work with AMD CPUs, right?
(You _can_ actually run -march=pentium3 on i686s unless you've put handwritten SSE assembler code in or are using a new (>= 4) gcc. Bad practice though.)
on win32 with MinGW i've had pd crash with 'bad instruction' errors by compiling with -march=athlon or i686, running on a Celeron II 500 (Coppermine). it is praobly either a bug in the audio interface code, or the aggressive optimization flags from Hans that caused the bug that started this thead..
-march=i586 -O2
is probably a good compromise. ive heard of -O3 causing problems, and -march implies -mtune and other stuff so its unnecessary to specify
best, c
On Sunday 26 Feb 2006 03:02, cdr wrote:
on win32 with MinGW i've had pd crash with 'bad instruction' errors by compiling with -march=athlon or i686, running on a Celeron II 500 (Coppermine). it is praobly either a bug in the audio interface code, or the aggressive optimization flags from Hans that caused the bug that started this thead..
Indeed, optimisation is never flawless. Although I don't see why under any circumstances gcc would spit out instructions with -march=i686 that at Celeron II can't handle.
-march implies -mtune and other stuff so its unnecessary to specify
-march=i586 implies -mtune=i586, but in reality most people will be running processors that are more similar to the pentium3, so 'tuning' the code to something the pentium3 will pipeline better and will work better with its cache arrangement will give most people a slight performance boost while allowing i586 users to still run it. Which is why the original flags are probably a good compromise. Though I'm really not sure about O3.
This is offtopic and unproductive, so I'll quieten down.
robert
ok, so i'm not totally sure what i'm reading here but sounds like a
good option to try is extended at
http://at.or.at/hans/pd/installers-0.38.4-extendedRC8.html
(thanks .hc)
thanks very much for all discussion - hopefully the students will
solve these startup issues ....
On Feb 25, 2006, at 10:02 PM, cdr wrote:
-mcpu=i586 -mtune=pentium3 -O3 -funroll-loops -fomit-frame-pointer
That should work with AMD CPUs, right?
(You _can_ actually run -march=pentium3 on i686s unless you've put
handwritten SSE assembler code in or are using a new (>= 4) gcc. Bad practice
though.)on win32 with MinGW i've had pd crash with 'bad instruction' errors
by compiling with -march=athlon or i686, running on a Celeron II
500 (Coppermine). it is praobly either a bug in the audio interface
code, or the aggressive optimization flags from Hans that caused
the bug that started this thead..-march=i586 -O2
is probably a good compromise. ive heard of -O3 causing problems,
and -march implies -mtune and other stuff so its unnecessary to
specifybest, c
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
On Feb 25, 2006, at 10:02 PM, cdr wrote:
-mcpu=i586 -mtune=pentium3 -O3 -funroll-loops -fomit-frame-pointer
That should work with AMD CPUs, right?
(You _can_ actually run -march=pentium3 on i686s unless you've put
handwritten SSE assembler code in or are using a new (>= 4) gcc. Bad practice
though.)on win32 with MinGW i've had pd crash with 'bad instruction' errors
by compiling with -march=athlon or i686, running on a Celeron II
500 (Coppermine). it is praobly either a bug in the audio interface
code, or the aggressive optimization flags from Hans that caused
the bug that started this thead..-march=i586 -O2
is probably a good compromise. ive heard of -O3 causing problems,
and -march implies -mtune and other stuff so its unnecessary to
specifybest, c
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
On 2/25/06, Hans-Christoph Steiner hans@eds.org wrote:
Pd-0.38.4-extended was compiled with these flags:
-mcpu=i586 -mtune=pentium3 -O3 -funroll-loops -fomit-frame-pointer
That should work with AMD CPUs, right?
The Pentium3 was the first CPU to have SSE so that flag quite possibly allows the compiler to issue SSE instructions. The original AMD Athlon (and all AMD chips before it) do not support SSE.
-
cdr -
chris clepper -
Hans-Christoph Steiner -
Mark Polishook -
Robert Scott