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

Seems to me it's possible to make Pd talk to jack without any major rewriting; simply make a library that appears from Pd to be called to transfer samples, and appears to jack to be called to provide samples. It would have to open a separate thread to respond to the jack calls, and maintain FIFOs to synchronize between them.

In Windows land, the same strategy would work for making PD act as a VST plug-in. Needless to say, I'll try this as soon as I don't have any more urgently needed stuff on my stack, or if someone else wants to try, be my guest...

cheers Miller

On Mon, Jul 22, 2002 at 07:55:08PM +0200, stefan kersten wrote:

günter geiger wrote: [...]

...

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.

this is perfectly ok as long as methods don't violate realtime constraints. still, i guess that making all sent messages return synchronously within the processing graph contributes to pd's design being as clear and understandable as it is currently.

i just had a thought: since audio is turned off anyway when reading patches (correct me if i'm wrong), it might be possible to deactivate the jack client for patch loading and reactivate it afterwards.

...

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 ?

the idea is to move non-realtime tasks (such as disk access) to separate (non-realtime) processes.

for disk streaming, you would read your data ahead of time, buffer it and preferably transfer it to the audio thread using lock-free ringbuffers, as done e.g. in ardour or ecasound, such that the audio processing callback won't get blocked under any circumstances (i think readsf~ does approximately that, too).

by 'sample synchronous' i referred to the exchange of data generated in realtime: in jack the clients' processing callbacks are triggered synchronously once per buffer computation; no latency due to intermediate buffering is introduced, just like in pd's processing of the dsp chain (the only exception being latencies due to graph cycles, in jack propably too).

...

Anyhow, I would be very interested to take a look at your solution.

i'll package the stuff and send it to you ...

<sk>

I read:

Miller Puckette wrote:

...

It would have to open a separate thread to respond to the jack calls, and maintain FIFOs to synchronize between them.

which brings me to another question, what do people on the list think about multithreaded externals and shouldn't we agree now on how to implement them. AFAICT from my somewhat limited pthread knowledge each and every extern author using threads should at least prefix mutex/conditional names with externalname_ otherwise we might well deadlock ourselves sooner than later .. any other thoughts/recommendations on this ?

(I could use threading in some of my [planned] externs, but won't jump in before the issue is somewhat clear, I know miller doesn't exactly like threads and I'm somewhat reluctant to release code that might break someone elses setup ...)

regards,

x

"static" is ok if you want one separate thread to handle all instances of your extern... if, as in readsf~ and writesf~, you need a separate thread for each instance, better put the mutexes and whatnot in the instance structure.

cheers Miller

On Thu, Jul 25, 2002 at 05:55:11PM +0200, Olaf Matthes wrote:

CK schrieb:

...

I read:

...

Miller Puckette wrote:

...

It would have to open a separate thread to respond to the jack calls, and maintain FIFOs to synchronize between them.

which brings me to another question, what do people on the list think about multithreaded externals and shouldn't we agree now on how to implement them. AFAICT from my somewhat limited pthread knowledge each and every extern author using threads should at least prefix mutex/conditional names with externalname_ otherwise we might well deadlock ourselves sooner than later .. any other thoughts/recommendations on this ?

Well, there already are two threaded objects in the standard Pd distribution: readsf~ and writesf~. I've successfully used the same 'principles' in my oggamp~ and oggcast~ externals and can run all of them togehter (or several instances of the same object) in one patch without any difficulties. Maybe I just missed the point but I personally don't see any problems why threaded externals should interfere (as long as the mutex/conditional variables are declared as 'static'). But I also have to admit that I'm no thread-expert.... (not even a C expert, just trying until it works)

Olaf

On Mon, 22 Jul 2002, stefan kersten wrote:

i just had a thought: since audio is turned off anyway when reading patches (correct me if i'm wrong), it might be possible to deactivate the jack client for patch loading and reactivate it afterwards.

it isnt so at the moment, but it could be done this way. There are other areas like array loading which might be problematic, but I think they can be handled, and generally pd meets the deadlines pretty well.

There isnt too much memory allocation, live patching being the most problematic case (but loosing this feature would be really bad).

<snip> > by 'sample synchronous' i referred to the exchange of data > generated in realtime: in jack the clients' processing > callbacks are triggered synchronously once per buffer > computation; no latency due to intermediate buffering is > introduced, just like in pd's processing of the dsp chain (the > only exception being latencies due to graph cycles, in jack > propably too).

ok, got it, thinking it over it is probably very bad adding some additional intermediate buffer to the pd adc and dacs to get rid of the problem, because it would increase latency too much.

Well we can't redesign pd from bottom up to make sure it works, but I hope that it is tweakable enough to work in practise.

Offering a callback based sound IO could be used to improve performance when using the portaudio library too.

...

Anyhow, I would be very interested to take a look at your solution.

i'll package the stuff and send it to you ...

Great !

Guenter

On Mon, 22 Jul 2002, CK wrote:

hi,

I read:

...

it isnt so at the moment, but it could be done this way.

I don't think so since ... . .

...

There isnt too much memory allocation, live patching being the most problematic case (but loosing this feature would be really bad).

which requires abstraction loading

you are right, didnt think of that. Probably it is possible to load a patch in another thread and hook it into the system when it is done ?

Guenter

Muy bien,

so we have both solutions and can try out which one is better.

BTW, due to pd's scheduler design, it doesnt make a big difference (theoretically) if you do it the correct way or, the hacked way. pd sleeps instead of blocking, and if it wakes up at the right time, it is able to fill the buffers and the overhead is (speak latency) not increased.

But I am not sure if it wakes up at the right time (depends on the system timer), and my crappy sblive here gives my 512 samples as smallest buffer with jack, which seems to be an eternity, so I will test latency later at home

Thanks a lot,

Guenter

On Thu, 25 Jul 2002, stefan kersten wrote:

hi list,

sorry for the delay. pd+jack is at:

http://www.cs.tu-berlin.de/~kerstens/pd.html

build instructions in the tarball.

<sk>