search

zynthian / zynthian-issue-tracking

Centralized Issue Tracking for Zynthian Project
https://github.com/orgs/zynthian/projects/1
11 stars 3 forks source link

Issue: HOTONE Jogg Audio Card not detected on startup. #1237

Closed michelemaroni closed 2 weeks ago

michelemaroni commented 1 month ago

Describe the issue

HOTONE Jogg Audio interface not available on startup

To Reproduce

Steps to reproduce the behavior:

  1. Power on the zynthian with the device attached.
  2. Neither aplay -l nor lsusb show the device in the list.
  3. Uplug and replug, the device becomes available.
  4. After that,zynthian-ui and service seems to normally start using jackd -P 70 -s -S -d alsa -d hw:Audio -r 48000 -p 256 -n 2 -X raw

    Expected behaviour

    The device should be detected, initialized, and activated on startup.

    Actual behaviour

    The device is not deteced and prevents zynthian-ui and serice from starting.

    Screenshots

On startup: image

After replugging: image

Manually configuring the device as audio interface with jackdcommand after replugging: image

Additional info

This behavior does not occurs using modep . The device properly starts once configured in the first login wizard.

Configuration

Hardware

Raspberry Pi 4 Model B Rev 1.5
Audio: Custom device
Display: WaveShare 3.5A
Wiring: DUMMIES
I2C: Not detected
Profile:

System

Debian GNU/Linux 12 (bookworm)
Build Date: 2024-09-11
Memory: 3% (281M/7809M)
SD Card: 32% (8.8G/29G)
Temperature: 66.2ºC
Overclock: None

MIDI & UI

Tuning: 440 Hz
Master Channel: Off
Preload Presets: On
ZS3 (SubSnapShots): On
Power Save: 10 minutes
Audio Levels on Snapshots: On

Software

zyncoder: oram (71de6d2) 
zynthian-ui: oram (bbc7246)
zynthian-sys: oram (a717e49)
zynthian-data: oram (ddfa009)
zynthian-webconf: oram (b530397)
riban-bw commented 1 month ago

It looks like the Jogg USB device is slow to appear. Maybe it has its own boot period which is slower than most, simple USB devices.

The jack2 service is configured to restart on failure every second. This quickly excedes the restarts permitted in the default period (5 in 5s). Once jack2 service has exceded this limit it stops attempting to restart. Zynthian is dependant on jack2 service, so it cannot operate. Extending the restart time to 2s does not significantly impact availability (zynthian's restart is 5s) and seems to resolve this issue because, when the USB device is available, jack2 finds it and starts then zynthian's next restart works. This may add a few seconds to startup if zynthian fails to start initially because of its 5s restart cycle. (We could probably reduce this to 2s.)

Try changing RestartSec=1 to RestartSec=2 in /etc/systemd/system/jack2.service then reboot.

I emulated the problem by depowering a USB attached audio card (UMC1820) during boot then powering after zynthian error screen shows. This seems to work.

Please report if this fixes the problem, or at least works around it. If so we could make these changes to the system so that your (cornercase) scenario is resolved.

riban-bw commented 1 month ago

I have implemented this fix in Vangelis (testing) which should fix @michelemaroni's problem and also makes zynthian more robust. It should now recover from more jack related issues.

michelemaroni commented 1 month ago

Thanks, I'll test it over the weekend and let you know the outcome.

michelemaroni commented 1 month ago

I can confirm that the issue is now fixed, at least for me.

Wanted to share some reflections/info.

I'd close this issue with one proposal: Would it be possible/useful to implement a graceful behavior in the zynthia ui in regards of the audio system?

1) The user specify and configure a valid audio interface as usual. 2) If the device is available zynthia starts normally, else it starts with a fallback device which could be also a null device. 3) At startup the user receives a warning about the inavailability of the main audio device and that the fallback device is being used. The warning could be combined/replaced with stamp-like message in the zynthian mixer.

Thank you for fixing this!

riban-bw commented 1 month ago

Reopening to track through to release. (Currently only resolved in testing.)

There is a different development that is looking at hotplug audio. I will considered your suggestions in that development.