Thanks for the introduction.
Sure, I tried to increase the memory to 256MB and 1024MB.
I tested it on a pure Raspberry Pi OS (32-bit) Lite and on Astroberry (btw sweet )
It made no difference.

I used to deal with driver optimization in the USB2.0 era. In fact, unjustified shortcuts were used so as not to overload the CPU, which actually made things worse.
It scares me that today's so efficient computers have a problem with such basic communication.
Recently, I became interested in telescopes and astrophotography. In my free time (if my daughter allows me ) I would like to be active in this extensive topic.

I think direct communication (without zwo drivers) with the camera will reveal where the problem lies. Work in progress.

Anyone interested in this topic?
Is the subject of Raspberry PI still not popular in astrophotography with high-speed cameras?

Over the past weeks, I have analyzed a large part of the LibASICamera2.a library. The most important classes of CCameraFX3 and CircBuf have not been properly implemented for their intended purpose.
For example, the startAsyncXfer method sets up bulk transfers to usb, and then waits for them to be processed, without preparing any more transfers. Then the data is copied in the CircBuf class.
The authors used asynchronous libusb functions to create synchronous communication.

Initial tests of the wrapped library showed that I was able to achieve the full throughput (60fps) without any problems.

My suggestion is to write an overlay to the library to provide asynchronous communication and queuing of buffer pointers,
as well as the new ASIGetVideoDataPointer function to get a data buffer without duplicating data unnecessarily.
Possibility to monitor the size of the queue so that the data from usb up to processing is in the same buffer (streammanager class in Indi).
I also think it is possible to be compatible with new libAsiCamera2 releases.

Pawel,

this is interesting stuff and you are doing a great job. I have never got this camera to work properly on Linux systems (even the big ones). That's why I still need a W10 box for Solar work (high frame rate/16bit). On the same computer (AMD 1500, USB3.1 under W10 it works without any glitch, but had to get rid of W10-2004) If on the same hardware I run a 64bit Ubuntu mate, lots of errors and dropped frames. (Usuallt error 11 from the ASi libs under firecapture) If I drop the the USB limit to 80 it gets better, but in 16bit capture I don't get the same performance as in W10.

If you have a solution for that, it would be very helpfull getting rid of microsoft. (Maybe if you have a solution you should contact Sam at ZWO)

Regards,

Paul

That's extremely promising results Pawel! I also agree with Paul that this should also be communicated back to Sam to see if they can improve it on their end. Nevertheless, it would great to try this out. How can we test this now?