SimpleUSB - device selected, associated USB device not found

AllStarLink
1

Hello,

I have a puzzling problem, for which a workaround has been found, but would like to understand the reason for the issue and a permanent fix.

I have a Shari PI3U running on a Lenovo M73 tiny computer. Works great, except for one little issue that was never encountered when the Shari was running on a Raspberry Pi. When powering up the computer, an error is encountered that a device has been selected, but the associated USB device not found. A work around was found at USB Device String not found. The solution works. If the text following devstr = is deleted in the simpleusb.conf file, and asterisk is restarted, the radio comes to life.

Looking for a permanent, proper solution to this. I created a systemd service which replaces the simpleusb.conf file with a clean copy at bootup, which works fine, but wondering about a real fix.

Any thoughts?

Regards,

Doug VE3XDB

2

So you're hitting an interesting problem with a subset of hardware we've seen where the Linux kernel seems to initialize USB hubs in random order. This makes the USB devstr field change potentially on every boot. What you're doing at boot time at the moment is probably the best solution to the problem. With the planned ASLA-based driver we're hoping to avoid this problem but using the current OSS kernel interface, the possibilities to make this "better" are limited at present.

3

Thank you for responding so quickly. By the way, if others are having difficulty, here is how I set up the systemd service.

Step 1. Edit simpleusb.conf, removing any text following devstr = Save the file as simpleusb.bak in /etc/asterisk

Step 2. Create the following bash script, and save it as /usr/local/bin/update_simpleusb.sh:

#!/bin/bash
cd /etc/asterisk || exit
cp simpleusb.bak simpleusb.conf

Step 3: Make the script executable.

   sudo chmod +x /usr/local/bin/update_simpleusb.sh

Step 4: Create the systemd service

To run the script at boot, you can create a systemd service. Create a new service file:

sudo nano /etc/systemd/system/update_simpleusb.service

Add the following content to the service file:

ini

[Unit]
Description=Update SimpleUSB Configuration

[Service]
Type=oneshot
ExecStart=/usr/local/bin/update_simpleusb.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Save the file as update_simpleusb.service

Step 5: Enable the service
To ensure the service runs at boot, enable it with the following command:

sudo systemctl enable update_simpleusb.service

Step 6: Reboot and Test
Reboot the system to test if the script runs at startup:

sudo reboot

After the system reboots, the script should execute automatically, changing to the /etc/asterisk directory and copying simpleusb.bak to simpleusb.conf without any prompts. You can check the status of the service to ensure it ran successfully:

sudo systemctl status update_simpleusb.service

This will show you the output and any errors if they occurred.

Hope this is helpful.

Regards,

Doug VE3XDB

4

I would suggest the following changes for this:

[Unit]
Description=Update SimpleUSB Configuration
Before=asterisk.service allmon3.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/update_simpleusb.sh
RemainAfterExit=no

[Install]
WantedBy=multi-user.target

You want this to run before asterisk.service and allmon3.service. Also since this terminates properly after its oneshot run successfully, having RemainAfterExit=yes is inappropriate for systemd.

Also, have you considered doing an inline edit rather than copying around a file? if you're always copying a file back into place, you're breaking the ability to reasonably use simpleusb-tune-menu or the susb command in Asterisk. You could do it in a one-liner like this:

sed -E 's/devstr=[^[:space:]]*/devstr=/g' /etc/asterisk/simpleusb.conf
5

Thanks for the suggestions! I like your approach because it doesn't mess with the simpleusb.conf file. I was trying to do what you suggested, but gave up and took the lazy approach. Thank you!

7

It didn't work, but spent some time trouble shooting, and found a spacing error in the sed command I was using. This one worked:

sudo sed -i.bak 's/^devstr *=.*/devstr =/' simpleusb.conf
8

Good afternoon, just checking in and wondering if this issue was ever resolved? I am going to be using the Lenovo for another node, running on Debian 12. Thanks!

