Does anyone know why I would get this message with these externals?
Segmentation fault socket receive error: Connection reset by peer (104)
The fluid help patch crashes when dsp is turned on, and the others exit straight away. Shabby~ and shaffy~ used to work here - could it be from changing compiler versions, or forgetting to remove something during pd recompiles/installs etc?
tim
Hallo, t.barrass@pgrad.unimelb.edu.au hat gesagt: // t.barrass@pgrad.unimelb.edu.au wrote:
Does anyone know why I would get this message with these externals?
Segmentation fault socket receive error: Connection reset by peer (104)
The message can have several reasons...
The fluid help patch crashes when dsp is turned on, and the others exit straight away. Shabby~ and shaffy~ used to work here - could it be from changing compiler versions, or forgetting to remove something during pd recompiles/installs etc?
... but I actually suppose that this is compiler related. Did you recompile both flext and the externals with the same compiler? If you updated you libstdc++ in the meantime, you need to recompile them. It's a satanic C++ thing, C-users wouldn't understand...
Oh, and: I did not test them with pd.0.37-test. 0.37 can not be officially supported by me until I can get it to run with ALSA.
ciao
Frank Barknecht _ ______footils.org__
On Mon, 26 May 2003, Frank Barknecht wrote:
Oh, and: I did not test them with pd.0.37-test. 0.37 can not be officially supported by me until I can get it to run with ALSA.
Strangly enough the last time we did latency tests using the OSS layer for ALSA, we discovered that the OSS layer showed by far better performance than the ALSA implementation. (Because it uses blocking I/O, which gives better time resolution) So there should be no reason not to run pd under OSS until we have time to fix the ALSA I/O (which should be supported by portaudio actually)
Guenter
Hallo,
[I'm slowly taking this over to pd-dev...]
guenter geiger hat gesagt: // guenter geiger wrote:
Strangly enough the last time we did latency tests using the OSS layer for ALSA, we discovered that the OSS layer showed by far better performance than the ALSA implementation. (Because it uses blocking I/O, which gives better time resolution) So there should be no reason not to run pd under OSS until we have time to fix the ALSA I/O (which should be supported by portaudio actually)
I couldn't get Pd and OSS-emu work together with my M-Audio Quattro in 4-channel mode. :( That's my personal reason. To use the Quattro this way some .asoundrc magic is needed, and at least I couldn't transfer this to OSS-devices.
Regarding portaudio:
I came a little bit farther along in activating the ALSA interface of Portaudio in Pd. I replaced all portaudio files except the pablio directory with current PA-cvs.
I then had to edit the Makefiles by hand, replace PA_USEAPI_OSS -> PA...ALSA, add "-lasound" to the final linking and remove -Werror. After that Pd compiled and ran, but it couldn't open the ALSA sound devices. The error message is:
ALSA lib pcm_hw.c:1078:(snd_pcm_hw_open) open /dev/snd/pcmC2D0c failed: No such file or directory ALSA lib pcm_hw.c:1078:(snd_pcm_hw_open) open /dev/snd/pcmC2D0p failed: No such file or directory ^- this also happens with the test programs and might be harmless input device 0, output device 0 nchan 2, flags 3, bufs 8, framesperbuf 256 ALSA call at line 381 succeeded ALSA call at line 388 succeeded ALSA format: 10 ALSA call at line 423 succeeded ALSA call at line 426 succeeded Error executing ALSA call, line 429 Error number -9993 occured opening portaudio stream Error message: Illegal combination of I/O devices
I guess, that maybe my main card, the M-Audio Audiophile is creating this error. It is a stereo card, but the chipset (ICE1712) has 10 in- and 12 out-channels. The line numbers above refer to pa_linux_alsa.c where it fails at line 429, which says:
/* ... set the number of channels */
ENSURE( snd_pcm_hw_params_set_channels( stream, hw_params, channels ) );
The three alsa-enabled pa_test programs do work, for example patest_sine, even when compiled with Pd's pabilo changes.
Maybe this rings a bell with someone?
ciao
Frank Barknecht _ ______footils.org__
anyone test oggcast~ with the new icecast server.
im using oggcast~ taken today from cvs with a gentoo linux distro and ALSA.
funny thought that I am getting these errors when connecting with oggcast~:
first, when I try to connect to the server, the server says im not connected, but oggcast~ says I am.
then, when I turn the dsp on in PD i get:
ALSA lib pcm_hw.c:407:(snd_pcm_hw_status) SNDRV_PCM_IOCTL_STATUS failed: Bad file descriptor audio I/O stuck... closing audio
this seems really wierd to me. can't see how oggcast~ would fuck up the soundcard (unless maybe oggcast is trying to ioctls internally ???).
-august.
august schrieb:
anyone test oggcast~ with the new icecast server.
im using oggcast~ taken today from cvs with a gentoo linux distro and ALSA.
Hi August,
since I don't upload my stuff into CVS myselfe I don't know which version you downloaded. The latest version is 0.2h (from my website) whis I tested with Icecast2 on Win32 (using pd0.36, in case that should matter).
first, when I try to connect to the server, the server says im not connected, but oggcast~ says I am.
Hhhm, strange, I'll try here again and let you know...
then, when I turn the dsp on in PD i get:
You should always turn on dsp _before_ connecting to the server. The server expects the source client to send the login string imediately followed by audio data. But this does not explain your "Bad file descriptor".
Olad
Hi August,
since I don't upload my stuff into CVS myselfe I don't know which version you downloaded. The latest version is 0.2h (from my website) whis I tested with Icecast2 on Win32 (using pd0.36, in case that should matter).
ok, just downloaded the latest 0.2h from your site, and I get the same errors.
i also noticed that to compile I needed to add #include <stdlib.h>
and to compile i had to take away -Wall -Wshadow
otherwise, I get this:
cc1: warnings being treated as errors
oggcast~.c: In function oggcast_child_connect': oggcast~.c:551: warning: int format, t_int arg (arg 3) oggcast~.c:615: warning: int format, t_int arg (arg 3) oggcast~.c: In functionoggcast_child_main':
oggcast~.c:790: warning: int format, t_int arg (arg 3)
oggcast~.c:801: warning: declaration of `fifotail' shadows a previous
local
oggcast~.c:700: warning: shadowed declaration is here
oggcast~.c:836: warning: int format, t_int arg (arg 3)
oggcast~.c:836: warning: int format, t_int arg (arg 4)
can you make something of this?
then, when I turn the dsp on in PD i get:
You should always turn on dsp _before_ connecting to the server. The server expects the source client to send the login string imediately followed by audio data. But this does not explain your "Bad file descriptor".
ok, I dumped the error messages to file so that I could sort through them, and this is what I get before all that ALSA junk:
oggcast~: logging in to IceCast2 server... oggcast~: logged in to http://aura.siba.fi:8000/puredata.ogg oggcast~: ogg/vorbis encoder initialised Pd: signal 13 ALSA lib pcm_hw.c:407:(snd_pcm_hw_status) SNDRV_PCM_IOCTL_STATUS failed: Bad file descriptor ... ...
so, it looks like pd is crashing, and thats where the bad file descriptor is coming from.
And, I can see that the Icecast2 server is working by connecting and streaming with IceS.
- august.
-
august -
Frank Barknecht -
guenter geiger -
Olaf Matthes -
t.barrass＠pgrad.unimelb.edu.au