On Sat, 20 Jul 2002, stefan kersten wrote:
Frank Barknecht wrote:
smoerk hat gesagt: // smoerk wrote:
does pd support jack (jackit.sf.net)? IIRC there was a patch, which added jack support for an older pd version.
This patch doesn't work with pd-0.35 anymore, and I don't know of a newer one.
Regarding Jack I wonder, if it would be possible (useful?) to have a jack external in the vein of for example the soundfile write/read objects?
i wrote a jack driver interface for pd that adheres to jack's callback model, i.e. pd's scheduler is completely driven by the jack processing callback. it basically works, but, as pd e.g. reads patches from the disk inside the audio callback, jack quite often throws pd out of its processing graph, when pd isn't able to meet a deadline.
in order to surpass this limitation i believe it would be necessary to rethink/-write a substantial amount of pd, essentially moving all non-realtime tasks (like disk access, calls to malloc, etc.) to other threads or making them asynchronous on one way or the other. IMO this would mean _lots_ of work, and i'm not sure how desirable it would be anyway.
note that adding jack support with a streaming implementation really would defy jack's most prominent feature: making several audio application cooperate while playing in sample sync ...
thoughts?
yes,
I think it is worth the effort, pd is meant to be lowlatency, so identifying the bottlenecks is important, if pd supports jack or not.
The problem that exists though, is that pd as a programming language depends on messages being synchronous with the signal processing, but only in few contexts, patch loading not being one of them.
On the other hand I think I do not understand how playing in sample synch can be achieved by multithreading. For soundfile reading for example. At the end you have to insert a buffer at one end or the other, which will make you lose your sample sync, no ?
Anyhow, I would be very interested to take a look at your solution.
Guenter