9

We added a change that allows the devstr = with no value to persist in the file (unless/until you are using multiple interfaces).

We're also still working on moving away from OSS and towards ALSA. Whether that will help is still TBD.

10

Thank you, Allan. Much appreciated!

11

So...before I get off on my slight tangent on how ALSA will fix this; there is a way to solve this on OSS with a little bit of work. We can create a UDEV rule for the DAC that automatically symlinks it somewhere; or even over /dev/dsp if needed. Start by making sure you know what your DAC's address and device ID are: (Okay..it's not really an OSS thing but more a UDEV thing)

$lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0424:2514 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub
Bus 001 Device 003: ID 0424:2514 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub
Bus 001 Device 005: ID 0d8c:0012 C-Media Electronics, Inc. USB Audio Device
Bus 001 Device 006: ID 0424:7800 Microchip Technology, Inc. (formerly SMSC)
Bus 001 Device 008: ID 1fc9:0094 NXP Semiconductors OpenDM1701 Transceiver

As you can see...my C-Media is vendor ID 0d8c and product ID 0012.

sudo nano /etc/udev/rules.d/99-usb-dac.rules to make a new file and put this in it:

KERNEL=="dsp*", SUBSYSTEM=="sound", ATTRS{idVendor}=="0d8c", ATTRS{idProduct}== "0014", SYMLINK+="my_dac"

Making sure to replace the vendor id and product id with the one in your system. Now reload:

sudo udevadm control --reload-rules && sudo udevadm trigger

This will create a /dev/my_dac device that will track wherever it's plugged in. If for some reason things won't talk to an OSS device on a non-standard name:

SYMLINK+="dsp" instead of "my_dac" and it will grab the default device name.

Yes. ALSA provides a couple layers of abstraction compared to OSS. I have a USB DAC on my primary system....so it's location can change and some programs, like mpd, use a device specified in a conf. So my DAC might be hw:3,0 till something happens during a reboot and it becomes something different; this is basically what happens with OSS. However ALSA provides alternative device names:

$ cat /proc/asound/cards
0 [DAC ]: USB-Audio - SMSL USB DAC
SMSL SMSL USB DAC at usb-0000:06:00.3-3.2, high speed
1 [NVidia ]: HDA-Intel - HDA NVidia
HDA NVidia at 0xfc080000 irq 89
2 [Generic ]: HDA-Intel - HD-Audio Generic
HD-Audio Generic at 0xfc5c8000 irq 91
3 [Generic_1 ]: HDA-Intel - HD-Audio Generic
HD-Audio Generic at 0xfc5c0000 irq 92
4 [Receiver ]: USB-Audio - Dell HR024 Audio Receiver
MediaTek Inc Dell HR024 Audio Receiver at usb-0000:06:00.3-3.1.4, full speed

So instead my player can use hw:DAC and ALSA will always find it.

12

The current code, with the logic in place to find "the" USB audio device, we don't have any issues. Plug it in and we'll find it. Unplug from one port and move it to another and we'll still find it. The problem is when you have more than one ASL "supported" audio device plugged in. With built-in USB ports known to the device-tree, and assuming you don't change where you've plugged in your device, the naming tends to be consistent and we're good. But, add a few USB hubs into the mix and now you are at the mercy of USB device enumeration.

13

Okay...maybe I am misunderstanding where the enumeration breakdown is. Sounds like a udev rule will help.

I'm gonna have to poke around my asl3 node's OS more and look at some configs....I admit I haven't looked at how a lot of that is setup on the distribution.

14

Again, all is good with 1 device. Issues arise when you have more than 1 device and no way to distinguish between them.

p.s. we can also match devices by their USB serial number ... but most CM108's don't provide one.

15

Good afternoon,

I set up the node on the Lenovo m73 yesterday. and all went well.

Thank you for your effort to continuously improve the system! It is noticed and greatly appreciated.

Regards,

Doug VE3XDB