Making that change had no positive affect. The USB identifiers were correct. Here are the kernel logs:
[ 3.391748] usb 1-1.1: Product: USB PnP Sound Device
[ 3.419903] input: C-Media Electronics Inc. USB PnP Sound Device as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.1/1-1.1:1.3/0003:0D8C:013A.0001/input/input0
[ 3.519387] hid-generic 0003:0D8C:013A.0001: input,hidraw0: USB HID v1.00 Device [C-Media Electronics Inc. USB PnP Sound Device] on usb-0000:01:00.0-1.1/input3
[ 3.629105] usb 1-1.2: new full-speed USB device number 4 using xhci_hcd
[ 3.785750] usb 1-1.2: New USB device found, idVendor=0d8c, idProduct=013a, bcdDevice= 1.00
[ 3.794168] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3.801520] usb 1-1.2: Product: USB PnP Sound Device
[ 3.823090] input: C-Media Electronics Inc. USB PnP Sound Device as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:1.3/0003:0D8C:013A.0002/input/input1
[ 3.909308] hid-generic 0003:0D8C:013A.0002: input,hidraw1: USB HID v1.00 Device [C-Media Electronics Inc. USB PnP Sound Device] on usb-0000:01:00.0-1.2/input3
With that change, the nodes are now being randomly assigned to a sound card (switching at random when the service restarts, which is kind of fun).
No change in the nodes being able to transmit at the same time.
I am going to revert the change. At least previously the correct node was broadcasting from the correct card and was consistent. They just both couldnât play at the same time.
Reading more of the hardware documentation on the Pi 4 hardware, the power budget for the 4 USB ports on a Pi4B is 1200 mA, shared between the ports. When either the Pi or the USB ports go above power budget, they should log a kernel error message. I am not any such messages. Not totally dismissing this as the issue though as I donât know how the kernel of this build is compiled.
At this point, I am just going to go to two single radio/node servers. Its probably more ideal anyway since it removes a single point of failure for our two repeaters.
I shouldnât have an issue making the two servers work (Iâm a system admin / network engineer). Thanks for the document! I already have the second server setup in the ASL portal with a unique port. I will configure the NAT forwarding on the firewall once it arrives.
The good info in that doc is that it would accept the port number in the nodes section in rpt.conf. Its not there by default and I was hoping it would take it. Defining the nodes locally is a requirement as I canât have them resolving our public address via the DNS lookup. Our firewall wont allow the public IP to be connected from internally, it has to resolve to an internal address.
The additional .x before the : is invalid, did you remove that ?
Well, I can only submit to you that this format is not correct.
The way it looks to the software, they are both addressed as 1-1
And unpredictable issues are going to happen when they are.
lsusb
I canât tell you why this made no change unless you either did not reload/restart the software for the new settings to be active or you also have other issues.
But the other strange behavior makes this perfectly clear to me at this point.
Perhaps plug one into the other USB header so it can be 2-1
Yes, I removed everything after the . (changing it exactly like you stated, making the devstr just 1-1 and 1-2) and restarted the service (a few times).
The URIs would randomly flip between nodes when restarted in that configuration, adding a new issue.
The problem with audio not playing on both nodes at the same time still persisted with the change. I reverted back as the nodes properly assign their URI
Here is the output from LSUSB
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 0d8c:013a C-Media Electronics, Inc.
Bus 001 Device 003: ID 0d8c:013a C-Media Electronics, Inc.
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Strange how the kernel lists it as Bus 1, device 1.1 and 1.2 and lsusb as device 3 and 4âŚ
I changed the simpleusb configs to 1-3 and 1-4, same result as just removing the . and changing it to 1 and 2. Random assignment to the sound card, only audio from one card at a time.
I believe that there is a difference on a Pi4 with USB version types. But I never had one to test that local.
I still suggest putting one of these on the other USB header so it is addressed as 2-x:1.0
That is the format the software is expecting. No matter what the OS reports.
When the software was written, the Pi 4 was not among us yet.
There have been strange issues here and there with 4âs, but I have not read or herd anyone with his one.
But generally, I have seen issues when they are on the same header on 3/3bâs
Unknown causes. But not all of these chips in the sound fob are exactly the same.
So, we can wonder and try to work around them.
But the first number is the USB header and the second is device# on that header.
On a PI4, all 4 USB-A ports are on the same bus. The two blue ports next to the ethernet jack are, from top to bottom, 1.1 and 1.2. The two black ports on the side, from top to bottom, are 1.3 and 1.4.
Here are the kernel messages when I move Port 2 (the bottom blue port) to port 3 (the top black port).
[351227.513747] usb 1-1.2: USB disconnect, device number 4
[351230.626708] usb 1-1.3: new full-speed USB device number 5 using xhci_hcd
[351230.773228] usb 1-1.3: New USB device found, idVendor=0d8c, idProduct=013a, bcdDevice= 1.00
[351230.773236] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[351230.773243] usb 1-1.3: Product: USB PnP Sound Device
[351230.773249] usb 1-1.3: Manufacturer: C-Media Electronics Inc.
[351230.848050] input: C-Media Electronics Inc. USB PnP Sound Device as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.3/0003:0D8C:013A.0003/input/input2
[351230.916902] hid-generic 0003:0D8C:013A.0003: input,hidraw0: USB HID v1.00 Device [C-Media Electronics Inc. USB PnP Sound Device] on usb-0000:01:00.0-1.3/input3
If the software is expecting something on 1-2 or 2-1, its not going to happen on a Pi4 the way the bus architecture is laid out and the way the Beta 6 kernel is compiled.
Seems like something that should be logged as a bug in git for the beta release. With Pi4s being commonplace and the Pi 5 coming soon, its going to need to be addressed at some point as the supply of 3s and 3Bs becomes unavailable.
Just a thought⌠Either way, I think my 2 server move will be the solution.