(I'm posting this mail to the pd list too. In case some of the things I have written is wrong, someone will hopefully correct me. The pd in question is the development branch of V0.36 from sourceforge compiled with jack support running on the new type of hammerfall card.)
On Thu, 13 Feb 2003, Natasha Barrett wrote:
Hello
I tested the machine this morning.
I still hear a lot of clicks. I think this is clearer when reading and writing into and from an 'array' in Pd, rather than when playing sound directly off the disk with something like playsf~
I was running root, used Jack with both -R and -s flags.
Also, Pd often crashes with the following message: "engine has shut down socket; stdout: Brokenpipe thread exiting"
That is not good, but I hope its because you are using a development branch of pd. There is an older version of pd with jack-support that might be more stable.
When I start Pd I get this message: "use of function jack_set_buffer_size_callback() is deprecated"
Thats not a problem.
Any suggestions? Shall I bring the machine back in? Does this suggest the clicks are due to the buffering differences?
If the clicks are related to jack, it writes out a message to the shell. But you must not spesify the -s flag for that to happen.
If the clicks are related to PD not able to supply enough data to jack, you should get a notice in the shell no matter what you do.
If you get clicks but you see no message about it in the shells, the source of the clicks are most probably in your patch.
Natasha
"Kjetil S. Matheussen" wrote:
I have upgraded your machine heavily with packages from planet-ccrma, and installed a low-latency kernel and tuned the harddisk. And the result seems promising.
When running jack and pd as root with realtime priority, I am unable to produce clicks or pops, even when starting and stopping heavy applications as emacs and mozilla. It does not seem necesarry to use the -s flag, but adding it will not hurt.
Hi,
Finally I have been able to get pd running with the Hammerfall and the ALSA drivers. It did cost me more time than I thought, at the end I was randomly trying different combinations of hundreds of calls for setting fragmentsizes, fragment numbers, samplerate and channels, ... and ... one combination worked !
Latency is not too good, I think this is because the driver currently works in non-blocking mode. So be sure to set "-bufsize 256" or bigger. (e.g.512,1024,2048,4096).
The code is in CVS, checkout with
#> cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/pure-data login
#> cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/pure-data co -r devel_0_36
For those who work with the non CVS version, download s_linux.c from http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pure-data/pd/src/?only_with_t...
put it into your pd/src directory and recompile.
I do not know how well it runs on an HDSP (please report).
Guenter
Hi all,
I'm testing it here with my HDSP Multiface, and it seems to work fine as long as I use -blocksize 512 or bigger. Smaller buffers always sound broken. I'm using a 2.4.20 kernel with the low-latency patches and ext3 patches. The latency via analog loopback as reported by pd/doc/7.stuff/tools/latency.pd is 25ms.
It's better than going via jack, because a couple of underruns (caused by eg. dragging 100 objects in a patch) give a 'audio IO stuck' and I have to restart PD to get audio up again.
Dragging lots of objects gives crackles, but operation is stable if I don't mess with the gui, even at very high CPU loads.
96kHz does not work. I guess PD is confused by the different number of channels @ 96kHz. Here the transcript:
: # pd -alsa -verbose -blocksize 1024 -r 96000 -rt : pd/doc/7.stuff/tools/latency.pd : reading startup file: /root/.pdrc : Pd version 0.36-0 : compiled 21:02:57 Feb 19 2003 : device 1: tried /dev/midi READ/WRITE; returned 3 : opened 1 MIDI input device(s) and 1 MIDI output device(s). : audio buffer set to 40 ms : opening sound input... : Using noninterleaved mode : snd_pcm_hw_params_set_channels (input): Invalid argument : ALSA lib pcm_hw.c:297:(snd_pcm_hw_hw_params) SNDRV_PCM_IOCTL_HW_PARAMS : failed: Device or resource busy : snd_pcm_hw_params (input): Device or resource busy : pd: pcm.c:4907: snd_pcm_sw_params_current: Assertion `pcm->setup' : failed. : Aborted
Remember to do a warm-boot if you don't get any output from the multiface...
j#|@
On Fri, 14 Feb 2003, guenter geiger wrote:
Hi,
Finally I have been able to get pd running with the Hammerfall and the ALSA drivers. It did cost me more time than I thought, at the end I was randomly trying different combinations of hundreds of calls for setting fragmentsizes, fragment numbers, samplerate and channels, ... and ... one combination worked !
Latency is not too good, I think this is because the driver currently works in non-blocking mode. So be sure to set "-bufsize 256" or bigger. (e.g.512,1024,2048,4096).
The code is in CVS, checkout with
#> cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/pure-data login
#> cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/pure-data co -r devel_0_36
For those who work with the non CVS version, download s_linux.c from http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pure-data/pd/src/?only_with_t...
put it into your pd/src directory and recompile.
I do not know how well it runs on an HDSP (please report).
Guenter
Johannes,
thanks for the feedback. this is very important for me, because I do not have a HDSP card. I will address the 512 blicksize issue soon, this will improve latency figures (Should improve the behaviour of pd/ALSA in general, at least that is what I hope for).
Will post updates to the list.
Guenter
On Thu, 20 Feb 2003, Johannes Taelman wrote:
Hi all,
I'm testing it here with my HDSP Multiface, and it seems to work fine as long as I use -blocksize 512 or bigger. Smaller buffers always sound broken. I'm using a 2.4.20 kernel with the low-latency patches and ext3 patches. The latency via analog loopback as reported by pd/doc/7.stuff/tools/latency.pd is 25ms.
It's better than going via jack, because a couple of underruns (caused by eg. dragging 100 objects in a patch) give a 'audio IO stuck' and I have to restart PD to get audio up again.
Dragging lots of objects gives crackles, but operation is stable if I don't mess with the gui, even at very high CPU loads.
96kHz does not work. I guess PD is confused by the different number of channels @ 96kHz. Here the transcript:
: # pd -alsa -verbose -blocksize 1024 -r 96000 -rt : pd/doc/7.stuff/tools/latency.pd : reading startup file: /root/.pdrc : Pd version 0.36-0 : compiled 21:02:57 Feb 19 2003 : device 1: tried /dev/midi READ/WRITE; returned 3 : opened 1 MIDI input device(s) and 1 MIDI output device(s). : audio buffer set to 40 ms : opening sound input... : Using noninterleaved mode : snd_pcm_hw_params_set_channels (input): Invalid argument : ALSA lib pcm_hw.c:297:(snd_pcm_hw_hw_params) SNDRV_PCM_IOCTL_HW_PARAMS : failed: Device or resource busy : snd_pcm_hw_params (input): Device or resource busy : pd: pcm.c:4907: snd_pcm_sw_params_current: Assertion `pcm->setup' : failed. : Aborted
Remember to do a warm-boot if you don't get any output from the multiface...
j#|@
On Fri, 14 Feb 2003, guenter geiger wrote:
Hi,
Finally I have been able to get pd running with the Hammerfall and the ALSA drivers. It did cost me more time than I thought, at the end I was randomly trying different combinations of hundreds of calls for setting fragmentsizes, fragment numbers, samplerate and channels, ... and ... one combination worked !
Latency is not too good, I think this is because the driver currently works in non-blocking mode. So be sure to set "-bufsize 256" or bigger. (e.g.512,1024,2048,4096).
The code is in CVS, checkout with
#> cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/pure-data login
#> cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/pure-data co -r devel_0_36
For those who work with the non CVS version, download s_linux.c from http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pure-data/pd/src/?only_with_t...
put it into your pd/src directory and recompile.
I do not know how well it runs on an HDSP (please report).
Guenter
On Fri, 21 Feb 2003, guenter geiger wrote:
Johannes,
thanks for the feedback. this is very important for me, because I do not have a HDSP card. I will address the 512 blicksize issue soon, this will improve latency figures (Should improve the behaviour of pd/ALSA in general, at least that is what I hope for).
Will post updates to the list.
Great. I'm ready to test further updates.
Could you please also adress the 96kHz issue? I really need 96kHz for ultrasound motion capture...
To use PD+ASIO+win2k+HDSP at 96kHz, I have to trick my soundcard by opening the MME driver at 96kHz in another application while starting PD. Otherwise portaudio/asio seems confused by the different number of channels at different samplerates. Sounds like a similar problem is happening in alsa. Also this message appears in dmesg:
ALSA ../../alsa-kernel/pci/rme9652/hdsp.c:698: cannot change between single- and double-speed mode (capture PID = 651, playback PID = 651)
Now on to getting my midiman usb midisport 4x4 to work past its first port...
j#|@
Hmm, and here I am trying to migrate Pd to use portaudio... I wonder if they've already "fixed" this???
cheers Miller
On Fri, Feb 21, 2003 at 12:03:49PM +0100, guenter geiger wrote:
Johannes,
thanks for the feedback. this is very important for me, because I do not have a HDSP card. I will address the 512 blicksize issue soon, this will improve latency figures (Should improve the behaviour of pd/ALSA in general, at least that is what I hope for).
Will post updates to the list.
Guenter
On Thu, 20 Feb 2003, Johannes Taelman wrote:
Hi all,
I'm testing it here with my HDSP Multiface, and it seems to work fine as long as I use -blocksize 512 or bigger. Smaller buffers always sound broken. I'm using a 2.4.20 kernel with the low-latency patches and ext3 patches. The latency via analog loopback as reported by pd/doc/7.stuff/tools/latency.pd is 25ms.
It's better than going via jack, because a couple of underruns (caused by eg. dragging 100 objects in a patch) give a 'audio IO stuck' and I have to restart PD to get audio up again.
Dragging lots of objects gives crackles, but operation is stable if I don't mess with the gui, even at very high CPU loads.
96kHz does not work. I guess PD is confused by the different number of channels @ 96kHz. Here the transcript:
: # pd -alsa -verbose -blocksize 1024 -r 96000 -rt : pd/doc/7.stuff/tools/latency.pd : reading startup file: /root/.pdrc : Pd version 0.36-0 : compiled 21:02:57 Feb 19 2003 : device 1: tried /dev/midi READ/WRITE; returned 3 : opened 1 MIDI input device(s) and 1 MIDI output device(s). : audio buffer set to 40 ms : opening sound input... : Using noninterleaved mode : snd_pcm_hw_params_set_channels (input): Invalid argument : ALSA lib pcm_hw.c:297:(snd_pcm_hw_hw_params) SNDRV_PCM_IOCTL_HW_PARAMS : failed: Device or resource busy : snd_pcm_hw_params (input): Device or resource busy : pd: pcm.c:4907: snd_pcm_sw_params_current: Assertion `pcm->setup' : failed. : Aborted
Remember to do a warm-boot if you don't get any output from the multiface...
j#|@
On Fri, 14 Feb 2003, guenter geiger wrote:
Hi,
Finally I have been able to get pd running with the Hammerfall and the ALSA drivers. It did cost me more time than I thought, at the end I was randomly trying different combinations of hundreds of calls for setting fragmentsizes, fragment numbers, samplerate and channels, ... and ... one combination worked !
Latency is not too good, I think this is because the driver currently works in non-blocking mode. So be sure to set "-bufsize 256" or bigger. (e.g.512,1024,2048,4096).
The code is in CVS, checkout with
#> cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/pure-data login
#> cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/pure-data co -r devel_0_36
For those who work with the non CVS version, download s_linux.c from http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pure-data/pd/src/?only_with_t...
put it into your pd/src directory and recompile.
I do not know how well it runs on an HDSP (please report).
Guenter
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list