I’m sorry, The camera is not defective. It works very stable on usb3.0 + windows.
But on the Raspberry Pi, there are still some limitations.
We can guarantee that the camera has the possibility of large resolution, but this still needs to be explored by the developers.
The crowdfunding directly states that is for RPI.
Indeed even has some features publicized that depends directly on the libcamera implementation.
Using an USB3 testing platform as Q&A of a RPI product is somewhat wrong.
Have had asked just for a kind of solution like you said before.
Should need at least tested solutions to use the camera outside RPI enviroment, like an USB or PCI adapter **that supports the 64MP/108MP+ **, has full control, and lossless compression.
“Just like these flagship phones, your Raspberry Pi now has an ultra high-res camera too. And just like them, your Pi can take still images at a breathtaking resolution (9152 x 6944) as well! Pi Hawk-eye is ready to make millions proud.”
What you are even taking about? What USB3 and windows has to do with it?
Not working RAW should have been mentioned in documentation. Did you even try to test the product? This error is caught after 5 mins real world use.
I’m sorry, I think we’ve had some misunderstandings. I would like to reorganize my thinking.
I gave the windows + USB example as inappropriate, I changed the verification, turned off the media controller, and used v4l2-ctl to fetch raw data from video0 instead.
time v4l2-ctl --set-fmt-video=width=9152,height=6944,pixelformat=RG10 --stream-mmap --stream-count=-1
I took 10 minutes of raw data at the maximum resolution to verify that the camera is stable enough. The result is very stable, of course, you can test for longer periods of time.
Since the 64MP resolution is too large, the Raspberry Pi may not have been designed with such a large resolution in mind, which leads to some memory shortages when running such a large resolution on the Raspberry Pi (currently CMA can only be set to 512MB max).
We have minimized buffer usage in libcamera, but still, occasionally encounter memory allocation problems.
Through our guesses and tests by Raspberry Pi engineers, we found that this is due to CMA memory fragmentation, a problem currently officially recommended by Raspberry Pi as “Adding “alloc_in_cma_threshold=16” in /boot/cmdline.txt”. After our testing, it does solve the problem, but it is not a perfect solution, and there are still user reactions that cause problems.
I did do a lot of testing before the product was released, on different versions of multiple devices, and found no such issues. This is a fairly unique situation and I am currently doing my best to do some testing. What I can confirm right now is that this phenomenon follows the SD card and replacing the SD may also solve the issue.
I am currently actively doing some debugging to see if I can fix some of the issues.
So far I have found a way to save the png format and I will sort it all out later.
I’ll also be starting a new thread later for all the methods, so hopefully we’ll be in active communication by then.
Thanks, will prepare a brand new 32Gb SD and follow all the steps.
Would be useful if you could make an .img (.xz) (with DD or so) of your installation so We can test together over the same base, and then discard software (leaving only hardware revisions to evaluate)
The offer to make a mirror is also a good one, but I have a lot of high priority work lately and I will make an updated mirror with all the camera environments in my free time.
# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details
# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1
# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16
# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720
# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1
# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1
# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2
# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4
# uncomment for composite PAL
#sdtv_mode=2
#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18
# Additional overlays and parameters are documented /boot/overlays/README
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
# Automatically load overlays for detected cameras
camera_auto_detect=1
# Automatically load overlays for detected DSI displays
display_auto_detect=1
# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2
# Disable compensation for displays with overscan
disable_overscan=1
[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1
[all]
[pi4]
# Run as fast as firmware / board allows
arm_boost=1
[all]
dtparam=i2c_vc=on
dtparam=i2c_arm=on
dtoverlay=arducam_64mp
dtoverlay=vc4-kms-v3d,cma-512
Hi guys, I have a similar problem too, where the 64MP camera randomly showing failed to allocate buffers error. I am running it on a Raspberry Pi 4 with 4 GB RAM btw.
From what I read on the previous reply it seems like maybe the Raspberry Pi is not powerful enough to run for the full 64 MP resolution.
So my questions,
Is anybody running this on a Raspberry Pi with 8 GB RAM? Are there still random failed to allocate buffers error?
Someone said lowering the resolution might work. Anybody here have a resolution suggestion that are highest but works stably?
Seems not related to RAM but GPU so the problem is the same whatever model you got (got a 2gb and 4gb)
That explains the lower resolution improves the capture. Try 1280x720
Arducam have updated the release to 0.0.9, but following github for this is awkward because there’s one “release” and cannot get notified. Do you have another way to get your updates notified?
By the way, tested 0.0.9 and now it captures 16MP by default, so you have to force 64MP with width and height. Log says preview leaks are fixed, but the buffer issue persist.