so, tried lots of different things.. but still remains the same...
a) remove procesing
removed all processing, so just left the submitting and receiving of usb packets, and just checked the sequence id of packets - and i could still clearly see dropped requests.
what this showed better, was that it seemed be regularly loosing transfers, but at times, it starts loosing alot more than at other times. and due to (d) below - id say it comes and goes
b) usb submission thread
so, i noticed that I cannot see the usb submission thread explicity in xenomai/threads & stats.
even though i could see it must have been created thru a wrapped xenomai call.
any how to make things more explicit, i hacked things around, so that the submissions could be done with a BelaAuxillaryTask, with an appropriate rt priority
did this, and could now see it in xenomai/threads and stats
this didnt change the behaviour, and revealed this part was taking very close to 0% cpu.
this was as expect, as Id moved most real processing into the SPLitePrcocessTask.
so doesnt appeaer to be CPU starvatioin (at least by my process... im guessing it must be lower in the process stack.
c) tried on bela (as inital tests on salt), again same behaviour
d) made the process continue regardless of frame errors.
operation is affected as we are getting some bad data,
but whats interesting is, sometimes its seems to return to 'normal' for a while.
... as if the USB transfers improve.
so it looks like we go thru phases of more and less data loss over time.
not just its starts up, then goes bad... its seems it goes good, bad, good, bad...
(this is all on v3.4)
the most frustrating part is for 30 seconds it works almost flawlessly, then just alls falls apart...
whats odd, is it doesn't seem like gradual degradation, seems like it just starts loosing lots of transfers