ld auxreturn / auxsend source
ld auxreturn / auxsend source
anyone knows if these are open source? would need to take a look to implement aux.
Re: ld auxreturn / auxsend source
so far i got sending working, and using ld auxreturn to return it, but there is a problem: parts of the buffer are missing sometimes, it looks like the return machine reads it too soon or a multithreading issue, but when i try it with ld auxsend, it works... so not sure what auxsend does different.. are you supposed to pre-roll the buffer or something ? i see in auxbuss.cpp that the maximum samples is 256, so i don't think so...
below is a screenshot of how it looks, top is what ld auxreturn receives, bottom is what i send.
another problem could be that i use an old auxbus.lib (1999), not sure where to get a newer one, not even sure there is a newer one...
below is a screenshot of how it looks, top is what ld auxreturn receives, bottom is what i send.
another problem could be that i use an old auxbus.lib (1999), not sure where to get a newer one, not even sure there is a newer one...
- Attachments
-
- normal_out_vs_aux.png (100.33 KiB) Viewed 5011 times
Re: ld auxreturn / auxsend source
also i'm wondering how this can possibly even work reliably in a multi-threaded environment? i guess it relies on the guarantee that effects are processed after generators, even when multi threaded, so the aux return is always 1 buffer late? But surely, effect chains are put on different threads so its possible a generator runs in parallel with another effect in another chain, no? Auxbus wouldn't know about that.. i can see auxbus.cpp does some ringbuffering, but no locking whatsoever, the buffer is 256 samples, but that's also the maximum a work() call can process. If receive is done 1 work() call after the send work() call, and the receiver needs more samples than where written, how would it work..would that ringbuffer be sufficient to not cause dropouts? I must be misunderstanding something. Are send machines expected to manage the buffer fill? i don't think so, since you should just be able to pass in the input samples from your machine?
Re: ld auxreturn / auxsend source
Despite my obsessive compulsive machine source hoarding instincts, I don't have any of ld's machines but I do have this...
- Attachments
-
- AuxBus Lib Source.zip
- (16.98 KiB) Downloaded 187 times
Re: ld auxreturn / auxsend source
...and this...
- Attachments
-
- Jeskola AuxSend.zip
- (2.88 KiB) Downloaded 196 times
Re: ld auxreturn / auxsend source
thanks' this is what i'm already looking at to get a clue of how auxbus.lib (which i'm linking in and using auxbus.h header) works...
i can get it to somewhat reliably send the input signal to my machine (straight copy) but as soon as i do just a little more (like generate a sine myself) i get the occasional dropouts, so i think if you don't fill that aux buffer fast enough, that's a problem, which is why i wonder if its multi-threading related..
Re: ld auxreturn / auxsend source
Shame. Maybe someone has contact info for LD?
Re: ld auxreturn / auxsend source
Just looked and he's not been here since 2016 but it might be worth sending him a PM in case it still fires him an email
Re: ld auxreturn / auxsend source
here's what i don't understand, let's assume these are the two first work calls to happen and the auxbuffer is 256 in size:
work1: numsamples: 16 -> Send 16 samples to aux buffer
work2: numsamples 200 -> Receive 200 samples from aux buffer
well, obviously we never even wrote 200 samples yet...
according to auxbus.cpp when receiving:
paux->ReadPos = (paux->WritePos - numsamples) & (MAX_BUFFER_LENGTH-1); // fix: always read last written samples
so:
readpos = 16 - 200 & 255 = 72
so this would start reading from 72, which is fine i think (256 samples behind), but observed behavior is that the read and write pointers seem to drift over time causing dropouts and i can't find the reason. as if some work calls are skipped but only for one of the machines...
work1: numsamples: 16 -> Send 16 samples to aux buffer
work2: numsamples 200 -> Receive 200 samples from aux buffer
well, obviously we never even wrote 200 samples yet...
according to auxbus.cpp when receiving:
paux->ReadPos = (paux->WritePos - numsamples) & (MAX_BUFFER_LENGTH-1); // fix: always read last written samples
so:
readpos = 16 - 200 & 255 = 72
so this would start reading from 72, which is fine i think (256 samples behind), but observed behavior is that the read and write pointers seem to drift over time causing dropouts and i can't find the reason. as if some work calls are skipped but only for one of the machines...