sorry for the last mail, which is a few days old. it was hanging in the queue at iem, so i sent it twice.
as far as i know ./configure --enable-rme is about the hammerfall 9562 with winfried's driver (not about the dsp version)
i got pd running with oss emulation and pd -blocksize 2048 but it's still not perfect (high load + latency...)
so my question ist (still): is there a workaround for the non-interleave mode of hdsp. does anybody know a .asounrc config to get pd running with hdsp and native alsa?
ps: i use alsa 0.9 from cvs kernel 2.4.19 and did a little "howto" at http://pd.klingt.org/files/hdsp-howto.html about my expiriences so far.
thanks & regards d13b
using native alsa, pd refuses to start:
just to check :
- are you using alsa 0.9 ?
- have you tried
$ ./configure --enable-alsa --enable-rme --with-x
regards, piem.
Hi all, there are strange things happening with/in the HDSP alsa driver.
Calling pd with something like "pd -r 44100 -alsadev hw:1,0" results in the usual console printout
Sample width set to 4 bytes ALSA: set input channels to 10 ALSA lib pcm_hw.c:292:(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:4358: snd_pcm_sw_params_current: Assertion `pcm->setup' failed.
but also an interesting kernel message
ALSA ../../alsa-kernel/pci/rme9652/hdsp.c:690: cannot change between single- and double-speed mode (capture PID = 2561, playback PID = 2561)
Looking into the driver code (and inserting some debug printouts) shows that there seems to be a bug in the driver: the function hdsp_system_sample_rate can also return 0 (which stands for a "default" sample rate). This case is not handled in the select statement starting at line 650 and causes the debug output and bail out. If i adapt the code and print out the sample rates that pd wants to set i get strange results:
ALSA ../../alsa-kernel/pci/rme9652/hdsp.c:646: set sample rate (current = 0, set = 64000)
Does PD want to set a wrong sample rate? Now the PD console printout is
pd: pcm.c:964: snd_pcm_writei: Assertion `pcm->access == SND_PCM_ACCESS_RW_INTERLEAVED' failed.
which seems much more logical. Is there a way to cope with interleaved streams by having an appropriate .asoundrc?
Hopefully getting nearer to a solution.... (but no time to do further experiments)
greetings, Thomas
hi everybody, sorry for such a newbie question, but large parts of linux are still a mystery to me me... i'd like to start pd either with one single mouse-klick or just with a keyboard-shortcut. i find it annoying to open the konsole-window and then type some stuff... i know i can adjust the .pdrc - file but i like to have different setups for different patches and therefore wrote different shell-scripts. but with clicking on the scripts, i cannot manage to see the konsole-window (only pd). is there a command to get this done? or - getting personally - how do you start pd? marius.
On Sun, 15 Sep 2002, marius schebella wrote:
hi everybody, sorry for such a newbie question, but large parts of linux are still a mystery to me me...
Linux is a different way to think than windows and mac. You should really do everything in the console. It is faster and more powerfull.
i'd like to start pd either with one single mouse-klick or just with a keyboard-shortcut. i find it annoying to open the konsole-window and then type some stuff...
The "trick" is to allways have a console-window open.
i know i can adjust the .pdrc - file but i like to have different setups for different patches and therefore wrote different shell-scripts. but with clicking on the scripts, i cannot manage to see the konsole-window (only pd). is there a command to get this done? or - getting personally - how do you start pd?
You can use "xterm" with the "-e" option. Like this: "xterm -e pd -alsa", which first starts an xterm console which again runs pd with alsa.
|> i'd like to start pd either with one single mouse-klick or just with a |> keyboard-shortcut. i find it annoying to open the konsole-window and then |> type some stuff... | |The "trick" is to allways have a console-window open.
or 20 .. so its never far .. ;)
|> i know i can adjust the .pdrc - file but i like to have |> different setups for different patches and therefore wrote different |> shell-scripts. but with clicking on the scripts, i cannot manage to see the |> konsole-window (only pd). |> is there a command to get this done? or - getting personally - how do you |> start pd? | |You can use "xterm" with the "-e" option. Like this: |"xterm -e pd -alsa", which first starts an xterm console which again |runs pd with alsa.
yeah but the problem with -e might be that if pd quits/crashes/etc, the xterm will disappear as well instantly and with it all maybe valuable debugging information...
hi still, i think xterm -e is (at least for me, alternatively to the usual console-way) a way to go. can i add a variable like windowsstyle %1 at the end of a script to have a patch loaded, lets say open all *.pd-files by default with "mystartscript_for_pd" and open that certain patch?
marius.
Am Sonntag, 15. September 2002 11:14 schrieb _-¯-_:
|> i'd like to start pd either with one single mouse-klick or just with a |> keyboard-shortcut. i find it annoying to open the konsole-window and |> then type some stuff... | |The "trick" is to allways have a console-window open.
or 20 .. so its never far .. ;)
|> i know i can adjust the .pdrc - file but i like to have |> different setups for different patches and therefore wrote different |> shell-scripts. but with clicking on the scripts, i cannot manage to see |> the konsole-window (only pd). |> is there a command to get this done? or - getting personally - how do |> you start pd? | |You can use "xterm" with the "-e" option. Like this: |"xterm -e pd -alsa", which first starts an xterm console which again |runs pd with alsa.
yeah but the problem with -e might be that if pd quits/crashes/etc, the xterm will disappear as well instantly and with it all maybe valuable debugging information...
On Sun, 15 Sep 2002, marius schebella wrote:
hi still, i think xterm -e is (at least for me, alternatively to the usual console-way) a way to go. can i add a variable like windowsstyle %1 at the end of a script to have a patch loaded, lets say open all *.pd-files by default with "mystartscript_for_pd" and open that certain patch?
Yes. For shell-scripts the following should work. $0 is the command. $1, $2, $3, etc. is the arguments. $@ means all arguments.
On Sun, 15 Sep 2002, _-¯-_ wrote:
| |The "trick" is to allways have a console-window open.
or 20 .. so its never far .. ;)
I agree about that. :)
| |You can use "xterm" with the "-e" option. Like this: |"xterm -e pd -alsa", which first starts an xterm console which again |runs pd with alsa.
yeah but the problem with -e might be that if pd quits/crashes/etc, the xterm will disappear as well instantly and with it all maybe valuable debugging information...
It can be solved by starting a shell after pd is finished. I cant think of any way to do that in a single-command line right now, but to make a shellscript that starts pd first and starts a shell right after should work. If he just run the following:
echo "#!/bin/sh" >/bin/pd echo "/usr/local/bin/pd $@" >>/bin/pd echo "bash" >>/bin/pd chmod a+rx /bin/pd
I guess it should work.
_-¯-_ wrote:
yeah but the problem with -e might be that if pd quits/crashes/etc, the xterm will disappear as well instantly and with it all maybe valuable debugging information...
ahm,,, what about :
<snip> #!/bin/sh cd /where/my/patches/reside pd -lib zexy -lib other_crap MAIN.pd
read
</snip>
note the "read"-line,...
mfg.das.f IOhannes
Thomas Grill hat gesagt: // Thomas Grill wrote:
Is there a way to cope with interleaved streams by having an appropriate .asoundrc?
If I understand ALSA's asoundrc and device nameing correctly (which might very well not be the case) then one needs a "plug" or "plughw" type of device to convert between non- and interleaved streams, if the hardware cannot do this on its own.
Unfourtunatly I cannot get PD to open "plug"-type devices at all :( [with a Midiman Audiophile]
One standard plug device is called "default", seen for example with "aplay -L"
If I try to use this device:
$ pd -alsa -alsadev default:0,0 $ pd -alsa -alsadev default
PD's audio is stuck. The same happens, if I define a plug PCM in my
asoundrc:
# asoundrc:
pcm.maudio {
type hw
card 0
}
ctl.maudio {
type hw
card 0
}
pcm.mydsp {
type plug
slave.pcm maudio
}
Now, "pd -alsadev maudio" works, but "pd -alsadev mydsp" doesn't. I can use "mydsp" with aplay without problems "aplay -D mydsp some.wav"
I suspect, that PD simply isn't able to use plug devices. But maybe working on the JACK support is more important.
ciao
Frank Barknecht _ ______footils.org__
hi all!
i CAN start pd with -alsa if my .asoundrc looks like pcm.hdsp_convert { type plug slave { pcm { type hw card 1 } rate 48000 format S32_LE channels 18 } }
and my .pdrc looks like -rt -alsa -alsadev hdsp_convert -r 48000
but the sound i get then is incredible. a osc~ 440 sounds like a c64-datasette played backwards...
as soon as i define -channels in .pdrc , pd will refuse to start with pd: pcm_params.c:1051: _snd_pcm_hw_param_refine: Assertion `0' failed.
regards d13b
Thomas Grill hat gesagt: // Thomas Grill wrote:
Is there a way to cope with interleaved streams by having an appropriate .asoundrc?
If I understand ALSA's asoundrc and device nameing correctly (which might very well not be the case) then one needs a "plug" or "plughw" type of device to convert between non- and interleaved streams, if the hardware cannot do this on its own.
Unfourtunatly I cannot get PD to open "plug"-type devices at all :( [with a Midiman Audiophile]
One standard plug device is called "default", seen for example with "aplay -L"
If I try to use this device:
$ pd -alsa -alsadev default:0,0 $ pd -alsa -alsadev default
PD's audio is stuck. The same happens, if I define a plug PCM in my asoundrc:
# asoundrc: pcm.maudio { type hw card 0 } ctl.maudio { type hw card 0 } pcm.mydsp { type plug slave.pcm maudio }
Now, "pd -alsadev maudio" works, but "pd -alsadev mydsp" doesn't. I can use "mydsp" with aplay without problems "aplay -D mydsp some.wav"
I suspect, that PD simply isn't able to use plug devices. But maybe working on the JACK support is more important.
ciao
hi hdsPDers! tried the jack-patch from ftp://xdv.org/pub/gige/pd/ today, and i'm happy with it. i can even record in ardour diretcly from pd's dac~ (18 channels...) the whole setup is a bit experimental , and i have to do some more tests, but this seems to be a good solution.
regards d13b
-
_-¯-_ -
d -
d13
-
Frank Barknecht -
IOhannes zmoelnig -
Kjetil S. Matheussen -
marius schebella -
Thomas Grill