ORAM: after last updates, very slow snapshot loading

Software
1

I noticed that after last updates of ORAM, my V4 kit

  • takes long time to load snapshots
    during the loading on screen shows “restoring MIDI capture state”
  • some snapshots sometimes have a silent chain

Here the UI log of loading:

Jun 01 13:59:52 zynthian startx[937]: WARNING:zynthian_gui_brightness_config.init_ctrls: Can’t set display brightness!
Jun 01 14:01:54 zynthian startx[937]: WARNING:zynthian_gui.busy_thread_task: Clients have been busy for longer than 30s: {‘load snapshot’, ‘add_processor’, ‘set_chain_state’}
Jun 01 14:01:54 zynthian startx[937]: ERROR:zynthian_engine.start: Can’t start engine Jalv/MIDI Velocity Adjust => Timeout exceeded.
Jun 01 14:01:54 zynthian startx[937]: <pexpect.pty_spawn.spawn object at 0x7fa53f81d0>
Jun 01 14:01:54 zynthian startx[937]: command: /usr/local/bin/jalv
Jun 01 14:01:54 zynthian startx[937]: args: [‘/usr/local/bin/jalv’, ‘-n’, ‘MIDI_Velocity_Adjust-01’, ‘x42 MIDI Filter Collection’]
Jun 01 14:01:54 zynthian startx[937]: buffer (last 100 chars): b’Plugin: x42 MIDI Filter Collection’
Jun 01 14:01:54 zynthian startx[937]: before (last 100 chars): b’Plugin: x42 MIDI Filter Collection’
Jun 01 14:01:54 zynthian startx[937]: after: <class ‘pexpect.exceptions.TIMEOUT’>
Jun 01 14:01:54 zynthian startx[937]: match: None
Jun 01 14:01:54 zynthian startx[937]: match_index: None
Jun 01 14:01:54 zynthian startx[937]: exitstatus: None
Jun 01 14:01:54 zynthian startx[937]: flag_eof: False
Jun 01 14:01:54 zynthian startx[937]: pid: 1240
Jun 01 14:01:54 zynthian startx[937]: child_fd: 59
Jun 01 14:01:54 zynthian startx[937]: closed: False
Jun 01 14:01:54 zynthian startx[937]: timeout: 30
Jun 01 14:01:54 zynthian startx[937]: delimiter: <class ‘pexpect.exceptions.EOF’>
Jun 01 14:01:54 zynthian startx[937]: logfile: None
Jun 01 14:01:54 zynthian startx[937]: logfile_read: None
Jun 01 14:01:54 zynthian startx[937]: logfile_send: None
Jun 01 14:01:54 zynthian startx[937]: maxread: 2000
Jun 01 14:01:54 zynthian startx[937]: ignorecase: False
Jun 01 14:01:54 zynthian startx[937]: searchwindowsize: None
Jun 01 14:01:54 zynthian startx[937]: delaybeforesend: 0
Jun 01 14:01:54 zynthian startx[937]: delayafterclose: 0.1
Jun 01 14:01:54 zynthian startx[937]: delayafterterminate: 0.1
Jun 01 14:01:54 zynthian startx[937]: searcher: searcher_re:
Jun 01 14:01:54 zynthian startx[937]: 0: re.compile(b’\n> ‘)
Jun 01 14:02:17 zynthian startx[937]: ERROR:zynthian_engine.proc_cmd: Can’t exec engine command: set 4 127.000000 => End Of File (EOF). Exception style platform.
Jun 01 14:02:17 zynthian startx[937]: <pexpect.pty_spawn.spawn object at 0x7fa53f81d0>
Jun 01 14:02:17 zynthian startx[937]: command: /usr/local/bin/jalv
Jun 01 14:02:17 zynthian startx[937]: args: [’/usr/local/bin/jalv’, ‘-n’, ‘MIDI_Velocity_Adjust-01’, ‘x42 MIDI Filter Collection’]
Jun 01 14:02:17 zynthian startx[937]: buffer (last 100 chars): b’’
Jun 01 14:02:17 zynthian startx[937]: before (last 100 chars): b’kShmReadWritePtr - Init not done for -1, skipping unlock\r\nerror: Failed to connect to audio system\r\n’
Jun 01 14:02:17 zynthian startx[937]: after: <class ‘pexpect.exceptions.EOF’>
Jun 01 14:02:17 zynthian startx[937]: match: None
Jun 01 14:02:17 zynthian startx[937]: match_index: None
Jun 01 14:02:17 zynthian startx[937]: exitstatus: None
Jun 01 14:02:17 zynthian startx[937]: flag_eof: True
Jun 01 14:02:17 zynthian startx[937]: pid: 1240
Jun 01 14:02:17 zynthian startx[937]: child_fd: 59
Jun 01 14:02:17 zynthian startx[937]: closed: False
Jun 01 14:02:17 zynthian startx[937]: timeout: 30
Jun 01 14:02:17 zynthian startx[937]: delimiter: <class ‘pexpect.exceptions.EOF’>
Jun 01 14:02:17 zynthian startx[937]: logfile: None
Jun 01 14:02:17 zynthian startx[937]: logfile_read: None
Jun 01 14:02:17 zynthian startx[937]: logfile_send: None
Jun 01 14:02:17 zynthian startx[937]: maxread: 2000
Jun 01 14:02:17 zynthian startx[937]: ignorecase: False
Jun 01 14:02:17 zynthian startx[937]: searchwindowsize: None
Jun 01 14:02:17 zynthian startx[937]: delaybeforesend: 0
Jun 01 14:02:17 zynthian startx[937]: delayafterclose: 0.1
Jun 01 14:02:17 zynthian startx[937]: delayafterterminate: 0.1
Jun 01 14:02:17 zynthian startx[937]: searcher: searcher_re:
Jun 01 14:02:17 zynthian startx[937]: 0: re.compile(b’\n> ')
Jun 01 14:02:17 zynthian startx[937]: WARNING:zynthian_autoconnect.audio_autoconnect: Port ‘Tal-Reverb-III-01:lv2_audio_out_1’ not available
Jun 01 14:02:17 zynthian startx[937]: WARNING:zynthian_autoconnect.audio_autoconnect: Port ‘Tal-Reverb-III-01:lv2_audio_out_2’ not available
Jun 01 14:02:17 zynthian startx[937]: WARNING:zynthian_autoconnect.audio_autoconnect: Port ‘Tal-Reverb-III-01:lv2_audio_out_1’ not available
Jun 01 14:02:18 zynthian startx[937]: WARNING:zynthian_autoconnect.audio_autoconnect: Port ‘Tal-Reverb-III-01:lv2_audio_out_2’ not available
Jun 01 14:02:24 zynthian startx[937]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! =>count: 1, delay: 39995328.0us

Raspberry Pi 4 Model B Rev 1.4
Audio: HifiBerry DAC+ ADC PRO
Display: ZynScreen 3.5 (v1)
Wiring: MCP23017_ZynScreen
I2C: MCP23017@0x20
Profile: v4_stage

SYSTEM

Debian GNU/Linux 12 (bookworm)
Build Date: 2024-03-01
Memory: 11% (890M/7810M)

SOFTWARE

zyncoder: oram (d25a811)
zynthian-ui: oram (675ba53)
zynthian-sys: oram (85d7598)
zynthian-data: oram (db0355a)
zynthian-webconf: oram (24fb89e)

1 Like
2

Same behaviour on my Zynthian V4. Removing a plugin, and it took a rather long time to reconnect the audio connections.

3

this afternoon I tried to use Zynthian at church but unfortunately it was a disaster because Zynthian loaded almost always incomplete snapshots

I believe that something bad happened during last updated: I decided to reflash te OS

4

I have discovered that adding the -S parameter to jackd to set it to run in synchronous mode causes massive delays (10s of seconds) for each jack client to connect. @jofemodo We need to remove the -S parameter from jackd config and revert to asyncronous mode (with its additional period of latency) until we identify what is causing this issue.

[Edit] I have fixed some of this by stopping zynthian jack clients from attempting to start the jackd service if it detects it is not running. (There seems to be some conflict that causes this issue.) What we should actually do is to set environmental variable JACK_NO_START_SERVER which will tell all jack clients to not do this. @jofemodo I did not find a sensible place to set this other than in all the zynthian_envars_Vx.sh scripts. I have pushed these changes and hopefully this resolves the problem. @jofemodo please validate the changes are sensible.

4 Likes
5

There seem to be some issues still.
With a simple plugin combination (source is internet radio plugin) and any plugin in between.

First of all some really crucial delay, especially when removing plugins (> 40s), if I am removing a plugin. The sound stops immediately, but the re-organizing takes it’s time. You can watch the build-up of the chains in patchage, and it’s slooowww. After all patching is done, it takes another time that the sound re-appears again.

Second issue: If I use a gain plugin in pre-fader position in the main audio chain (output chain), the
audio seems to be bypassed, if the gain is set to -40. This is not observed if plugin is in post-fader position.

1 Like
6

Agreed! It’s not fixed. We will sort it soon …

1 Like
7

it seems fixed with
zyncoder: oram (b5c87b7)
zynthian-ui: oram (e351b84)
zynthian-sys: oram (ce896ec)
zynthian-data: oram (db0355a)
zynthian-webconf: oram (c27fea2)

thanks

2 Likes
8

Yes, this has been fixed with some attention to the way we handle jackd. There are some undocumented features and unexpected interactions that we had to understand and work around but it seems to be more robust and a little faster than before so this was worth the detour.

1 Like
9

Hm, I’ve updated to

the above branches, and zynthian-ui to
zynthian-ui: oram (c030c6c)

I reboot and bummer…
it’s hanging in a dead loop while restoring states. In Webconf I deleted last_state.zss to be shure to have a clean system. Webconf is accessible, ssh too, VNC shows in patchage that all plugins are loaded, but no audio connections are established - thus hanging in restoring state dead lock.

Am I the only one having this issue? should I reburn and update the SD card again? It’s all after the last update :frowning:

10

Hi @gitnob !

How do you updated the system?
What is your audio configuration and hardware?

Regards

11

It’s a regular V4 Zynthian, audio configuration like V4 standard setting, updated via webconf update. Until this afternoon,when I updated the last time, system was working normal, the evening I’ve updated to the actual version (s.above), then I got this dead lock. Zyn screen shows loading of plugins into chain, then when restoring mixer, the zyn-screen does not go any further.
Webconf, ssh is working fine, But on VNC I see no connection establishing in patchage.

12

Try updating again, please.

13

I’ll do it in some hours not at my zynthian ATM.
till then, thanks anyway