Pi-top [3] A311D upgrade : Libre Computer Alta (Cottonwood series)

pi-top [3]
#1

Moving the discussion here from the “Pi-top [3] RK3399 upgrade” thread to prevent it being completely derailed.

This thread is for you if :

  • You’re fed up with the relatively slow processing speed and low amount of RAM of the Raspberry Pi 3B+ and would like to actually be able to daily drive your pi-top [3] as desktop / laptop

  • You’d like to replace the Raspberry Pi 3B+ in your pi-top [3] with minimal effort and still be able to receive good quality OEM / community support

  • You want to avoid your pi-top [3] becoming e-waste

At long last we have a suitable candidate for upgrading the pi-top [3] !
The Alta SBC from Libre Computer is the same physical form factor as the Raspberry Pi 3B+ and is thus a drop-in replacement for it in the pi-top [3] : the USB, Ethernet, HDMI and 3.5mm A / V ports all line up correctly with the pi-top’s hub and keyboard / battery USB connectors.
It’s also not outrageously priced and even performs pretty competitively with the Raspberry Pi 5 !

There are currently some teething issues, which @butonic is in the process of solving. I can’t recommend enough reading through their I2C pull request on Libre Computer’s Github (and helping out with it if you can !). I dream of the day when I understand anything like enough to be able to help resolve that issue but hopefully I can at least help draw more attention to it.

Libre Computer has an upstream / mainline-first policy, which - if I’ve understood correctly - means long term you actually become less reliant on them as the OEM and enables you to benefit from the latest kernels supported on your chipset. With the open source firmware Libre Computer has contributed for their ARM-based SBCs, you should just be able to download any distro’s aarch64 image and run it on those SBCs, rather than having to rely on Libre Computer to ship their own specifically-crafted image. This should open up a wide range of distros : Fedora, NixOS, Guix SD, Debian, Arch etc. - you can even run Raspberry Pi OS !

