Annoyance Bug in CM108 PTT sanity check when USB VID:PID is not a C-Media device

[skuep]

I know this should never happen, because there are only C-Media devices out there that can be used with the CM108 PTT option.

Not anymore! The AIOC now has preliminary CM108 support. See this Release: https://github.com/skuep/AIOC/releases/tag/v1.2.0-rc.1

It works quite well! However these two warnings are reported by direwolf.

    Warning: USB audio card 5 (AllInOneCable) is not a device known to work with GPIO PTT.
    ....
    ioctl HIDIOCGRAWINFO failed for /dev/hidraw13. errno = 0.

The first one is fine for me. The second one (repeats with every assertion/deassertion of the PTT) however seems to be a bug with jumbled up if/else clauses here: https://github.com/wb2osz/direwolf/blob/7d3c1d100ea38605bf5d11459f5a678be99fffab/src/cm108.c#L817-L829

I would expect the second warning to be

    USB audio card 5 (AllInOneCable) is not a supported device type.  Proceed at your own risk. ....

This warning seems annoying and redundant (it already says so on direwolf startup), it clutters the direwolf log window. Maybe get rid of this message?

Thanks for all the work that went into direwolf. Thanks a bunch!

[wb2osz]

Thanks for inventing such a useful gadget which makes the wiring so tidy. I don't have one of the devices for testing, but I found this:

https://github.com/skuep/AIOC/blob/master/stm32/aioc-fw/Src/usb_descriptors.h

define USB_VID 0x1209

define USB_PID 0x7388

The fix should be to simply add that to GOOD_DEVICE in direwolf/src/cm108,c. This has been pushed to the dev branch.

I agree, the if nesting doesn't look right. I need to ponder that some more.

Questions for you: (1) do you use the same gpio number as all the other interfaces? If not I could put in a different default gpio number for this device. (2) What do you get for owner, group, and permissions of the HID?
For a CMedia chip, I originally saw something like this which ordinary users could not access. crw------- 1 root root ,... /dev/hidraw1 I added something to /etc/udev/rules.d so it is also accessible by audio group. crw-rw---- 1 root audio ..... /dev/hidraw1 Ordinary users that can access the sound part can access the HID part.

[skuep]

Sorry I forgot including the VID/PID in my post, I didn't think you'd be willing to add those :-) I think the error messages that come with each PTT assertion is what bugged me the most.

(1) Yeah, totally CM108 compatible (2) crw------- 1 root root, same as the CMedia chip. I was thinking of adding the udev rule to my README at some point, but feel free to add them to yours as well :-)

[wb2osz]

SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="7388", GROUP="audio", MODE="0660"

Do you use the same ptt gpio number as everyone else? If not, I could set a different default for this device.

[skuep]

Udev Rule is looking good, thanks a lot!

Yes, same GPIO number! After all, it already works with Direwolf, just these error messages look awkward. :-)

uint8_t pttMask = (gpio & 0x04 ? PTT_MASK_PTT1 : 0) |
                  (gpio & 0x08 ? PTT_MASK_PTT2 : 0);

This is currently the mask check for PTT1 (Bit 2) (and PTT2 (Bit 3) if available).

[kx1t]

Has this been implemented? And if so, from which version/release? I am using DireWolf 1.6 from the Debian repo and I am still seeing this error with the AIOC device

(Ha - then the next question would be, when will the Debian repo be updated with the latest, but I guess that should go in a different Issue)

Thnx, kx1t

# apt-cache showpkg direwolf
Package: direwolf
Versions: 
1.6+dfsg-3 (/var/lib/apt/lists/deb.debian.org_debian_dists_bookworm_main_binary-arm64_Packages.lz4) (/var/lib/dpkg/status)
...

[dranch]

The Direwolf 1.7 release versions is already uploaded into both Debian unstable (testing branch) and the future Debian Trixie /13 release which due out in 2025. It's unlikely Direwolf will be backported to say Debian Bookworm / 12 due to the standard Debian packaging process and timelines. If you want the newer code now, you need to either find either a PPA (private repo) or someone else's compiled version or better yet, just build it yourself. Compiling Direwolf is not hard to do and is documented in both the Direwolf User Guide and many other docs on the Internet.

Beyond that, the above USB recognition changes are not done in Direwolf but in the udev system to better recognize unknown USB devices with already supported internals. If you browse the Linux USB VID:PID database ( https://usb-ids.gowdy.us/read/UD/1209 ) , 1209:7388 isn't known yet. T vendor of the AIOC device needs to submit some basic details to get it added which also isn't hard. One the basic details are uploaded, it will take time for this information to make it into various code bases like the Linux kernel, etc. but until then, adding that support is as simple as the steps mentioned above. Give it a try and if you have issues, feel free to join the direwolf@groups.io list for support.

[wb2osz]

The AIOC device is fully supported in release 1.7. I have an AIOC device here. The cm108 utility reports:

VID  PID   Product                          Sound                  ADEVICE        ADEVICE            HID [ptt]
---  ---   -------                          -----                  -------        -------            ---------

1209 7388 All-In-One-Cable /dev/snd/pcmC4D0c plughw:4,0 plughw:AllInOneCable,0 /dev/hidraw2 1209 7388 All-In-One-Cable /dev/snd/pcmC4D0p plughw:4,0 plughw:AllInOneCable,0 /dev/hidraw2 ** 1209 7388 All-In-One-Cable /dev/snd/controlC4 /dev/hidraw2

Note the ** which means it is supported for USB audio device PTT.

Here is a configuration file to test it:

ADEVICE plughw:4,0 MYCALL WB2OSZ-14 CHANNEL 0 PTT CM108 OBEACON objname="Santa C" delay=0:05 every=0:5 symbol=snowmobile lat=42^37.14N long=071^20.78W comment="Ho Ho Ho" KISSPORT 0 AGWPORT 0

It works as expected. No complaints.

Building from source is easy. You should uninstall the package first so you don't have both installed at the same time.

73, John WB2OSZ