hi all
netpd's major problem is the occurence of many dropouts in certain situations. one reason is the way how all (at least all i know) network related objects in pd handle buffer overruns. when the buffer of a network object is full, the whole pd processing is stopped until the buffer gets emptied again. buffer overruns could be avoided in userspace, if these object would output their internal state. it would be already quite helpful, if there would be a second outlet, that outputs a bang when ever the buffer is completely emptied (like [textfile] or [list-drip] and other object do). with this information it would be possible to build a patch, that uses maximum bandwidth without ever getting dropouts. the above concerns at least [netsend], [netserver]/[netclient] (from maxlib) and possibly the objects from mrpeach.
as a crude solution to limit bandwidth in netpd, i made the attached abstraction [list-fifo]. i am not sure, if it is a suitable name.
@frank if you think, that fits into your list-abs-collection, feel free to add/modify it.
roman
I like the status message idea a lot. I think that whenever a Pd
object handles something that cannot be handled in one clock tick,
then there needs to be an output to communicate when the process
finishes.
Another example where this would be useful would be with [readsf~].
It uses a thread, so there are no guarantees that the [open( command
will return in any set amount of time. Its undetermined. So it
should output a message when it is ready to play so that open-then-
play could be handled programmically.
We are also working this out with [hidio]. A thread will probably be
necessary to build the device list without causing interruptions. So
the idea is that you send a [refresh( message, then it replies with a
[refresh 1( if successful and a [refresh 0( if complete, but
unsuccessful.
.hc
On Dec 17, 2006, at 1:42 PM, Roman Haefeli wrote:
hi all
netpd's major problem is the occurence of many dropouts in certain situations. one reason is the way how all (at least all i know)
network related objects in pd handle buffer overruns. when the buffer of a network object is full, the whole pd processing is stopped until the buffer gets emptied again. buffer overruns could be avoided in userspace, if these object would output their internal state. it would be already quite helpful, if there would be a second outlet, that outputs a bang when ever the buffer is completely emptied (like [textfile] or [list-drip] and other object do). with this
information it would be possible to build a patch, that uses maximum bandwidth
without ever getting dropouts. the above concerns at least [netsend], [netserver]/[netclient] (from maxlib) and possibly the objects from mrpeach.as a crude solution to limit bandwidth in netpd, i made the attached abstraction [list-fifo]. i am not sure, if it is a suitable name.
@frank if you think, that fits into your list-abs-collection, feel free to add/modify it.
roman <list-fifo.pd> <list-fifo-help.pd> _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Mistrust authority - promote decentralization. - the hacker ethic
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
as a crude solution to limit bandwidth in netpd, i made the attached abstraction [list-fifo]. i am not sure, if it is a suitable name.
@frank if you think, that fits into your list-abs-collection, feel free to add/modify it.
Thanks a lot, this can be a very useful patch. I added it to the [list]-abs on CVS with some small changes/extensions: Internally it uses the new [list-extend] abstraction now to build lists from incoming messages. I added a "clear" method to the first inlet to empty the FIFO, I changed the default delimiter to the empty symbol, and added the possibility to set the delimiter with an abstraction argument as well like [list-fifo my-l33t-del1m17er]
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Mon, 2006-12-18 at 13:47 +0100, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
as a crude solution to limit bandwidth in netpd, i made the attached abstraction [list-fifo]. i am not sure, if it is a suitable name.
@frank if you think, that fits into your list-abs-collection, feel free to add/modify it.
Thanks a lot, this can be a very useful patch. I added it to the [list]-abs on CVS with some small changes/extensions: Internally it uses the new [list-extend] abstraction now to build lists from incoming messages. I added a "clear" method to the first inlet to empty the FIFO, I changed the default delimiter to the empty symbol, and added the possibility to set the delimiter with an abstraction argument as well like [list-fifo my-l33t-del1m17er]
wow.. cool!
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Sun, 17 Dec 2006, Roman Haefeli wrote:
netpd's major problem is the occurence of many dropouts in certain situations. one reason is the way how all (at least all i know) network related objects in pd handle buffer overruns. when the buffer of a network object is full, the whole pd processing is stopped until the buffer gets emptied again.
Pd doesn't handle all of its sockets like that. There's one special socket that handles it differently, and it's the socket that talks to the GUI process. In Pd 0.38, Miller added a bunch of special code in s_inter.c that allows it to do nonblocking writes and causes it to replace the output buffer by a bigger one.
The problems that I see with that are:
- there's no way to limit the size of the output buffer. If the other
side of the connection doesn't respond, the sending buffer just inflates quickly. I've seen it happen that a bug in the sender causes it to try to send so fast that it ate memory like an infinite recursion or a forkbomb.
- That operation is not realtime-safe (but still it's much closer to
being so than just blocking...)
It's only usable by the GUI socket and never by [netsend].
While that buffer together with t_guiqueue allow GUI updates to be
delayed for as long as necessary, it doesn't solve the problem that it can send information that is already outdated and redundant. This can be important in preventing problem #1 for a very heavy GUI. DesireData has had this problem essentially dealt with since a long time, but it lacks some fine tuning to get more robust.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
Frank Barknecht -
Hans-Christoph Steiner -
Mathieu Bouchard -
Roman Haefeli