Jump to content

axel

Members
  • Posts

    3
  • Joined

  • Last visited

Reputation Activity

  1. Like
    axel reacted to 李松錡 in A cheap UAC 1.0 in to UAC 2.0 out converter that allows your PS5, switch, etc to use high end speakers   
    Hi, I would like to share my recent work: a cheap USB Audio Class 1.0 (UAC) input to UAC 2.0 output converter.
     
    For folks that may not understand why I have this crazy idea, here is the background:
    For some shitty reasons, PS5 does not support outputting audio through certain USB sound card, and that is because PS5 only supports very old USB sound card (UAC 1.0), and usually high end speakers or sound cards would use newer, better UAC 2.0 protocol.
    So, this shitty thing happens to me, when I thought my EDIFIER S880 speaker would be a plus for my gaming experience. EDIFIER S880 has a UAC 2.0 in input source, so my PS5 does not support that. So, what I can do is to use another 3.5 jack to connect the speaker to my PS5.
    Unfortunately, there is a staticky buzz sound throughout this channel. What's even worse is that EDIFIER S880 has 6 input source selection, but I can only switch to the next source, wait for 2 seconds, and repeat this process 5 times every time I want to switch the audio from my computer to the PS5.
     
    After lots of trials and flashing my custom kernel, I finally did it!
    The idea is to use a board that has 1 USB otg port to act as a UAC 1.0 sound card, and has another 1 USB host port to connect to the UAC 2.0 speakers, then run programs on that board to redirect sound from USB otg port to USB host port. It is even a plus that the board consumes less power, so we do not need an extra or special power supply for it; this becomes crucial, especially when sharing the same USB connection with the USB otg port (SBC boards are more power-hungry these days!). The standard USB 2.0 protocol only allows 5V 0.5A to the device connected.
    I actually built one with an Orange Pi One board, but it turns out that the CPU is not fast enough, and there are sound glitches sometimes.
     
    With some research, I found this board that perfectly fits my needs: Radxa zero 3W. Here is the advantage:
    - It is cheap, and the one I used is the nearly minimum SKU (1 GB ram with 8 GB onboard eMMC, they also have no onboard eMMC SKU).
    - The otg port could handle USB PD protocol, meaning no special hacks are needed, you could get at most 30W of power, if needed (and turns out the normal USB 2.0 port on my PS5 works perfectly, so I guess it consumes less than 5V 1A = 5W)
    - It is tiny.
     
    However, things don't work right out of the box. At the beginning, I flashed the official, latest Radxa OS, modprobe the g_audio. It is running as a UAC 2.0 device, so it is not the one I want. As a result, I grabbed their kernel source, changed the config to UAC 1.0 gadget, and flashed onto the board, but there seems to be some issues in their kernel fork for UAC 1.0 driver: there was no /dev/snd/controlC0, so the g_audio failed to run.
    As a result, I turned to use the Armbian build. This time, the /dev/snd/pcmC0D0c is missing, so g_audio failed to run again.
    I then compiled my own kernel, flashed it onto the board. The Armbian build is with kernel 6.1, and the kernel I built is kernel 6.12, then the board failed to boot to the kernel due to U-Boot thought there were some errors.
    Luckily, I found that building the whole Armbian image with kernel 6.12 can boot without issues, so I built a custom kernel 6.12 with UAC 1.0 enabled image, modeprobe the g_audio module, and it finally worked!
     
    After that, I crafted a simple golang SystemV daemon for bootstrapping and terminating the alsaloop program for redirecting the sound, and used a udev rule to notify that daemon of the attachment/detachment of the USB speaker out event. The converter is finally working!
     
    Here is the pre-built image for folks who want a quick test. It is based on the commit b27c86e620dcd9f55daadf52ccc85643dba2a381 from the armbian build repo with the following config modification:
    diff --git a/config/kernel/linux-rockchip64-current.config b/config/kernel/linux-rockchip64-current.config index d053d0997..6e360bba7 100644 --- a/config/kernel/linux-rockchip64-current.config +++ b/config/kernel/linux-rockchip64-current.config @@ -3507,3 +3507,8 @@ CONFIG_RATIONAL_KUNIT_TEST=m CONFIG_MEMCPY_KUNIT_TEST=m CONFIG_TEST_MEMCAT_P=m CONFIG_MEMTEST=y + +CONFIG_USB_CONFIGFS_F_UAC1=y +CONFIG_USB_CONFIGFS_F_UAC2=n +CONFIG_USB_F_UAC2=n +CONFIG_GADGET_UAC1=y  
    Currently, the "current" build does not detect the Wi-Fi interface, but as it does not affect the audio converting feature, I may not put too much effort into this.

  2. Like
    axel reacted to ValdikSS in AICSEMI AIC8800 supports WPA3-SAE, but not 256-bit ciphers   
    In case anyone wondering, AIC8800D80 found in Raxda Zero 3W and Radxa Cubie A5E (aic8800 driver) supports WPA3 SAE, but not GCMP/GCMP-256 ciphers.
     
    root@radxa-zero3:~# iw phy Wiphy phy0 wiphy index: 0 max # scan SSIDs: 3 max scan IEs length: 200 bytes max # sched scan SSIDs: 0 max # match sets: 0 Retry short limit: 7 Retry long limit: 4 Coverage class: 0 (up to 0m) Device supports RSN-IBSS. Device supports AP-side u-APSD. Supported Ciphers: * WEP40 (00-0f-ac:1) * WEP104 (00-0f-ac:5) * TKIP (00-0f-ac:2) * CCMP-128 (00-0f-ac:4) * CMAC (00-0f-ac:6) * WPI-SMS4 (00-14-72:1) Available Antennas: TX 0 RX 0 Supported interface modes: * managed * AP * AP/VLAN * monitor * mesh point * P2P-client * P2P-GO * P2P-device …  
    > get_capability pairwise CCMP TKIP > get_capability group CCMP TKIP WEP104 WEP40 > get_capability key_mgmt NONE IEEE8021X WPA-EAP WPA-PSK WPA-EAP-SUITE-B OWE DPP FT-PSK FT-EAP > get_capability proto RSN WPA > get_capability auth_alg OPEN SHARED LEAP SAE  
  3. Like
    axel got a reaction from hartraft in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    It's really nice to see all these recent community efforts to revive and keep the Helios64 alive and useful.
    However, the relevant info seems to be a bit all over the place.
     
    For instance, with the device tree files (dtb files). Which one is the "latest" one? How do you know which one to use for your current kernel? Where should you download it? (as an attachment to a user post on this forum?) Are they going to be merged as part of regular Armbian?
    These questions are not that hard to answer if you read through the topics and have some technical knowledge, but that's sort of the problem!
     
    Essentially, it would be great to start making things a bit more organised so people don't have to piece the information together from various forum posts
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines