Of course you see no difference, since the triggering of the [sfplay2~] objects happens at the control rate, so whether wired or wireless, all messages will reach their destinations before the next sample block starts. Just bare in mind that Pd computes all its audio objects in blocks of samples (64 samples per block, by default), and when done, it makes all the control rate calculations (all objects without the tilde (~)), so your starting messages will all go through in between the same two blocks of samples.

@KMETE have you given this a try? Or are you asking to eliminate the possibility of an unpleasant surprise? Because I think what you need to do is very simple, and it does make me wander what triggers your query. Also, what @jameslo proposes can also work, as a 10-track audio file will be played from 10 different outlets in your sound file player object, so you can easily route them to any [dac~] inlet you want.

I will again mention the Jack audio server here, as it can do what you want without breaking a sweat. If you have Jack support in Pd and Python (you can have that with Pyo), then you just make the connections in Jack's graph, and that's all.
As for mrpeach, unfortunately, Martin Peach passed away about a year ago. I don't know if someone has taken over the maintenance of his library though.

I don't know the [sfplay2~] object, but I guess you can do it with Pd's native [readsf~]. Just make sure you give a few seconds to all [readsf~] objects to load their tracks, before you start playing. Just read its help patch.

I might be totally wrong here, but I think that the GPU is used by shaders only, in which case you have to look into the glsl objects of Gem.

The feedback does not occur between [delwrite~] and [delread~] if not patched explicitly. [delread~] reads from the corresponding [delwrite~]. To create feedback, you'll still need to use [s~]/[r~] etc, to send the output of [delread~] back to the input of [delwrite~]
Mind though that it's best to put the writing and the reading parts of your delay in separate subpatches, where the one with [delwrite~] will have a dummy [outlet~], and the one with [delread~] will have a dummy [inlet~]. Then you must connect the two in the parent patch, to circumvent the issue of not being able to drop the delay time lower than one sample block. By making this connection you explicitly force Pd to first compute [delwrite~] and then [delread~], so delays up to a single sample are possible. This is somewhat related to the feedback issue you were having, and the way Pd treats signals.

When you want to create feedback, you need to use either a [s~ ]/[r~ ] or [throw~]/[catch~] pair, or write to a table with [tabsend~] and read with [tabreceive~]. Didn't check your patches, but DSP loops are detected when a signal chain returns to a previous point.

Think of it like this, in the following ASCII patch:

[osc~]
|
[*~ ]

[osc~] needs to make its computations before it sends its output to [*~ ]. If [*~ ] was to send its output back to [osc~]'s inlet, the latter would not be able to compute this signal, as it will be generated after [osc~]'s own output has been computed. Using a [s~ ]/[r~ ] pair, you can be sure that [*~ ] will send its output to [s~ ], which in turn will transfer it to [r~ ], without disturbing the signal chain order

@Schlamborius I'm not sure. I can compile the object with a simple make, but I can't load it, as I get some error about _Py_NoneStruct, which the developer of Pyo can't reproduce, so I have abandoned this for now, and every now and then I keep thinking that I have to retry.
How did you compile? Which Pyo version do you have?

I've written a paper titled: "[neuralnet]: A Pure Data External for the Creation of Neural Networks Written in Pure C", and it's available through the proceedings of the last AIMC that just happened in Brighton!
Here's the paper.

I think the jmmmp library of vanilla abstractions has one. It's available in deken.