Delay with pipewire

[pzant]

Describe the bug projectM have ~2 sec delay with pipewire

Desktop:

• Application: libpipewire 0.3.66
• OS: Linux 6.0.10
• Version 3.1.12

Additional context If using a helvum to pass the stream except the alsa analog monitor directly from the source to projectM then delay disappears

[kblaschke]

Could you please test this with the rewritten SDL frontend and tell us if that issue is still present there?

Also please check if setting a specific audio driver for libSDL, e.g. using export SDL_AUDIODRIVER=pipewire and other values like pulseaudioor alsa, makes a difference.

In addition to that, the version of your local libSDL2 would be relevant, as SDL only added direct pipewire support in version 2.0.16, previous versions would use a different driver which may incur additional delays.

[pzant]

@kblaschke great, works fine but take incorrect monitor, always take sink but not monitor in my case:

• In default take microphone.
• SDL_AUDIODRIVER=pipewire take alsa analog stereo
• SDL_AUDIODRIVER=alsa take microphone
• SDL_AUDIODRIVER=pulseaudio take microphone I'm tested it in the sandbox but i don't sink it has any effect. Why it's not pushed in upstream, when are you planning to release? Also this setup don't make 100% load cpu if window is not focused and placed on another workspace in wayland.

[kblaschke]

Not sure what "upstream" means here. I've released a development build from an early dev version, which was stable enough for people to use it. There was more work being down since then, but the frontend currently lacks any UI or feedback, making it very hard to use.

My current focus is on the core library, getting it as Milkdrop-compatible as possible. To elaborate, there will be three releases, probably in this order:

• The 4.0 version of the core library, with a whole new programming interface and some bugfixes.
• The 4.1 version of the core library, with a new expression parser (supporting megabuf, loop etc.) and a rewritten rendering system - this is what I'm working on currently.
• The 2.0 version of the SDL frontend application.

The frontend is now a separate application, no longer part of the core library to make it easier to release both at a different pace, as internal changes to the library without visible stuff for the user (e.g. new API functions or a different rendering backend) may confuse people.

On Wayland, it may not work really well because Wayland uses EGL, while projectM only supports GLX rendering for now. This may change in the future when libSDL 3 is stable and we have implemented EGL and Vulkan rendering backends in projectM, which we'll probably release as version 5.0.

I can't really give an ETA on any release, because we're only working on this in our spare time. So releases may happen fast, or take a year or two.

Since this problem only affects the old release, I'm closing this issue.