The main things you will find missing compared with Raspberry Pi 3B+ are Wi-Fi and Bluetooth but you can deal with that by using suitable dongles (e.g. https://ryf.fsf.org/categories/wireless-adapters https://hub.libre.computer/t/realtek-wifi-drivers/57 and https://ryf.fsf.org/categories/bluetooth-adapters).

I have been looking quite some time now for a suitable drop-in solution for upgrading the pi-top [3] and have engaged with various solutions that were less viable (see my contributions on this forum to relevant threads !) than this and am really glad that Libre Computer in particular has brought this to the table. I still like the CM4 to RPi3B+ adapter / carrier board from Waveshare because it enables testing of the latest CM4 form factor compute modules, e.g. the RISC-V based Mars CM from Milk-V, but it only has USB2.0, not USB3.0, and is quite a squeeze in the pi-top [3] chassis because the B2B connectors are on the underside of the Waveshare board.

I look forward to seeing this community’s experiences with the Alta in this thread and really hope that this proves especially useful for school IT labs.

Disclaimer : I have no connection with Libre Computer other than as the close relative of a new, paying consumer. The views expressed here are my own and I am happy to be corrected / make corrections if / where I’ve made a mistake / misunderstood.

N.B. Where I refer to “OEM” here, I am referring to Libre Computer as the OEM of the Alta SBC, not pi-top as the OEM of the pi-top [3].

#2

I will repeat here a few of the salient points from the RK3399 thread:

As the end user, the only physical intervention you should need to make to the Alta when it arrives, is to gently tease the heatsink off the CPU and RAM (be careful as it’s stuck on quite firmly with adhesive tape), otherwise you won’t be able to connect the Cooling Bridge from the Alta’s GPIO pins to the B2B connector on the pi-top [3]'s hub.

I have not yet tried this assembly with an eMMC fitted beneath the Libre Computer so it’s possible that might change things.

If you’re interested in other Libre Computer SBCs, I think their “Le Potato” and “Solitude” boards might be compatible with the pi-top [3] and I would have expected the “Renegade” to be as well, however user @joeykork mentioned that it didn’t quite fit correctly.
I suppose their “Tritium” model also ought to fit but I don’t really know why one would choose it over the Alta…

Bret Weber has done a review, comparing it to the RPi4B+ (https://bret.dk/libre-computer-alta-review-big-cottonwood/ ) and ShotokuTech is doing a couple of YT videos on it (the first one is here: https://redirect.invidious.io/watch?v=ojFgY-4Aofs - be sure to check out the comments for relevant information as well). It has SPI flash so it would be interesting to see Tow-Boot ported to run on the Alta.
Further benchmarks are available in Bret Weber’s comparison with the RPi5 here: https://bret.dk/raspberry-pi-5-review/ - pretty interesting stuff! Especially if you wanted a solar-battery-powered cryptominer SBC…
The A311D already features on a few other manufacturers’ SBCs (Khadas, Radxa, BananaPi…), which means it should be pretty well known in the community. It’s 12nm process vs. the RPi3B+'s 40nm so it should be quite a lot more efficient and it’s up to 2GHz hexacore vs the RPi3B+'s up to 1.4GHz quadcore. Also, the Alta has 4xUSB3.0 vs. the RPi3B+'s 4xUSB2.0 and it has 4Gb RAM vs the latter’s 1Gb RAM. The Alta also has eMMC storage and NPU support.
On the Libre Computer forum, it states: “The board offers industry-leading 1W idle power consumption and can be flexibly powered by USB Type-C, Power over Ethernet, or 5V header directly” so, unless I’ve got completely confused, I take the “5V header” to mean via the GPIOs? Bret Weber’s review has a hardware comparison table, in which under “Power Input” it states: “Power via GPIO Header”

So what that all translates to is: the Alta should turn your pi-top [3] into a long term, actually daily-driveable laptop, on which you can properly use general purpose Linux desktop OSes. No more OOM when opening more than 1 tab in Firefox-ESR - heck, you’ll actually be able to use full fat Firefox! Actually able to have more than one program open at a time etc. It should be a massive leap up from the RPi3B+!

Two other YouTubers who are covering the Alta are MakerMind Nexus (whose video was recommended by Libre Computer on Twitter / X ) and Frank Davis (https://redirect.invidious.io/channel/UCJVqlG6s4sc7a6ltLZXumjQ).

A v5.1 eMMC should be faster than a microSD but I would still use a microSD for storage or testing a different OS from that stored on the eMMC. You could also use a nano USB flash drive for additional storage (which is why having USB3.0 instead of USB2.0 is so important).
If you have to choose between two media, where one is faster than the other, I can’t remember whether you’re supposed to have: the OS on the faster one and /home (all your photos, documents etc.) on the slower one, or the other way round?

No one else has yet come up with a laptop form factor that neatly contains within its body an SBC bay, battery, speaker, breadboard and protoboard that you can use to learn, then write and finally actually field test code! It’s such a neat configuration, I really don’t get why pi-top let it fall by the wayside…

#3

On the subject of cooling, it would seem that the RPi3B+'s TDP is max. 7W, whereas the A311D’s is max. 15W - however the latter obviously benefits from a smaller die process and more, faster cores and RAM across which to spread loads.

Khadas has the A311D quick reference manual available here : https://dl.khadas.com/hardware/vim3/datasheet/a311d_quick_reference_manual_01_wesion.pdf

#4

Regarding horizontal screen flickering. I moved the AML-A311D-CC into a different pi-top[3] to check if the flickering persisted (and because the battery seems to be disconnected in the one my son is using). It still flickers, so I think we can rule out problems with the pi-top[3] hardware. To rule out the AML-A311D-CC I replaced it as well (I have three pi-top[3] & three AML-A311D-CC). Same flickering. For now. I will assume the hardware is working as designed.

Which leaves us with a software problem. What does the kernel say about the video anyway?

$ uname -a
Linux raspbian-bullseye-arm64 6.1.74-12781-g74961fb0a5d2 #1 SMP PREEMPT_DYNAMIC Wed Jan 24 02:05:32 EST 2024 aarch64 GNU/Linux
$ sudo dmesg | egrep -i "midgard|panfrost|drm|vpu|gpu|meson|mali"
[    0.043033] platform ff900000.vpu: Fixed dependency cycle(s) with /soc/bus@ff600000/hdmi-tx@0/port@0/endpoint
[    0.045347] platform cvbs-connector: Fixed dependency cycle(s) with /soc/vpu@ff900000/port@0/endpoint
[    1.617856] irq_meson_gpio: 100 to 8 gpio interrupt mux initialized
[    1.634443] soc soc0: Amlogic Meson G12B (A311D) Revision 29:b (10:2) Detected
[    1.663293] meson-sm: secure-monitor enabled
[    1.664947] meson-saradc ff809000.adc: Looking up vref-supply from device tree
[    1.747043] ff803000.serial: ttyAML0 at MMIO 0xff803000 (irq = 16, base_baud = 1500000) is a meson_uart
[    3.196161] meson-drm ff900000.vpu: Queued 2 outputs on vpu
[    3.203042] meson8b-dwmac ff3f0000.ethernet: IRQ eth_wake_irq not found
[    3.207765] meson8b-dwmac ff3f0000.ethernet: IRQ eth_lpi not found
[    3.213974] meson8b-dwmac ff3f0000.ethernet: PTP uses main clock
[    3.220291] meson8b-dwmac ff3f0000.ethernet: User ID: 0x11, Synopsys ID: 0x37
[    3.226901] meson8b-dwmac ff3f0000.ethernet:         DWMAC1000
[    3.232064] meson8b-dwmac ff3f0000.ethernet: DMA HW capability register supported
[    3.239479] meson8b-dwmac ff3f0000.ethernet: RX Checksum Offload Engine supported
[    3.246895] meson8b-dwmac ff3f0000.ethernet: COE Type 2
[    3.252068] meson8b-dwmac ff3f0000.ethernet: TX Checksum insertion supported
[    3.259055] meson8b-dwmac ff3f0000.ethernet: Wake-Up On Lan supported
[    3.265482] meson8b-dwmac ff3f0000.ethernet: Normal descriptors
[    3.271306] meson8b-dwmac ff3f0000.ethernet: Ring mode enabled
[    3.277081] meson8b-dwmac ff3f0000.ethernet: Enable RX Mitigation via HW Watchdog Timer
[    3.299493] meson-dw-hdmi ff600000.hdmi-tx: Looking up hdmi-supply from device tree
[    3.324383] meson-dw-hdmi ff600000.hdmi-tx: Detected HDMI TX controller v2.01a with HDCP (meson_dw_hdmi_phy)
[    3.328786] meson-dw-hdmi ff600000.hdmi-tx: registered DesignWare HDMI I2C bus driver
[    3.336430] meson-drm ff900000.vpu: bound ff600000.hdmi-tx (ops meson_dw_hdmi_ops)
[    3.344006] [drm] Initialized meson 1.0.0 20161109 for ff900000.vpu on minor 0
[    3.982249] meson-drm ff900000.vpu: [drm] fb0: mesondrmfb frame buffer device
[    4.341979] dwc3-meson-g12a ffe09000.usb: Looking up vbus-supply from device tree
[    4.341995] dwc3-meson-g12a ffe09000.usb: Looking up vbus-supply property in node /soc/usb@ffe09000 failed
[    4.342116] dwc3-meson-g12a ffe09000.usb: USB2 ports: 2
[    4.342171] dwc3-meson-g12a ffe09000.usb: USB3 ports: 1
[    4.560894] meson-gx-mmc ffe07000.mmc: Looking up vmmc-supply from device tree
[    4.561641] meson-gx-mmc ffe05000.mmc: Looking up vmmc-supply from device tree
[    4.561918] meson-gx-mmc ffe05000.mmc: Looking up vqmmc-supply from device tree
[    4.562178] meson-gx-mmc ffe05000.mmc: Got CD GPIO
[    4.568215] meson-gx-mmc ffe07000.mmc: Looking up vqmmc-supply from device tree
[    4.571259] meson-gx-mmc ffe07000.mmc: allocated mmc-pwrseq
[    4.600881] genirq: Setting trigger mode 3 for irq 27 failed (meson_gpio_irq_set_type+0x0/0x70)
[    4.904967] meson-vrtc ff8000a8.rtc: registered as rtc0
[    4.907940] meson-vrtc ff8000a8.rtc: setting system clock to 1970-01-01T00:00:04 UTC (4)
[    4.931288] panfrost ffe40000.gpu: clock rate = 24000000
[    4.947336] panfrost ffe40000.gpu: Looking up mali-supply from device tree
[    4.947354] panfrost ffe40000.gpu: Looking up mali-supply property in node /soc/gpu@ffe40000 failed
[    4.947378] panfrost ffe40000.gpu: error -ENODEV: _opp_set_regulators: no regulator (mali) found
[    4.953490] panfrost ffe40000.gpu: mali-g52 id 0x7212 major 0x0 minor 0x0 status 0x0
[    4.959659] panfrost ffe40000.gpu: features: 00000000,00000cf7, issues: 00000000,00000400
[    4.967222] panfrost ffe40000.gpu: Features: L2:0x07110206 Shader:0x00000000 Tiler:0x00000809 Mem:0x1 MMU:0x00002830 AS:0xff JS:0x7
[    4.978954] panfrost ffe40000.gpu: shader_present=0x3 l2_present=0x1
[    4.988909] [drm] Initialized panfrost 1.2.0 20180908 for ffe40000.gpu on minor 1
[    6.851525] systemd[1]: Starting Load Kernel Module drm...
[    7.000503] systemd[1]: modprobe@drm.service: Succeeded.
[    7.000928] systemd[1]: Finished Load Kernel Module drm.
[    7.873343] rc rc0: meson-ir as /devices/platform/soc/ff800000.bus/ff808000.ir/rc/rc0
[    7.874553] rc rc0: lirc_dev: driver meson-ir registered at minor = 0, raw IR receiver, no transmitter
[    7.880540] input: meson-ir as /devices/platform/soc/ff800000.bus/ff808000.ir/rc/rc0/input5
[    7.892632] meson-ir ff808000.ir: receiver initialized
[    8.022273] meson_vdec: module is from the staging directory, the quality is unknown, you have been warned.
[    8.962121] meson8b-dwmac ff3f0000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[    9.160474] meson8b-dwmac ff3f0000.ethernet eth0: PHY [mdio_mux-0.0:00] driver [RTL8211F Gigabit Ethernet] (irq=20)
[    9.168437] meson8b-dwmac ff3f0000.ethernet eth0: No Safety Features support found
[    9.168457] meson8b-dwmac ff3f0000.ethernet eth0: PTP not supported by HW
[    9.168664] meson8b-dwmac ff3f0000.ethernet eth0: configuring for phy/rgmii link mode

How is the display connected?

$ xrandr --verbose
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 1920 x 1920
Composite-1 unknown connection primary (normal left inverted right x axis y axis)
        Identifier: 0x40
        Timestamp:  9158
        Subpixel:   unknown
        Clones:
        CRTCs:      0
        Transform:  1.000000 0.000000 0.000000
                    0.000000 1.000000 0.000000
                    0.000000 0.000000 1.000000
                   filter:
        link-status: Good
                supported: Good, Bad
        CONNECTOR_ID: 32
                supported: 32
        non-desktop: 0
                range: (0, 1)
  720x576i (0x43) 13.500MHz Interlace
        h: width   720 start  732 end  795 total  864 skew    0 clock  15.62KHz
        v: height  576 start  580 end  586 total  625           clock  50.00Hz
  720x480i (0x44) 13.500MHz Interlace
        h: width   720 start  739 end  801 total  858 skew    0 clock  15.73KHz
        v: height  480 start  488 end  494 total  525           clock  59.94Hz
HDMI-1 connected 1920x1080+0+0 (0x45) normal (normal left inverted right x axis y axis) 1214mm x 683mm
        Identifier: 0x41
        Timestamp:  9158
        Subpixel:   unknown
        Gamma:      1.0:1.0:1.0
        Brightness: 1.0
        Clones:
        CRTC:       0
        CRTCs:      0
        Transform:  1.000000 0.000000 0.000000
                    0.000000 1.000000 0.000000
                    0.000000 0.000000 1.000000
                   filter:
        EDID:
                00ffffffffffff003873000000000000
                0d1a0103a37944961eee91a3544c9926
                0f505420000001010101010101010101
                010101010101293680a070381f403020
                350000000000001e011d007251d01e20
                6e285500beab4200001e000000fc004e
                43532048444d492020202020000000fd
                0018780c9a22000a202020202020010a
                020319c1469004052213142309040783
                01000065030c001000011d8018711c16
                20582c2500beab4200009e011d801871
                382d40582c4500beab4200001e011d00
                bc52d01e20b8285540beab4200001e01
                1d80d0721c1620102c2580beab420000
                9e000000000000000000000000000000
                0000000000000000000000000000001d
        max bpc: 0
                range: (8, 8)
        link-status: Good
                supported: Good, Bad
        CONNECTOR_ID: 34
                supported: 34
        non-desktop: 0
                range: (0, 1)
  1920x1080 (0x45) 138.650MHz +HSync +VSync *current +preferred
        h: width  1920 start 1968 end 2000 total 2080 skew    0 clock  66.66KHz
        v: height 1080 start 1083 end 1088 total 1111           clock  60.00Hz
  1920x1080 (0x46) 148.500MHz +HSync +VSync
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock  67.50KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  60.00Hz
  1920x1080 (0x47) 148.352MHz +HSync +VSync
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock  67.43KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  59.94Hz
  1920x1080i (0x48) 74.250MHz +HSync +VSync Interlace
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock  33.75KHz
        v: height 1080 start 1084 end 1094 total 1125           clock  60.00Hz
  1920x1080i (0x49) 74.250MHz +HSync +VSync Interlace
        h: width  1920 start 2448 end 2492 total 2640 skew    0 clock  28.12KHz
        v: height 1080 start 1084 end 1094 total 1125           clock  50.00Hz
  1920x1080 (0x4a) 74.250MHz +HSync +VSync
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock  33.75KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  30.00Hz
  1920x1080i (0x4b) 74.176MHz +HSync +VSync Interlace
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock  33.72KHz
        v: height 1080 start 1084 end 1094 total 1125           clock  59.94Hz
  1920x1080 (0x4c) 74.176MHz +HSync +VSync
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock  33.72KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  29.97Hz
  1280x720 (0x4d) 74.250MHz +HSync +VSync
        h: width  1280 start 1390 end 1430 total 1650 skew    0 clock  45.00KHz
        v: height  720 start  725 end  730 total  750           clock  60.00Hz
  1280x720 (0x4e) 74.250MHz +HSync +VSync
        h: width  1280 start 1720 end 1760 total 1980 skew    0 clock  37.50KHz
        v: height  720 start  725 end  730 total  750           clock  50.00Hz
  1280x720 (0x4f) 74.176MHz +HSync +VSync
        h: width  1280 start 1390 end 1430 total 1650 skew    0 clock  44.96KHz
        v: height  720 start  725 end  730 total  750           clock  59.94Hz

Lets try that other mode 1920x1080 (0x46) at 148.500MHz:

$ xrandr --output HDMI-1 --mode 0x46

Oh, nice! No more flickering AFAICT … ah … I saw a flicker! But waaaaaay less. To the point where I am satisfied and would declare this usable.

Let us make the mode permanent. We can convert the xrandr mode to a modeline for the xorg.conf:

Modeline "1920x1080_pitop"  148.50  1920 2008 2052 2200  1080 1084 1089 1125 +HSync +VSync

To make this permanent:

$ sudo vi /etc/X11/xorg.conf.d/10-monitor.conf
Section "Monitor"
        Identifier      "HDMI-1"
        Option "Primary" "true"
        # Modeline "1280x1024"  MHz  HSize HTotal HSyncEnd HSyncDelay  VSize VSyncStart VSyncEnd VTotal -hsync +vsync
        Modeline "1920x1080_pitop"  148.50 1920 2008 2025 2200  1080 1084 1089 1125 +hsync +vsync
        Option "PreferredMode" "1920x1080_pitop"
EndSection

After rebooting or reloading X xrandr now tells us that that mode is our preferred mode:

$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 1920 x 1920
HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 1214mm x 683mm
   1920x1080_pitop  60.00*+
   1920x1080     60.00 +  60.00    59.94    30.00    29.97
   1920x1080i    60.00    50.00    59.94
   1280x720      60.00    50.00    59.94
Composite-1 unknown connection (normal left inverted right x axis y axis)
   720x576i      50.00
   720x480i      59.94

Next up: audio.

1 Like
#5

Really nice work @butonic ! I’d particularly like to thank you for taking the time to show in detail the debugging steps you took.

I see you were using Raspbian Bullseye with an X11-based WM, which leads me to wonder whether you would consider testing what the display output is like with a Wayland-based WM?
Forgot to add: presumably later we could try those other modes (0x47), (0x4a) and (0x4c) just for elimination purposes?

I’m afraid I haven’t yet got to flashing the latest firmware but it’s already abundantly clear from your work here that your knowledge and understanding go way beyond my own!

RE audio: From https://hub.libre.computer/t/alta-aml-a311d-cc-audio-issues-dummy-output-and-no-sound/3488/15 some users have got HDMI audio to work using commands provided by Libre Computer but those users don’t yet seem to have got 3.5mm audio to work. Fortunately, Libre Computer just replied half an hour ago that “We are preparing new images to be released in a week. They should fix the audio issue for the new boards.”

#6

Yes, I am testing using the official Raspbian Bullseye image … but I admit I very much prefer armbian. But I wanted to have the official libre.computer cli tools to test if I can get the i2c bus to connect to the hub. No luck so far.

I did test the other modes as well:

  • 1920x1080 (0x45) 138.650MHz +HSync +VSync is what is used without any changes. I have flickering with this.
  • 1920x1080 (0x46) 148.500MHz +HSync +VSync works for me without flickering and I made it the preferred modeline (explicity named 1920x1080_pitop) for xorg by providing the custom 10-monitor.conf above.
  • 1920x1080 (0x47) 148.352MHz +HSync +VSync worked without flickering as well. I wouldn’t know how decide which of these lines to use. And pointers welcome.
  • 1920x1080i (0x48) 74.250MHz +HSync +VSync Interlace makes the screen go white in this ‘overbleeding’ fashion, if that is a word. I did not try any other interlaced modes.
  • 1920x1080 (0x4a) 74.250MHz +HSync +VSync same garbage.
  • 1920x1080 (0x4c) 74.176MHz +HSync +VSync same garbage.

Regarding firmare: libre.computer announced a new firmare in the sound thread due the next week. :crossed_fingers:

Regarding audio:

aplay picks pulseaudio by default (LC_ALL=C just makes aplay talk english):

$ LC_ALL=C aplay /usr/share/sounds/alsa/Front_Center.wav -v
Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate: 48000 Hz, mono
ALSA <-> PulseAudio PCM I/O Plugin
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 24000
  period_size  : 6000
  period_time  : 125000
  tstamp_mode  : NONE
  tstamp_type  : GETTIMEOFDAY
  period_step  : 1
  avail_min    : 6000
  period_event : 0
  start_threshold  : 24000
  stop_threshold   : 24000
  silence_threshold: 0
  silence_size : 0
  boundary     : 6755399441055744000

But there are other devices:

$ aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
default
    Playback/recording through the PulseAudio sound server
lavrate
    Rate Converter Plugin Using Libav/FFmpeg Library
samplerate
    Rate Converter Plugin Using Samplerate Library
speexrate
    Rate Converter Plugin Using Speex Resampler
jack
    JACK Audio Connection Kit
oss
    Open Sound System
pulse
    PulseAudio Sound Server
upmix
    Plugin for channel upmix (4,6,8)
vdownmix
    Plugin for channel downmix (stereo) with a simple spacialization
hw:CARD=LCALTA,DEV=0
    LC-ALTA,
    Direct hardware device without any conversions
hw:CARD=LCALTA,DEV=1
    LC-ALTA,
    Direct hardware device without any conversions
hw:CARD=LCALTA,DEV=2
    LC-ALTA,
    Direct hardware device without any conversions
plughw:CARD=LCALTA,DEV=0
    LC-ALTA,
    Hardware device with all software conversions
plughw:CARD=LCALTA,DEV=1
    LC-ALTA,
    Hardware device with all software conversions
plughw:CARD=LCALTA,DEV=2
    LC-ALTA,
    Hardware device with all software conversions
sysdefault:CARD=LCALTA
    LC-ALTA,
    Default Audio Device
dmix:CARD=LCALTA,DEV=0
    LC-ALTA,
    Direct sample mixing device
dmix:CARD=LCALTA,DEV=1
    LC-ALTA,
    Direct sample mixing device
dmix:CARD=LCALTA,DEV=2
    LC-ALTA,
    Direct sample mixing device
usbstream:CARD=LCALTA
    LC-ALTA
    USB Stream Output

Trying the plughw ones I can hear sound via headphones using

$ LC_ALL=C aplay --device="plughw:CARD=LCALTA,DEV=1" /usr/share/sounds/alsa/Front_Center.wav -v
Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate: 48000 Hz, mono
Plug PCM: Hardware PCM card 0 'LC-ALTA' device 1 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 24000
  period_size  : 6000
  period_time  : 125000
  tstamp_mode  : NONE
  tstamp_type  : MONOTONIC
  period_step  : 1
  avail_min    : 6000
  period_event : 0
  start_threshold  : 24000
  stop_threshold   : 24000
  silence_threshold: 0
  silence_size : 0
  boundary     : 6755399441055744000
  appl_ptr     : 0
  hw_ptr       : 0

It does not seem 100% centered and a little off to the left, but maybe that is just me.

pulseaudio does not even seem to see the alsa device:

$ pacmd list-sinks
1 sink(s) available.
  * index: 0
        name: <alsa_output.platform-sound.stereo-fallback>
        driver: <module-alsa-card.c>
        flags: HARDWARE DECIBEL_VOLUME LATENCY
        state: SUSPENDED
        suspend cause: IDLE
        priority: 9000
        volume: front-left: 65536 / 100% / 0,00 dB,   front-right: 65536 / 100% / 0,00 dB
                balance 0,00
        base volume: 65536 / 100% / 0,00 dB
        volume steps: 65537
        muted: no
        current latency: 0,00 ms
        max request: 0 KiB
        max rewind: 0 KiB
        monitor source: 0
        sample spec: s16le 2ch 44100Hz
        channel map: front-left,front-right
                     Stereo
        used by: 0
        linked by: 0
        fixed latency: 59,95 ms
        card: 0 <alsa_card.platform-sound>
        module: 6
        properties:
                alsa.resolution_bits = "16"
                device.api = "alsa"
                device.class = "sound"
                alsa.class = "generic"
                alsa.subclass = "generic-mix"
                alsa.name = ""
                alsa.id = "fe.dai-link-0 (*)"
                alsa.subdevice = "0"
                alsa.subdevice_name = "subdevice #0"
                alsa.device = "0"
                alsa.card = "0"
                alsa.card_name = "LC-ALTA"
                alsa.long_card_name = "libre_computer-aml_a311d_cc-"
                alsa.driver_name = "snd_soc_meson_axg_sound_card"
                device.bus_path = "platform-sound"
                sysfs.path = "/devices/platform/sound/sound/card0"
                device.form_factor = "internal"
                device.string = "hw:0"
                device.buffering.buffer_size = "10576"
                device.buffering.fragment_size = "2648"
                device.access_mode = "mmap"
                device.profile.name = "stereo-fallback"
                device.profile.description = "Stereo"
                device.description = "Internes Audio Stereo"
                module-udev-detect.discovered = "1"
                device.icon_name = "audio-card"
        ports:
                analog-output: Analog Output (priority 9900, latency offset 0 usec, available: unknown)
                        properties:

        active port: <analog-output>

I wonder how we can change the alsa.subdevice :eyes:

#7

Ok, we can change the default card device to 1 by creating:

$ cat /etc/asound.conf
defaults.pcm.device 1
defaults.ctl.device 1

Not that I wrote card device. Most examples chinge the default card by setting defaults.(pcm|ctl).card but we nood to change the device!

Then we kill and restart pulseaudio to make it pick up the new alsa config:

$ pulseaudio -k
$ pulseaudio -D

Now I have audio via headphones by default!

So for me Video and Audio are fixed. I should be able to configure them just as well in armbian and then hand over the machines to my kids.

I worry about battery lifetime and would love to get i2c to the hub running. That would also allow cleaner shutdowns AFAICT. Again, any pointers welcome.

But that is polish, to be honest. First, I’ll look into running minetest mineclonia on the machines, because that is a huge upgrade over the current minecraft pi reborn they are stuck with.

1 Like
#8

Very nice! So you had to sort out the alsa and pulseaudio configs but would it be any easier in Pipewire?
What’s your coding background, @butonic? I’m really envious of how in your debugging workflow you know exactly where to look, what to look for and which incantations to use to get there haha

@pi-topMIKE @duwudi would you be willing to advise on the following?

#9

15 Years ago, we ran a computerlab based on gentoo for the software engineering research group I worked for. At the time I also ran gentoo on my personal laptop and had to fiddle with the drivers until it would properly hibernate, get hw supported video and 3d working. I learned a lot during that time. Two weeks after everything was working the next Ubuntu release came out and everything was working OOTB, so I switched.

When I started working at ownCloud I switched to debian and debbuged the hell out of PHP scripts. Maybe for 7 years I had the opportunity to debug very different systems to make them play nice with each other. I think three years ago we moved to go for oCIS and that caused the time I spent on debugging to shift towards microservices and kubernetes.

I guess it boils down to me being a professional debugger :wink: To me it is like solving puzzles. It should work, so why doesn’t it? What got me hooked on open source was that I could read the code to see what it was doing.

My basic routine is:

  • find an error string in a log (software, services, dmesg, anywhere … try to filter by time, getting console logs for SoC is sometimes hard - but I rarely needed to look into JTAG)
    • try to google the best match
    • sometimes the results lead to a straigt forward fix
    • sometimes google comes up empty, then try github (google does not find everything there)
    • still nothing? try to identify the software that is failing see if they have any other communication channels
  • not even any errors? try triggering the error and see if you can reproduce it somehow.
  • try raising loglevels for related software and reproduce the error
  • talk to the forum, or the devs! <- this is gold, but show that you did the all the above research

Regarding pipewire: I don’t know the new kids on the block :man_shrugging:

1 Like
#10

Nice experience and very good advice - thank you! That should be pinned to the top of every tech forum lol.
Sounds like you had some seriously useful and widely applicable troubleshooting experience. Your experience with PHP and Kubernetes (Go?) reminds me of some ycombinator posts I was reading through earlier - do you have any experience with Oberon-related languages?

I don’t know whether it’s taboo to mention the fork since you’re at ownCloud but do you cross paths with Nextcloud much? If yes, have you met Brent Gervais?

RE I2C: Does this post help at all?

Nevermind RE Pipewire, I’d just understood from Jupiter Broadcasting that it was replacing Pulseaudio etc.

#11

do you have any experience with Oberon-related languages?

nope, still busy sharpening my go skills

I don’t know whether it’s taboo to mention the fork since you’re at ownCloud but do you cross paths with Nextcloud much? If yes, have you met Brent Gervais?

I’m fine talking about NC and know the old core developers but haven’t met Brent. The fork hurt, but I did meet some of them on conferences. I have the feeling that NC keeps pushing for new features. We are trying to iterate on the core functionality and turn oCIS into a data platform. With PHP it is hard to make the system robust against misbehaving apps, as they basically run in process. With oCIS we went the microservice route. If an app is eating all your CPU you can scale it if necssary or just limit the amount of CPU time the thumbnailer gets etc…

RE I2C: Does this post help at all?

Partly. It gave me an idea how to enable i2c 1-4 … but none of them show the pi hub. I created this post but havent seen a response, yet.

1 Like
#12

Right! Fascinating - I had superficially looked into the differences between ownCloud and Nextcloud but I definitely wasn’t aware of that difference! Yes, NC seem to be implementing the ability to self-host LLMs on your NAS. So are you implementing microservices with Wasm?
Brent Gervais co-hosts some shows on Jupiter Broadcasting and has been organising meetups in Berlin but he comes across as quite a troubleshooter/bug finder, like yourself, so I figured it could be interesting to meet.

Hmm that’s a bit perplexing and yeah I saw your post, would be great if someone would reply but Chinese New Year’s only just come to an end so maybe something will be forthcoming from Libre Computer.
I saw this in the Radxa forum, not sure if it helps at all but it seemed relevant: https://forum.radxa.com/t/radxa-zero-3w-mraa-no-pins/20078

Apropos Pipewire, itsfoss just published a brief article on how it differs from Pulseaudio, Fedora Magazine has a more detailed explainer (centred around Wireplumber) from Fedora 35*, baeldung has a quick and simple to follow guide on replacing Pulseaudio with Pipewire on your system and there’s a Wireplumber GUI available as a GPLv3 licensed Flatpak on Flathub.
However, I would be surprised if Pipewire wasn’t already running by default on your Alta’s Raspbian install because, according to RPi Documentation:

“The PipeWire backend was introduced in Bookworm. PulseAudio was used in older versions of Rasperry Pi OS.”

*the comments beneath the Fedora Magazine article are also worth reading through

Obligatory link to Arch’s wiki entry on Wireplumber.

#13

Shoutout here to those who attend the Cambridge Raspberry Jam (“CamJam”) - saw you’re using quite a few pi-top CEEDs at the event so would be grateful to hear your experiences if you choose to try a Libre Computer Alta in place of a RPi in those!

#14

Great pieces of information were shared, I enjoyed reading this.

#15

@butonic I highlighted your Github pull request for I2C to Tomeu Vizoso here, hoping for some advice to advance it:

#16

I got this reply:

“I unfortunately don’t remember much about I2C (has been quite a few years), but I think you could try asking in #linux-amlogic on Libera.Chat. Or on the mailing list: http://lists.infradead.org/mailman/listinfo/linux-amlogic”

#17

Further Khadas documentation on their VIM3 is available here. Their forum also has a thread about using hardware encoder on A311D and A311D2.

Might be worth seeing what the MNT Reform community has already troubleshot with the BananaPi A311D CM they’re using: https://community.mnt.re/t/tracking-known-issues-and-solutions-with-the-bpi-a311d-upgrade/1682

#18

And if anyone wants to try NixOS, hans311 in the Libre Computer forum has this advice:

"Hi, I installed nixos on alta aml-a311d using an image of nixos 23.11 in Hydra - Latest builds for job nixos:release-23.11:nixos.sd_image.aarch64-linux.

Choose one which has been processed successfully. I expect it to work on the newest boards. Flash it to an SD and boot the SBC. The u-boot starts this one up based on extlinux configuration file in the fat32 partition."

#19

Official Libre Computer advice on NixOS:
"Nix’s ARM64 images should work on all of our boards.

For boards like Le Potato and Tritium and Renegade without SPI firmware, just use libretech-flash-tool to flash the bootloader onto the image (or use dd with the bootloader file from boot.libre.computer/ci. It should work as long as it’s not GPT partitioning. If it is GPT partitioning, we recommend splitting the bootloader device and the GPT disk."

#20

Reposting here what Luke Lu has replied to your I2C thread in the Libre Computer forum:

" hi, sorry for late reply…

We’ve submitted a patch[1] to enable i2c2 for Alta, tested with i2c device connected

so, can you give it a try? thanks

[1] aml-a311d-cc: enable i2c-2 controller · libre-computer-project/libretech-wiring-tool@771185a · GitHub"