Ok Peter, let's move this over to pd-dev. There is no specific libpd list, is it?
I have now quickly looked into what the context of the socket polling is like in Pd. It is even done in the audio callback (via sys_pollgui) if this is enabled, so it can't really have serious side effects. As far as i have seen libpd also uses a callback based approach for audio, at least for iOS. Maybe introducing a sys_microsleep(0,1) in the audio callback does the trick? I will test that now. That said, i'm totally unaware of the details of other implementations.
all the best, gr~~~~
2013/1/21 Peter Brinkmann peter.brinkmann@googlemail.com
Hi Thomas, I have to admit that I didn't realize that netreceive requires an extra polling step. So, I'm afraid that netreceive is currently broken.
The question is what to do about this. I took a quick look at sys_domicrosleep and didn't immediately see how it works. I wouldn't mind integrating it into libpd somehow, but I want to be sure that there won't be any weird side effects. This seems slightly off-topic for pd-list. Shall we talk about this on pd-dev? Cheers, Peter
On Sun, Jan 20, 2013 at 6:42 PM, Thomas Grill gr@grrrr.org wrote:
Hi all, i am new to libpd and i have run into problems using netreceive on ios 5.1. While netsend works perfectly, netreceive doesn't work at all. Senders can connect to the receiving socket, but netreceive wouldn't spit out any data. Looking at the code, it seems to me that the polling of the net sockets (done in plain Pure Data in s_inter.c / sys_domicrosleep) is not called in libpd at all. I also couldn't find a different place where this is done. Does that mean that libpd doesn't currently service incoming socket data?
Thanks for clarification, all the best, gr~~~
-- Thomas Grill http://grrrr.org
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Thomas, There's no mailing list for libpd, but there is a forum: http://createdigitalnoise.com/categories/pd-everywhere In any case, this does seem like a question for pd-dev, so we're in the right place :)
About sys_microsleep, there are two potential problems that I'm concerned about about: The first is that it might block, but that doesn't seem to be the case since it's being called in the audio callback. The second concern is that I'm not sure how this low-level access to network sockets might behave on Android (which requires special permissions for internet access). I'm expecting that it'll be okay, but we need to make sure. Please let me know how it goes! Best, Peter
On Mon, Jan 21, 2013 at 6:43 AM, Thomas Grill gr@grrrr.org wrote:
Ok Peter, let's move this over to pd-dev. There is no specific libpd list, is it?
I have now quickly looked into what the context of the socket polling is like in Pd. It is even done in the audio callback (via sys_pollgui) if this is enabled, so it can't really have serious side effects. As far as i have seen libpd also uses a callback based approach for audio, at least for iOS. Maybe introducing a sys_microsleep(0,1) in the audio callback does the trick? I will test that now. That said, i'm totally unaware of the details of other implementations.
all the best, gr~~~~
2013/1/21 Peter Brinkmann peter.brinkmann@googlemail.com
Hi Thomas, I have to admit that I didn't realize that netreceive requires an extra polling step. So, I'm afraid that netreceive is currently broken.
The question is what to do about this. I took a quick look at sys_domicrosleep and didn't immediately see how it works. I wouldn't mind integrating it into libpd somehow, but I want to be sure that there won't be any weird side effects. This seems slightly off-topic for pd-list. Shall we talk about this on pd-dev? Cheers, Peter
On Sun, Jan 20, 2013 at 6:42 PM, Thomas Grill gr@grrrr.org wrote:
Hi all, i am new to libpd and i have run into problems using netreceive on ios 5.1. While netsend works perfectly, netreceive doesn't work at all. Senders can connect to the receiving socket, but netreceive wouldn't spit out any data. Looking at the code, it seems to me that the polling of the net sockets (done in plain Pure Data in s_inter.c / sys_domicrosleep) is not called in libpd at all. I also couldn't find a different place where this is done. Does that mean that libpd doesn't currently service incoming socket data?
Thanks for clarification, all the best, gr~~~
-- Thomas Grill http://grrrr.org
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Thomas Grill http://grrrr.org
Hi Peter, at least on iOS, the whole thing boils down to the patch below. I added two initialization functions to libpd_init, the first sys_findprogdir for finding the pd binary directory (actually to initialize the symbol sys_libdir which can also be done manually), and second sys_startgui to initialize the data structures for networking. That this fundamental functionality is mangled with GUI-related code is not pretty and should certainly be refactored (in Pd proper). The polling happens in the PROCESS macro, after audio has been processed. I think using a sleep time of 0 it should be non-blocking, but it would definitely be better (in sys_domicrosleep) to avoid calling the system function Sleep (only matters for WIN32) for timeouts of 0. Maybe Miller should review that. I am not sure whether using memory management functions in an audio callback is a problem - it shouldn't, as Miller certainly had a look at that. This happens because the incoming networking data is stored in dynamically allocated binbuf structures. That's my report - it works for me now. all the best, gr~~~
----------
--- a/libpd_wrapper/z_libpd.c +++ b/libpd_wrapper/z_libpd.c @@ -20,6 +20,8 @@ #include "g_all_guis.h"
void pd_init(void); +void sys_findprogdir(char *progname); +int sys_startgui(const char *guipath);
t_libpd_printhook libpd_printhook = NULL; t_libpd_banghook libpd_banghook = NULL; @@ -65,7 +67,9 @@ void libpd_init(void) { sys_nmidiout = 0; sys_time = 0; pd_init(); + sys_findprogdir(""); /* set sys_progname, guipath */ libpdreceive_setup(); + sys_startgui(sys_libdir->s_name); /* start the gui */ sys_set_audio_api(API_DUMMY); sys_searchpath = NULL; } @@ -128,6 +132,7 @@ static const t_sample sample_to_short = SHRT_MAX, } \ } \ } \ + sys_microsleep(0); \ return 0;
int libpd_process_short(int ticks, short *inBuffer, short *outBuffer) {
2013/1/21 Peter Brinkmann peter.brinkmann@googlemail.com
Hi Thomas, There's no mailing list for libpd, but there is a forum: http://createdigitalnoise.com/categories/pd-everywhere In any case, this does seem like a question for pd-dev, so we're in the right place :)
About sys_microsleep, there are two potential problems that I'm concerned about about: The first is that it might block, but that doesn't seem to be the case since it's being called in the audio callback. The second concern is that I'm not sure how this low-level access to network sockets might behave on Android (which requires special permissions for internet access). I'm expecting that it'll be okay, but we need to make sure. Please let me know how it goes! Best, Peter
On Mon, Jan 21, 2013 at 6:43 AM, Thomas Grill gr@grrrr.org wrote:
Ok Peter, let's move this over to pd-dev. There is no specific libpd list, is it?
I have now quickly looked into what the context of the socket polling is like in Pd. It is even done in the audio callback (via sys_pollgui) if this is enabled, so it can't really have serious side effects. As far as i have seen libpd also uses a callback based approach for audio, at least for iOS. Maybe introducing a sys_microsleep(0,1) in the audio callback does the trick? I will test that now. That said, i'm totally unaware of the details of other implementations.
all the best, gr~~~~
2013/1/21 Peter Brinkmann peter.brinkmann@googlemail.com
Hi Thomas, I have to admit that I didn't realize that netreceive requires an extra polling step. So, I'm afraid that netreceive is currently broken.
The question is what to do about this. I took a quick look at sys_domicrosleep and didn't immediately see how it works. I wouldn't mind integrating it into libpd somehow, but I want to be sure that there won't be any weird side effects. This seems slightly off-topic for pd-list. Shall we talk about this on pd-dev? Cheers, Peter
On Sun, Jan 20, 2013 at 6:42 PM, Thomas Grill gr@grrrr.org wrote:
Hi all, i am new to libpd and i have run into problems using netreceive on ios 5.1. While netsend works perfectly, netreceive doesn't work at all. Senders can connect to the receiving socket, but netreceive wouldn't spit out any data. Looking at the code, it seems to me that the polling of the net sockets (done in plain Pure Data in s_inter.c / sys_domicrosleep) is not called in libpd at all. I also couldn't find a different place where this is done. Does that mean that libpd doesn't currently service incoming socket data?
Thanks for clarification, all the best, gr~~~
-- Thomas Grill http://grrrr.org
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Thomas Grill http://grrrr.org
On 21 January 2013 at 14:57 Thomas Grill gr@grrrr.org wrote:
I am not sure whether using memory management functions in an audio callback is a problem
Yikes!
http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-f...
2013/1/21 padawan12@obiwannabe.co.uk padawan12@obiwannabe.co.uk
**
On 21 January 2013 at 14:57 Thomas Grill gr@grrrr.org wrote:
I am not sure whether using memory management functions in an audio callback is a problem
Yikes!
http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-f...
You (and Ross) are certainly right. Someone has to find a better solution, maybe using an extra thread that is signalled by the audio callback. For libpd that should be easier (because it's very clean right now) than for Vanilla Pd. gr~~~
By the way, is MIDI in working at all? I ask because it doesn't for me, and there's a sys_pollmidiqueue function in Pd that doesn't appear to be called in the libpd wrappers. gr~~~
2013/1/21 Thomas Grill gr@grrrr.org
2013/1/21 padawan12@obiwannabe.co.uk padawan12@obiwannabe.co.uk
**
On 21 January 2013 at 14:57 Thomas Grill gr@grrrr.org wrote:
I am not sure whether using memory management functions in an audio callback is a problem
Yikes!
http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-f...
You (and Ross) are certainly right. Someone has to find a better solution, maybe using an extra thread that is signalled by the audio callback. For libpd that should be easier (because it's very clean right now) than for Vanilla Pd. gr~~~
-- Thomas Grill http://grrrr.org
Sorry, one more note: In libpd, sched_tick is currently calling in the PROCESS macro in the context of the audio callback (in z_libpd.c). The function sched_tick handles all timed objects (such as metro) and therefore triggers all kinds of message processing downstream, where also memory operations commonly happen. In this sense, calling sys_domicrosleep at the end of PROCESS does not make the situation worse than it is right now.
gr~~~
2013/1/21 Thomas Grill gr@grrrr.org
2013/1/21 padawan12@obiwannabe.co.uk padawan12@obiwannabe.co.uk
**
On 21 January 2013 at 14:57 Thomas Grill gr@grrrr.org wrote:
I am not sure whether using memory management functions in an audio callback is a problem
Yikes!
http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-f...
You (and Ross) are certainly right. Someone has to find a better solution, maybe using an extra thread that is signalled by the audio callback. For libpd that should be easier (because it's very clean right now) than for Vanilla Pd. gr~~~
-- Thomas Grill http://grrrr.org
On Mon, Jan 21, 2013 at 11:30 AM, Thomas Grill gr@grrrr.org wrote:
Sorry, one more note: In libpd, sched_tick is currently calling in the PROCESS macro in the context of the audio callback (in z_libpd.c). The function sched_tick handles all timed objects (such as metro) and therefore triggers all kinds of message processing downstream, where also memory operations commonly happen. In this sense, calling sys_domicrosleep at the end of PROCESS does not make the situation worse than it is right now.
gr~~~
Why doesn't sched_tick call sys_domicrosleep then?
That function is making sleep and lock calls that I don't think should be made in libpd's process loop verbatum - timing is handled by whatever audio callback mechanism is using libpd and locking is handled within the language / framework wrappers.
It looks like the meat and potatoes is the following funky guy:
(*sys_fdpoll[i].fdp_fn)(sys_fdpoll[i].fdp_ptr, sys_fdpoll[i].fdp_fd);
If this were to be utilized by libpd, we should probably create a new, barebones method that does this polling (whatever that is...).
cheers,
Rich
I'm not sure but I believe it should work if you periodically call sys_domicrosleep(0, 1) - this asks it not to sleep at all but just to poll all the FDs Pd is watching.
cheers Miller
On Sat, Jan 26, 2013 at 11:16:41PM -0500, Rich E wrote:
On Mon, Jan 21, 2013 at 11:30 AM, Thomas Grill gr@grrrr.org wrote:
Sorry, one more note: In libpd, sched_tick is currently calling in the PROCESS macro in the context of the audio callback (in z_libpd.c). The function sched_tick handles all timed objects (such as metro) and therefore triggers all kinds of message processing downstream, where also memory operations commonly happen. In this sense, calling sys_domicrosleep at the end of PROCESS does not make the situation worse than it is right now.
gr~~~
Why doesn't sched_tick call sys_domicrosleep then?
That function is making sleep and lock calls that I don't think should be made in libpd's process loop verbatum - timing is handled by whatever audio callback mechanism is using libpd and locking is handled within the language / framework wrappers.
It looks like the meat and potatoes is the following funky guy:
(*sys_fdpoll[i].fdp_fn)(sys_fdpoll[i].fdp_ptr, sys_fdpoll[i].fdp_fd);
If this were to be utilized by libpd, we should probably create a new, barebones method that does this polling (whatever that is...).
cheers,
Rich
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
Miller Puckette -
padawan12＠obiwannabe.co.uk -
Peter Brinkmann -
Rich E -
Thomas Grill