Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mention a workaround for the PipeWire #63

Open
nmsv opened this issue Nov 27, 2023 · 11 comments
Open

Mention a workaround for the PipeWire #63

nmsv opened this issue Nov 27, 2023 · 11 comments

Comments

@nmsv
Copy link

nmsv commented Nov 27, 2023

The readme states that PipeWire doesn't work without the patch, but there's another workaround.
Defining alsa sinks and sources manually allows you to use the PipeWire.
In pipewire.conf there's an example for source:

    # This creates a single PCM source device for the given
    # alsa device path hw:0. You can change source to sink
    # to make a sink in the same way.
    #{ factory = adapter
    #    args = {
    #        factory.name           = api.alsa.pcm.source
    #        node.name              = "alsa-source"
    #        node.description       = "PCM Source"
    #        media.class            = "Audio/Source"
    #        api.alsa.path          = "hw:0"
    #        api.alsa.period-size   = 1024
    #        api.alsa.headroom      = 0
    #        api.alsa.disable-mmap  = false
    #        api.alsa.disable-batch = false
    #        audio.format           = "S16LE"
    #        audio.rate             = 48000
    #        audio.channels         = 2
    #        audio.position         = "FL,FR"
    #    }
    #}

So you can have a sink (and hence some sound) by adding a few lines beside it:

    { factory = adapter
        args = {
            factory.name           = api.alsa.pcm.sink
            node.name              = "alsa-sink"
            node.description       = "PCM Sink"
            media.class            = "Audio/Sink"
            api.alsa.path          = "hw:0" # or whatever device number you have in your alsamixer
            api.alsa.period-size   = 1024
            api.alsa.headroom      = 0
            api.alsa.disable-mmap  = false
            api.alsa.disable-batch = false
            audio.format           = "S16LE"
            audio.rate             = 48000
            audio.channels         = 2
            audio.position         = "FL,FR"
        }
    }

Unmuting the device every reboot is also a thing that is required. You can nicely do it in the same config just below in the context.exec section:

context.exec = [
    # ...
    { path = "/usr/bin/amixer" args = "set -q -c 0 Master 100 unmute" }
]

Not the prettiest workaround, but I think it's worth mentioning.

@asimovc
Copy link

asimovc commented Jun 28, 2024

This works with bluetooth too?

@xplshn
Copy link

xplshn commented Jun 29, 2024

This works with bluetooth too?

Nope, it does not. ALSA is crap. And you'll have to set your Bluetooth output as your default sink with Bluealsa-tools

@nmsv
Copy link
Author

nmsv commented Jul 1, 2024

This works with bluetooth too?

Yes, but alsa is not used in this case, pipewire works with bluez directly. No workaround required for that.

@xplshn
Copy link

xplshn commented Jul 1, 2024

This works with bluetooth too?

Yes, but alsa is not used in this case, pipewire works with bluez directly. No workaround required for that.

Bluetooth would work, except not with this workaround, it will if he uses the patch instead of the cfg workaround.

@nmsv
Copy link
Author

nmsv commented Jul 1, 2024

It works for me with the workaround and without it (without the patch in both cases).

@xplshn
Copy link

xplshn commented Jul 1, 2024

It works for me with the workaround and without it (without the patch in both cases).

Oh, when did it start working? I should probably start using libudev-zero again then it seems. I had issues with it in the past, but I kept this project in my watchlist in case such issues were resolved...

@nmsv
Copy link
Author

nmsv commented Jul 1, 2024

It works for me with the workaround and without it (without the patch in both cases).

Oh, when did it start working? I should probably start using libudev-zero again then it seems. I had issues with it in the past, but I kept this project in my watchlist in case such issues were resolved...

For me bluetooth worked without an issue on multiple machines from since the day I got pipewire installed ...until recently I should say. A year ago or so I had to finally switch to wireplumber and I had to disable couple of plugins (like libcamera) to prevent it from crashing.

@xplshn
Copy link

xplshn commented Jul 1, 2024

If not wireplumber, then what are you using?

@nmsv
Copy link
Author

nmsv commented Jul 1, 2024

If not wireplumber, then what are you using?

Previously it was pipewire-media-session or something like that. This thingy actually caused me less headache than wireplumber.

@xplshn
Copy link

xplshn commented Jul 1, 2024

If not wireplumber, then what are you using?

Previously it was pipewire-media-session or something like that. This thingy actually caused me less headache than wireplumber.

Ah. I see. The workaround did nothing then, since it is for Wireplumber, not pipewire-media-session. Which is a deprecated reference implementation. I'm guessing you are on Debian or some other distro like that?

@nmsv
Copy link
Author

nmsv commented Jul 1, 2024

The alsa workaround is for pipewire.conf and not wireplumber.conf, so it worked for both. The disabling of the plugins is for wireplumber only. I'm using Alpine, which has unpatched pipewire in the repos AFAIK.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants