Refresh when Pipewire or ALSA is up #59

Closed
opened 1 year ago by mitinarseny · 3 comments

This is my yambar config for ALSA module:

bar:
  right:
    - alsa:
        card: default
        mixer: Master
        content:
          map:
            on-click: amixer -q sset Master toggle
            tag: muted
            values:
              true: {string: {text: '', font: *awesome}}
              false:
                list:
                  spacing: 4
                  items:
                    - map:
                        tag: percent
                        default: {string: {text: '', font: *awesome}}
                        values:
                          0: {string: {text: '', font: *awesome}}
                    - string: {text: '{percent}%'}

I have following lines in the end of my wayland compositor config (river):

pipewire &
yambar &

However, as I assume, when yambar is started, pipewire is not already fully loaded (I actually do not know internals of Pipewire and ALSA). So when the yambar is started, it does not recognise the card, so the volume is 0%. But then pipewire is loaded, and nothing changes! I can even change my volume with amixer, but it never changes in bar. The problem goes away if I kill the bar and start it again.

This is my yambar config for ALSA module: ```yaml bar: right: - alsa: card: default mixer: Master content: map: on-click: amixer -q sset Master toggle tag: muted values: true: {string: {text: '', font: *awesome}} false: list: spacing: 4 items: - map: tag: percent default: {string: {text: '', font: *awesome}} values: 0: {string: {text: '', font: *awesome}} - string: {text: '{percent}%'} ``` I have following lines in the end of my wayland compositor config ([river](https://github.com/ifreund/river)): ```sh pipewire & yambar & ``` However, as I assume, when yambar is started, pipewire is not already fully loaded (I actually do not know internals of Pipewire and ALSA). So when the yambar is started, it does not recognise the card, so the volume is 0%. But then pipewire is loaded, and nothing changes! I can even change my volume with `amixer`, but it never changes in bar. The problem goes away if I kill the bar and start it again.
dnkl commented 1 year ago
Owner

This is a classical daemon/service dependency issue. As is custom on Linux, it is really up to the user/system to ensure that service A has started before service B, if B depends on A.

Normally, you'd let the system's service manager (be that systemd, openrc, s6, 66, or whatever) deal with this (I use a custom s6 service directory for my Sway session, and it starts yambar, fnott, foot etc, with correct dependencies).

That said, there are a couple of alternatives I think. One is to add a sleep between pipewire and yambar. To prevent river from stalling, put everything in a wrapper script and call that wrapper script from river.

I'm not familiar with the pipewire suite. But looks like maybe you can use context.exec to launch yambar? Or maybe there's a way to use pw-cli to busy-wait until pipewire is up, and then launch yambar?

In any case, this isn't something that yambar can, or should do.

This is a classical daemon/service dependency issue. As is custom on Linux, it is really up to the user/system to ensure that service A has started before service B, if B depends on A. Normally, you'd let the system's service manager (be that systemd, openrc, s6, 66, or whatever) deal with this (I use a custom s6 service directory for my Sway session, and it starts yambar, fnott, foot etc, with correct dependencies). That said, there are a couple of alternatives I think. One is to add a sleep between `pipewire` and `yambar`. To prevent river from stalling, put everything in a wrapper script and call that wrapper script from river. I'm not familiar with the pipewire suite. But looks like maybe you can use `context.exec` to launch yambar? Or maybe there's a way to use `pw-cli` to busy-wait until `pipewire` is up, and then launch yambar? In any case, this isn't something that yambar can, or should do.
dnkl closed this issue 1 year ago
dnkl added the
invalid
label 1 year ago
Poster

Ok, I agree with you. What do you think about implementing "reload" of yambar on SIGUSR1, for example? It can be usefull in those cases, when I do not know what services I am going to start, but I explicitly list all of their pairticles in yambar config, so there should be a mechanism to tell yambar to update itself.

Ok, I agree with you. What do you think about implementing "reload" of yambar on SIGUSR1, for example? It can be usefull in those cases, when I do not know what services I am going to start, but I explicitly list all of their pairticles in yambar config, so there should be a mechanism to tell yambar to update itself.
mitinarseny reopened this issue 1 year ago
dnkl commented 1 year ago
Owner

Reloading the configuration in this way is near impossible with yambar's current architecture. It just wasn't designed for this.

Without rewriting large parts of yambar, we'd have to do more or less a full reboot of yambar - tear down everything, reload the configuration, re-create the bar and all the modules and particles and start up again. If you're going to send a signal to yambar, it might just as well be SIGINT or SIGTERM, followed by a manual restart of yambar.

I can keep this issue open, if you like, and will accept patches sent my way, but can't really see myself implementing it.

Reloading the configuration in this way is near impossible with yambar's current architecture. It just wasn't designed for this. Without rewriting large parts of yambar, we'd have to do more or less a full reboot of yambar - tear down everything, reload the configuration, re-create the bar and all the modules and particles and start up again. If you're going to send a signal to yambar, it might just as well be `SIGINT` or `SIGTERM`, followed by a manual restart of yambar. I can keep this issue open, if you like, and will accept patches sent my way, but can't really see myself implementing it.
dnkl added
enhancement
help wanted
and removed
invalid
labels 1 year ago
dnkl closed this issue 10 months ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.