Hello all, I've a few questions to beg of you,
What are A/D/A sync errors caused by?
Also I seem to have plenty of spare time available when I run jackd (Thanks for the help by the way!) but I cannot fully utilize it. When I run: sudo jackd -v -R -d alsa -d hw:1 -r 48000 -p 32 Alsa says it cannot allocate a buffersize of 32. 64 seems as small as I can go. How can I circumvent this?
Lastly, what is this? bad window path name ".x0x8208f0" bad window path name ".x0x847780" bad window path name ".x0x881cb0"
Im running a voice synthsis patch with a seperate gem interface to be run on a different computer. When I start the voice interface wihtout the graphics I obviously get nesend errors, but I get these errors as well. PD-0.38-0test4. Any Ideas?
Thanks, -thewade
Hello
What are A/D/A sync errors caused by?
I don't know, but you can avoid them running jack as USER and Pd as ROOT in order to set it to realtime mode with the "-rt" flag
% su % password : % pd -jack -rt
with this solution, I don't get A/D/A errors, except if I open/close Pd files (and some Pd sub-windows with graphic arrays or tables, for example)
Also I seem to have plenty of spare time available when I run jackd (Thanks for the help by the way!) but I cannot fully utilize it. When I run: sudo jackd -v -R -d alsa -d hw:1 -r 48000 -p 32 Alsa says it cannot allocate a buffersize of 32. 64 seems as small as I can go. How can I circumvent this?
which sound card do you have ? mine doesn't even have 32 smp as buffer size
did you try to use qjackctl ? it's a QT graphical interface for jackd I think.
Hallo, julien.breval@tremplin-utc.net hat gesagt: // julien.breval@tremplin-utc.net wrote:
I don't know, but you can avoid them running jack as USER and Pd as ROOT in order to set it to realtime mode with the "-rt" flag
% su % password : % pd -jack -rt
with this solution, I don't get A/D/A errors, except if I open/close Pd files (and some Pd sub-windows with graphic arrays or tables, for example)
The clean way is, not to run jackd nor Pd as root, but give both higher priorities. For Pd this unfortunatly means "chmod +s /usr/bin/pd" which is still more secure than running as root, and jackd can be started as normal user through "jackstart" if you have a capabilities-patched 2.4 or 2.6 kernel, or as user, if you use the realtime-lsm module.
Alsa says it cannot allocate a buffersize of 32. 64 seems as small as I can go. How can I circumvent this?
which sound card do you have ? mine doesn't even have 32 smp as buffer size
Whooho, 64 already is *very* small. I never heard of anybody run jack with 32. That's almost hard-realtime!
Ciao
Frank Barknecht _ ______footils.org__
On Tue, 19 Oct 2004, Frank Barknecht wrote:
Whooho, 64 already is *very* small. I never heard of anybody run jack with 32. That's almost hard-realtime!
Hi. I'd like to know what you consider to be hard-realtime. I was under the impression that it meant that the problem requires strict time limits on the execution, and therefore using pd audio in a way that causes no dropouts may already be considered as hard-realtime, no matter how big the latency.
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Hallo, Matju hat gesagt: // Matju wrote:
On Tue, 19 Oct 2004, Frank Barknecht wrote:
Whooho, 64 already is *very* small. I never heard of anybody run jack with 32. That's almost hard-realtime!
Hi. I'd like to know what you consider to be hard-realtime. I was under the impression that it meant that the problem requires strict time limits on the execution, and therefore using pd audio in a way that causes no dropouts may already be considered as hard-realtime, no matter how big the latency.
I didn't intend to be technically correct, but illustrative. The correct description of hard realtime is of course yours: fixed upper latency limits. In that way, Linux might be considered hard-realtime already, with a hard latency of, say, several minutes. ;) Generally though people are not interested in hard latencies that big.
I was more referring to the special purpose realtime OSes, some based on Linux like RTLinux, which actually provide hard realtime in the microsecond area.
For our normal uses this would be overkill, IMO, and it's not the goal of most efforts in getting lower latencies for the general purpose Linux kernel. Although there are efforts to get hard realtime into the kernel, too. [1] This is important for several kinds of embedded devices, and the results of course can benefit our needs, too. But then probably an overhaul of Pd's architecture would be needed to make use of it.
[1] http://source.mvista.com/linux_2_6_RT_Announce.txt
Ciao
Frank Barknecht _ ______footils.org__
On Tuesday 19 October 2004 07:40, Frank Barknecht wrote:
Whooho, 64 already is *very* small. I never heard of anybody run jack with 32. That's almost hard-realtime!
Several people are running jack with -p8 or -p16 using the latest realtime-preempt patches on linux 2.6.9 I can run -p16 without xruns on 2.6.9-rc4-mm1 as long as I don't use disc-access, that's even without ingo's latest harder realtime patches. (Of course if I don't do anything, no apps, no X, just start jackd, I can go to -p8. But that is really pointless, but neat.) I'll try the latest patches and do the latency-limbo, how low can you go.
The downside is that periodsizes that small are less efficient for synthesis, so the same thing takes more cpu and you hit your performance ceiling sooner In a way it is useless to go that low, but it does mean that the entire system is more robust, so bigger periods will perform better as well.
ciao
Gerard
Ciao
On Wed, 20 Oct 2004, vanDongen/Gilcher wrote:
On Tuesday 19 October 2004 07:40, Frank Barknecht wrote:
Whooho, 64 already is *very* small. I never heard of anybody run jack with 32. That's almost hard-realtime!
Several people are running jack with -p8 or -p16 using the latest realtime-preempt patches on linux 2.6.9
Just want to add that this "feature" depends primarily on the soundcard. Mine (SBLive) for example has a minimum of -p512.
If ALSA says it cannot set periodsize, then it can't, unless you change your soundcard hardware. And then there is the minimum latency implied by pd. Going beyond 64 does not make sense with pd. Sound I/O with pd is based on 64 bit chunks.
Guenter
I can run -p16 without xruns on 2.6.9-rc4-mm1 as long as I don't use disc-access, that's even without ingo's latest harder realtime patches. (Of course if I don't do anything, no apps, no X, just start jackd, I can go to -p8. But that is really pointless, but neat.) I'll try the latest patches and do the latency-limbo, how low can you go.
The downside is that periodsizes that small are less efficient for synthesis, so the same thing takes more cpu and you hit your performance ceiling sooner In a way it is useless to go that low, but it does mean that the entire system is more robust, so bigger periods will perform better as well.
ciao
Gerard
Ciao
-- electronic & acoustic musics-- http://www.xs4all.nl/~gml
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
On Wed, 20 Oct 2004 12:02:14 +0200 (CEST), guenter geiger geiger@xdv.org
wrote:
If ALSA says it cannot set periodsize, then it can't, unless you change your soundcard hardware. And then there is the minimum latency implied by pd. Going beyond 64 does not make sense with pd. Sound I/O with pd is based on 64 bit chunks.
Can't you set the block~ size smaller?
Gerard
On Wed, 20 Oct 2004, gerard van dongen wrote:
64 does not make sense with pd. Sound I/O with pd is based on 64 bit chunks.
Can't you set the block~ size smaller?
My tests shows that you need at least 3x times the blocksize, since you have a floating logical time.
Not for audio I/O. You would have to change the source and recompile with a different default blocksize.
there was some patch for a command line option,
Blocksize ist defined only in one #define so this could be easy to handle, but overhead of calling becomes higher so you need more cpu power.
mfg winfried
Winfried Ritsch wrote:
Not for audio I/O. You would have to change the source and recompile with a different default blocksize.
there was some patch for a command line option,
yes, i i have checked it into the pd-cvs: unfortunately i have made another branch (variable_blocksize or the like) AND it was against 0.37 or 0.36.
probably i'll do it again and commit it to pd_devel
mfg.asdr. IOhannes
yes, i i have checked it into the pd-cvs: unfortunately i have made another branch (variable_blocksize or the like) AND it was against 0.37 or 0.36.
hm ... additional branches are a wonderful mean to forget features *g*
probably i'll do it again and commit it to pd_devel
anyway, i'm not shure, how much work this would be, so maybe it's better to wait for 0.38 and add it to the devel_0_38 branch ...
cheers ... tim
Tim Blechmann wrote:
probably i'll do it again and commit it to pd_devel
anyway, i'm not shure, how much work this would be, so maybe it's better to wait for 0.38 and add it to the devel_0_38 branch ...
currently i have no time anyways, so i guess it will be in devel_0_38...
mfg.a.r IOhannes
-
Frank Barknecht -
gerard van dongen -
guenter geiger -
IOhannes m zmoelnig -
julien.breval＠tremplin-utc.net -
Matju -
thewade -
Tim Blechmann -
vanDongen/Gilcher
-
Winfried Ritsch