Hello list,
i'm sorry to pop-up again with this eternal topic but i really can't find relevant information about running an hdsp with pd, as everyone is quoting quite outdated documentations, weird how-to's or magical tricks/tips.
My questions are quite simple:
- what is the best interface to use an hdsp with ? oss, alsa, jack ?
(when you just need to run pd and don't need to forward the audio elsewhere)
- what is the typical nice setting for pd with an hdsp
(blocksize/latency) ? what latency do you usually have ?
- is there any objective/obvious reasons to not use a 2.6.x kernel ?
- as modern computers/devices handles irqs in a more smart way now,
would it make a "real" difference to have the hdsp set in a higher IRQ number?
thank you !
++ aym3ric.
aym3ric wrote:
My questions are quite simple:
- what is the best interface to use an hdsp with ? oss, alsa, jack ?
(when you just need to run pd and don't need to forward the audio elsewhere)
if you want multichannel output (and you most probably want it as you have spent your money on it), you will *have* to use alsa/jack.
why?
- there are no OSS drivers for the hdsp (there are drivers for the
normal "old" (and superior, in my opinion) hammerfall, but none forthe hdsp)
- so there are only ALSA-drivers; however pd's alsa support is bad as it
cannot do multichannel. so you cannot "just" use alsa
- pd's jack support is better than it's alsa support (although far from
perfect); at least it can do multichannel.
so your setup should be something like pd->jack->alsa->hdsp
(yesterday this gave me about 13ms latency which is quite ok)
i am running 2.6-kernels and i don't think that there are any reasons not to use it.
mfg.a.sdr IOhannes
thx for the quick reply iohannes,
so your setup should be something like pd->jack->alsa->hdsp
(yesterday this gave me about 13ms latency which is quite ok)
ok, it's actually the way it's running but i can't get this latency though on my laptop (P4 2Ghz) i can run jack @96khz with a setting of 256 frames with no xrun, and that should give me a latency of 5.33 ms. Now if start pd -jack, some xrun start to occur and audio is periodically choppy.(note: if pd is running in -rt, audio seems to be stable but i guess i have to make some intense tests before assuming it's a correct setup).
If i really want to have it the "safe" way i must use a framesize of 1024... :(
so i'm just curious about this, is there things to improve for the "safe" method or is it just a normal behaviour, is it ok to run pd in -rt as it seems to enable lower audio latency with no click'n'pops ?
hello
I have a similar setup and finally it works
My questions are quite simple:
- what is the best interface to use an hdsp with ? oss, alsa, jack ?
(when you just need to run pd and don't need to forward the audio elsewhere)
on my system, Pd works only with Jack
I first have to run "hdsploader" manually (and to get sound I have to run "hdspmixer")
Then, I start jack with the Qjackctl graphic interface
After this, the working command line for Pd is "pd -jack -rt" (the "-rt" flag is here to set Pd to high priority) ; you must be root to do this ("su" in a terminal)
If I don't use the "-rt" flag, I get lots of A/D/A sync errors (in Pd) and crackles when I interact with the GUIs
- what is the typical nice setting for pd with an hdsp
(blocksize/latency) ? what latency do you usually have ?
I use 64 or 128 samples, with 2 periods (I can't change this latter one actually) Latency is 2.9 ms (64 smp) or 5.38 ms (128 smp)
- is there any objective/obvious reasons to not use a 2.6.x kernel ?
I installed all from the PlanetCCRMA website, and there it's a special 2.4 kernel with optimization for realtime audio / video
- as modern computers/devices handles irqs in a more smart way now,
would it make a "real" difference to have the hdsp set in a higher IRQ number?
I don't know
I hope it will help
J
After this, the working command line for Pd is "pd -jack -rt" (the "-rt" flag is here to set Pd to high priority) ; you must be root to do this ("su" in a terminal)
If I don't use the "-rt" flag, I get lots of A/D/A sync errors (in Pd) and crackles when I interact with the GUIs
ok, indeed the -rt flag helps a lot i was not sure if it was "nice" to use it though (as said in my previous post)
I hope it will help
sure, thank you :)
++ aym3ric.
julien.breval@tremplin-utc.net wrote:
hello
- what is the typical nice setting for pd with an hdsp
(blocksize/latency) ? what latency do you usually have ?
I use 64 or 128 samples, with 2 periods (I can't change this latter one actually) Latency is 2.9 ms (64 smp) or 5.38 ms (128 smp)
now i know why you all get so damned good latencies. i guess the numbers are plain wrong when you refer to pd.
when you set the samples/period-value to something like 64 you will *not* get a latency of 64 samples. the actual latency in this case (as i have measured(!) it) is 323 samples (which is approx 7.32ms @ 44.1kHz). with a periodsize of 128 samples you will get 579 samples latency and with periodsize of 256 samples you will get 835 samples latency.
and even worse, 323samples are far from usable (on my 3.2GHz-A7) as i get crackles all the time.
mfg.a.sdr IOhannes
IOhannes m zmoelnig wrote:
julien.breval@tremplin-utc.net wrote:
I use 64 or 128 samples, with 2 periods (I can't change this latter one actually) Latency is 2.9 ms (64 smp) or 5.38 ms (128 smp)
when you set the samples/period-value to something like 64 you will *not* get a latency of 64 samples.
of course i was assuming non-sense here too, as you would expect 2*64=128 samples latency in such a case. still the real values are far worse.
mfg.as.dr IOhannes
IOhannes m zmoelnig wrote:
julien.breval@tremplin-utc.net wrote:
I use 64 or 128 samples, with 2 periods (I can't change this latter one actually) Latency is 2.9 ms (64 smp) or 5.38 ms (128 smp)
when you set the samples/period-value to something like 64 you will *not* get a latency of 64 samples.
of course i was assuming non-sense here too, as you would expect 2*64=128 samples latency in such a case. still the real values are far worse.
well, of course 64 samples is only the HARWARE latency (and it corresponds to 1.5 ms @ 44100 Hz) ; "2 periods" regards software processing only (correct me if I'm wrong)
and here, "2.9 ms (64 smp)" meant : "when I use a buffer size of 64 samples on the HDSP, the global latency told by Qjackctl is 2.9 ms"
sorry for the confusion
Zitiere julien.breval@tremplin-utc.net:
well, of course 64 samples is only the HARWARE latency (and it corresponds to 1.5 ms @ 44100 Hz) ; "2 periods" regards software processing only (correct me if I'm wrong)
and here, "2.9 ms (64 smp)" meant : "when I use a buffer size of 64 samples on the HDSP, the global latency told by Qjackctl is 2.9 ms"
actually that is what i was talking about: when qjackctl tells me that i have a latency of 2.9ms, most users (i assume) tend to say: "oh cool, so i get a latency of 2.9ms!!"
i just wanted to make clear, that the numbers in qjackctl are only part of the truth.
unfortunately i haven't yet been able to test the latency of a system without pd (just wiring the inputs of the hdsp to the outputs via jack)
anyhow, the patch i use for latency-measuring can be downloaded from our cvs via cvs -d:pserver:anonymous@cvs.iem.at:/cvsroot/latency login cvs -d:pserver:anonymous@cvs.iem.at:/cvsroot/latency co pd
(compiled versions of zexy and iemlib1 are included in the cvs)
sorry for the confusion
me too.
mfg.a.sdr IOhannes
Selon zmoelnig@iem.at:
actually that is what i was talking about: when qjackctl tells me that i have a latency of 2.9ms, most users (i assume) tend to say: "oh cool, so i get a latency of 2.9ms!!"
i just wanted to make clear, that the numbers in qjackctl are only part of the truth.
Isn't it the the actual latency when no audio program is running ?
unfortunately i haven't yet been able to test the latency of a system without pd (just wiring the inputs of the hdsp to the outputs via jack)
Actually, I thought the total latency depended on the audio program you use ; qjackctl tells the lower limit, but when you run an audio program latency increases more or less, depending on the program Am I completely wrong ?
On Thursday 22 April 2004 10:21, julien.breval@tremplin-utc.net wrote:
Actually, I thought the total latency depended on the audio program you use ; qjackctl tells the lower limit, but when you run an audio program latency increases more or less, depending on the program Am I completely wrong ?
With jack, yes. Although there are programs that communicate with jack through buffers, so they will have a different latency depending on their internal buffers. But that will affect only that particular program.
Qjackctl may give only the one way latency, that is proportional to the output buffer size. I am not sure, it may also give total latency.
In the help files of pd there is a latency test patch. (I think it is in the extra dirctory somewhere) You have to connect you output to your input of your soundcard and it will give a rough estimate of the latency.
Gerard
With jack, yes. Although there are programs that communicate with jack through buffers, so they will have a different latency depending on their internal buffers. But that will affect only that particular program.
then, does it make sense to also tweak the pd latency/blocksize when using jack, or is pd just running as "slave" ?
++ aym3ric.
well, of course 64 samples is only the HARWARE latency (and it corresponds to 1.5 ms @ 44100 Hz) ; "2 periods" regards software processing only (correct me if I'm wrong)
and here, "2.9 ms (64 smp)" meant : "when I use a buffer size of 64 samples on the HDSP, the global latency told by Qjackctl is 2.9 ms"
actually that is what i was talking about: when qjackctl tells me that i have a latency of 2.9ms, most users (i assume) tend to say: "oh cool, so i get a latency of 2.9ms!!"
*cough* :) well.... unfortunately, without any extra explanation and having as feedback this only piece of information, it's quite easy to suppose these values are the right ones.
Moreover, when you are playing around the settings until you get rid of any clicks/pops/drops, you also tend to think that the final latency you have is your actual "real" latency.
anyhow, the patch i use for latency-measuring can be downloaded from our cvs via cvs -d:pserver:anonymous@cvs.iem.at:/cvsroot/latency login cvs -d:pserver:anonymous@cvs.iem.at:/cvsroot/latency co pd
thanks, i will have a look.
sorry for the confusion
me too.
not me ! it helps a lot to understand all these things :)
++ aym3ric.
now i know why you all get so damned good latencies. i guess the numbers are plain wrong when you refer to pd.
start to be confusing again :) if those values are wrong, what is the latency info in qjackctl is supposed to represent ? How can i measure the "real" latency within pd ? (i remember an out->in cable test patch posted a long time ago)
Selon aym3ric stm-sq@bleu255.com:
now i know why you all get so damned good latencies. i guess the numbers are plain wrong when you refer to pd.
start to be confusing again :) if those values are wrong, what is the latency info in qjackctl is supposed to represent ? How can i measure the "real" latency within pd ? (i remember an out->in cable test patch posted a long time ago)
play an electric or an electronic instrument through Pd, you may see very well if there's too much latency
I get a latency of 2.9 ms for Jack, and therefore this is the latency of the system when no audio program runs Under Pd the latency should of course be a bit higher, but still unperceptible (that was not the case under Windows XP)
-
aym3ric -
IOhannes m zmoelnig -
julien.breval＠tremplin-utc.net -
vanDongen/Gilcher -
zmoelnig＠iem.at