Hi there !
I just opened the devel_0_37 branch on CVS. There are not too many differences between Millers version and this one.
- configure.in checks for tcl/tk headers again (this is needed for Debian mainly). - the tcl/tk 8.4 patch - JACK support as s_audio_jack.c (until jack support works in portaudio)
I have not yet included any of the patches from devel_0_37, mainly because several have already been there (thanks Miller, I hope it wasn't too much of a pain to incorporate them. If so, let us now, and we will try to find a better procedure).
I am going to incorporate some of the (small) changes that are needed for cross platform linux stuff (SPARC, IA64, etc, etc, ..).
If an important feature is missing (some of Thomas threading stuff ??) please let us discuss it.
A last thing, Frank , you said ALSA does not work on 0.37, but it should, because there is still native ALSA support.
The CVS devel_0_36 had a slighlty different ALSA implementation which made it possible to use the Hammerfall HDSP, should we use incorporate that ?
Well, thats it, happy hacking
Guenter
Hi Günter,
I just opened the devel_0_37 branch on CVS. There are not too many differences between Millers version and this one.
great!
If an important feature is missing (some of Thomas threading stuff ??) please let us discuss it.
Well, at least it's important for me, because in my externals (and i think to recall also in Olaf's) the clock functions are used for inter-thread-communication. For this to work reliably they have to be thread-safe. I think that this is the only possibility for threads in PD to communicate with the real-time-system. I implemented the necessary things in devel_0_36, so i would like to know if anyone had problems with it (like timing hickups, deadlocks, clicks etc.). I use this version on a regular basis and haven't encountered problems lately. Therefore, it would be great if we could merge it into the devel_0_37 branch.
best greetings, Thomas
On Mon, 2 Jun 2003, Thomas Grill wrote:
Hi G�nter,
I just opened the devel_0_37 branch on CVS. There are not too many differences between Millers version and this one.
great!
If an important feature is missing (some of Thomas threading stuff ??) please let us discuss it.
Well, at least it's important for me, because in my externals (and i think to recall also in Olaf's) the clock functions are used for inter-thread-communication. For this to work reliably they have to be thread-safe. I think that this is the only possibility for threads in PD to communicate with the real-time-system. I implemented the necessary things in devel_0_36, so i would like to know if anyone had problems with it (like timing hickups, deadlocks, clicks etc.). I use this version on a regular basis and haven't encountered problems lately. Therefore, it would be great if we could merge it into the devel_0_37 branch.
Ok, take a look whats there, would be cool if you can put it in yourself if something is missing. I personally never experienced any problems with it.
Greetings, Guenter
What's wrong with simply putting a mutex around all of Pd? that way other threads could just make calls right into "receive" objects without having to set and wait for clock callbacks. Perhaps I'm missing something but that seems the much simpler solution for making threaded externs.
Pd's scheduler would simply lock all pf Pd whenever it issues a message or runs a DSP tick, and unlock it when it ``idles".
cheers Miller
On Mon, Jun 02, 2003 at 04:04:26PM +0200, Thomas Grill wrote:
Hi Günter,
I just opened the devel_0_37 branch on CVS. There are not too many differences between Millers version and this one.
great!
If an important feature is missing (some of Thomas threading stuff ??) please let us discuss it.
Well, at least it's important for me, because in my externals (and i think to recall also in Olaf's) the clock functions are used for inter-thread-communication. For this to work reliably they have to be thread-safe. I think that this is the only possibility for threads in PD to communicate with the real-time-system. I implemented the necessary things in devel_0_36, so i would like to know if anyone had problems with it (like timing hickups, deadlocks, clicks etc.). I use this version on a regular basis and haven't encountered problems lately. Therefore, it would be great if we could merge it into the devel_0_37 branch.
best greetings, Thomas
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
What's wrong with simply putting a mutex around all of Pd? that way other threads could just make calls right into "receive" objects without having to set and wait for clock callbacks. Perhaps I'm missing something but that seems the much simpler solution for making threaded externs.
Pd's scheduler would simply lock all pf Pd whenever it issues a message or runs a DSP tick, and unlock it when it ``idles".
cheers Miller
Is it not possible to do a mutex thread with the DSP function? Would this assure that the DSP calls would have enough time to complete without fighting sys_pollgui() and the other calls for time? Or would those have to be threaded as well? It seems like when DSP is on that all other tasks need to be subservient to the computing of audio to ensure proper audio performance.
It would be really great to have some sort of solution to this within the Pd scheduler.
cgc
I think it's fine to have DSP and pollgui, etc., in the same thread (I hope to improve the relative scheduling of real-time and graphics by queueing graphics updates but am stuck at the moment on that.) It seems to be emerging that on most systems at least, setting separate threads for audio computations doesn't actually improve real-time performance.
cheers Miller
On Mon, Jun 02, 2003 at 01:00:34PM -0500, chris clepper wrote:
What's wrong with simply putting a mutex around all of Pd? that way other threads could just make calls right into "receive" objects without having to set and wait for clock callbacks. Perhaps I'm missing something but that seems the much simpler solution for making threaded externs.
Pd's scheduler would simply lock all pf Pd whenever it issues a message or runs a DSP tick, and unlock it when it ``idles".
cheers Miller
Is it not possible to do a mutex thread with the DSP function? Would this assure that the DSP calls would have enough time to complete without fighting sys_pollgui() and the other calls for time? Or would those have to be threaded as well? It seems like when DSP is on that all other tasks need to be subservient to the computing of audio to ensure proper audio performance.
It would be really great to have some sort of solution to this within the Pd scheduler.
cgc
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
Hi,
What's wrong with simply putting a mutex around all of Pd? that way other threads could just make calls right into "receive" objects without having to set and wait for clock callbacks. Perhaps I'm missing something but
that
seems the much simpler solution for making threaded externs.
Pd's scheduler would simply lock all pf Pd whenever it issues a message or runs a DSP tick, and unlock it when it ``idles".
that sounds very reasonable and efficient. The reason why i preferred the clock functions is probably my lack of insight. Is my understanding right that there shall be something like pd_lock() and pd_unlock() functions that are used around every call into the pd API from a second thread?
best greetings, Thomas
I think that's correct... So at all Pd callbacks (new, free, and message routines, even setup()) the lock would already have been obtained by Pd, and anytime you want your own thread to call into Pd you just lock it and go.
cheers Miller
On Mon, Jun 02, 2003 at 09:00:21PM +0200, Thomas Grill wrote:
Hi,
What's wrong with simply putting a mutex around all of Pd? that way other threads could just make calls right into "receive" objects without having to set and wait for clock callbacks. Perhaps I'm missing something but
that
seems the much simpler solution for making threaded externs.
Pd's scheduler would simply lock all pf Pd whenever it issues a message or runs a DSP tick, and unlock it when it ``idles".
that sounds very reasonable and efficient. The reason why i preferred the clock functions is probably my lack of insight. Is my understanding right that there shall be something like pd_lock() and pd_unlock() functions that are used around every call into the pd API from a second thread?
best greetings, Thomas
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
- configure.in checks for tcl/tk headers again (this is needed for Debian mainly).
- the tcl/tk 8.4 patch
- JACK support as s_audio_jack.c (until jack support works in portaudio)
First: thanks a lot for your effort.
I still am not successful, though.
I get this error when trying Jack 0.71 (Debian unstable) after a fresh checkout of Pd:
$ pd -jack reading startup file: /home/freak/.pdrc Testing for Jack could not attach as client (duplicate client name?) could not attach as client
There is no pure-data running else.
A last thing, Frank , you said ALSA does not work on 0.37, but it should, because there is still native ALSA support.
ALSA with devel_037 works in principle, but gives wrong sounds. The test patch sounds very distorted and also the sine frequencies are wrong. I'm using a Delta Audiophile...
ciao
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
ALSA with devel_037 works in principle, but gives wrong sounds. The test patch sounds very distorted and also the sine frequencies are wrong. I'm using a Delta Audiophile...
Update: It works okay it I start "-alsa -alsadev default"...
ciao
On Mon, 2 Jun 2003, Frank Barknecht wrote:
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
- configure.in checks for tcl/tk headers again (this is needed for Debian mainly).
- the tcl/tk 8.4 patch
- JACK support as s_audio_jack.c (until jack support works in portaudio)
First: thanks a lot for your effort.
I still am not successful, though.
I get this error when trying Jack 0.71 (Debian unstable) after a fresh checkout of Pd:
$ pd -jack reading startup file: /home/freak/.pdrc Testing for Jack could not attach as client (duplicate client name?) could not attach as client
There is no pure-data running else.
Strange, I tested with jack 0.50 and 0.71. on two machines and it worked on both (notebook and desktop with SBLive). Furthermore I did not really change anything in the code. Clueless up to now.
A last thing, Frank , you said ALSA does not work on 0.37, but it should, because there is still native ALSA support.
ALSA with devel_037 works in principle, but gives wrong sounds. The test patch sounds very distorted and also the sine frequencies are wrong. I'm using a Delta Audiophile...
Is this with some special setting. I have the problem that you described with the nasty startup sound too, but then it works. Again no idea. I could port the modified alsa version from 0_36_devel to 0_37_devel, maybe this helps.
Thanks for the feedback anyhow.
Guenter
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
Strange, I tested with jack 0.50 and 0.71. on two machines and it worked on both (notebook and desktop with SBLive). Furthermore I did not really change anything in the code. Clueless up to now.
It seems to be a jack problem: I can use pd with jack running on "hw:0" but not with Jack on device "default". In fact, Jack doesn't produce sound at all with "default" here, which is strange, but not Pd's fault.
Is this with some special setting. I have the problem that you described with the nasty startup sound too, but then it works. Again no idea. I could port the modified alsa version from 0_36_devel to 0_37_devel, maybe this helps.
I think, I still have Pd 0.36 with the old alsa code here, and when I try to run with "-alsadev default" audio is stuck. Being able to use the named interface is probably much more flexible, when it comes to multichannel cards thanks to asoundrc magic - so I don't necessarily "want my old Pd back".
I'm quite sure, that the idiosyncratic ICE1712 chipset is the reason. I also have a SBLive in this machine, but cannot test right now because I have no cable for it. :(
But the ICE1712 is a bit strange in that ALSA accesses the hw-layer with a certain setting (period size, samplerate, bitdepth), for conversions the plug-layer seems to be needed.
I guess now most of my problems are solved and I can update Pd on my main machine. Will you put a debian directory into the pd-dir?
One problem remains: If I start a quite complex patch with Pd in "-realtime" mode and Jack, Pd just hangs. The error message of Jack is:
subgraph starting at pure_data_0 timed out (subgraph_wait_fd=11, status = 134629112, state = Running) client pure_data_0 error: awake_at = 37365543201 state = 2 timed_out = 0
I tried playing with the jack -t option and set it very high and very low, but it didn't help. I guess, I might disable jack_connecting on startup again, but maybe this could be a command line option later?
(But this also happens if I start Pd, manually jack_disconnect Pd and try to open that patch. I could send you the patch, but it still has some highly personalized absolute paths in it.)
ciao
-
chris clepper -
Frank Barknecht -
guenter geiger -
Miller Puckette -
Thomas Grill