playerone: Fix 100% CPU usage during video streaming

[cfuture81]

Problem

The PlayerOne driver consumes 100% of a CPU core during video streaming, regardless of exposure time. Even at 0.5s exposure (2 FPS), the indi_playerone_ccd process pins a core at 100%.

Root Cause

workerStreamVideo() contains a tight busy-wait polling loop:

while (pIsReady == POA_FALSE)
{
    POAImageReady(mCameraInfo.cameraID, &pIsReady);
}

This spins with no sleep between calls, burning CPU cycles while waiting for a frame.

Fix

Remove the redundant POAImageReady() polling loop. POAGetImageData() already blocks internally until a frame is ready (up to waitMS timeout), making the polling unnecessary. This matches how the ASI driver uses ASIGetVideoData() — a single blocking call with timeout.

Before / After

	Before	After
CPU usage during streaming	~100% on one core	Near-idle between frames

indi settings:

cpu before fix:

cpu after fix:

Testing

Tested with PlayerOne Xena 585M (IMX585) on Intel N150 (x64, Arch Linux):

• 8-bit and 16-bit streaming modes
• Exposures from 0.001s to 0.5s
• Hardware binning 1x1 and 2x2
• No frame drops or streaming issues observed after the fix

[knro]

@jctk Can you please take a look?

[jctk]

Unfortunately, I don't have a Player One camera.

[knro]

Sorry that was by mistake! @hiro3110i can check :-)

[hiro3110i]

@cfuture81 Thank you for your suggestion.
I actually tried your suggestion and confirmed that it reduces CPU load. The PlayerOne sample code uses POAImageReady() to wait for the next frame and then POAGetImageData() to retrieve the frame image.
However, if POAGetImageData() can internally wait for the next frame, then the extra polling loop is unnecessary.

In actual operation, USB bus bandwidth is dominant, and I couldn't confirm that reducing CPU load had enough effect to improve the frame rate. However, generally speaking, lower load is better.

[knro]

@hiro3110i Great so no objections on merging this PR?

[hiro3110i]

@knro Yes, please.