[APP BUG] [FRONTEND-SDL] [PIPEWIRE] Only input devices (like mic) are listed and selectable; and wrong app name ('SDL app' instead of ProjectM-SDL)

[actionless]

Please confirm the following points:

• [x] This report is NOT about the Android apps in the Play Store
• [x] I have searched the project page to check if the issue was already reported

Affected Application

projectM Standalone SDL2 Frontend (includes the Steam app)

Affected Version

git master

Operating System

Linux (Desktop)

Additional Application Details

and also wrong app name ('SDL app' instead of ProjectM-SDL)

Type of Defect

Misc

Log Output

$ projectMSDL -l
Events enabled: 1
Recording audio from device "Onyx Blackjack Analog Stereo" (ID 0).
Available audio capturing devices:
    -1 = Default capturing device
    0 = Onyx Blackjack Analog Stereo

$ pw-link -l -i -o | grep -i  -C 3  -e sdl
...
  |-> SDL Application:input_FL
...
  |-> SDL Application:input_FR

Describe the Issue

Previous versions were listing all devices, including monitors

The current workaround:

#!/bin/sh

record_from_interface=easyeffects_sink:monitor
record_wrong_interface=alsa_input.usb-Loud_Technologies_Inc._Onyx_Blackjack-00.analog-stereo:capture
listen_on_interface="SDL Application:input"

projectMSDL \
	-p/usr/share/projectM/presets/ \
	--shuffleEnabled=0 \
	--enableSplash=0 \
	--width=1920 \
	--height=1080 \
	--fps=30 \
	--beatSensitivity=0.72 \
	--fullscreenWidth=1920 \
	--fullscreenHeight=1080 \
	"$@" &
pid=$!

sleep 2
for channel in FL FR ; do
	record_from_channel="${record_from_interface}_${channel}"
	listen_on_channel="${listen_on_interface}_${channel}"
	record_wrong_channel="${record_wrong_interface}_${channel}"
	pw-link "$record_from_channel" "$listen_on_channel"
	pw-link --disconnect "$record_wrong_channel" "$listen_on_channel"
done


wait $pid
for channel in FL FR ; do
	record_from_channel="${record_from_interface}_${channel}"
	listen_on_channel="${listen_on_interface}_${channel}"
	pw-link --disconnect "$record_from_channel" "$listen_on_channel"
done

[actionless]

if instead of pipewire trying to run it with pulseaudio backend instead, it detects the audio devices, but UI visually hangs, right after that line (although log messages in command line still respond to keypresses inside the window):

$ SDL_AUDIODRIVER=pulseaudio projectMSDL -l -d0
Events enabled: 1
Recording audio from device "Monitor of Avantree C81 Analog Stereo" (ID 0).
Available audio capturing devices:
    -1 = Default capturing device
    0 = Monitor of Avantree C81 Analog Stereo
    1 = Monitor of Onyx Blackjack Analog Stereo
    2 = Onyx Blackjack Analog Stereo
    3 = Monitor of Easy Effects Sink
    4 = Easy Effects Source
Opened audio recording device "Monitor of Avantree C81 Analog Stereo" (ID 0) with 2 channels at 44100 Hz.

with jack it also hangs the same as with pulse

with alsa works, but shows only inputs without monitors

[actionless]

(i've renamed it from 'regression' since it's not actually a regression, although the hang with pulseaudio which haven't been happening before - i'm not sure whatever is a regression on a side of pipewire-pulse or projectm - as i don't have possibility to downgrade to pure pulseaudio setup for testing)

[kblaschke]

I don't think we can do much about this issue, as the whole audio device handling is done within libSDL2 and the audio backend implementation used (see the SDL_AUDIODRIVER environment variable). There are many different builds and configurations of libSDL2 out there, so hard to tell what's going wrong.

Could you provide a full back trace on all threads at the point the UI hangs? That could give a clue where exactly the lockup happens. Run projectMSDL with gdb, then ctrl-c when it hangs and type thread apply all bt to dump all thread stacks.

[actionless]

i'm not closely familiar with libsdl, but that's one of first results i got in google: https://www.reddit.com/r/linux_gaming/comments/lv25d9/sdl_audio_add_pipewire_playbackcapture_sink/

[actionless]

and regarding pulseaudio/jack output hanging - because both on my system are using pipewire-pulse and pipewire-jack, not real pulse/jack that could be smth wrong with that

[actionless]

i quickly checked aforementioned commit of sdl and i see its separating devices by Capture and Playback types - are you also using that parameter for filtering available devices? because that could be the problem that monitoring 'device' is not a separate device, it's the same as output device, so it's not marked as capture device

[kblaschke]

i quickly checked aforementioned commit of sdl and i see its separating devices by Capture and Playback types - are you also using that parameter for filtering available devices?

Sure, those devices work differently, as you put audio data into one type and get data from the other. There is a boolean flag named iscapture in the SDL_GetNumAudioDevices(), SDL_GetAudioDeviceName() and SDL_OpenAudioDevice() functions, which is set to true in projectMSDL:

https://github.com/projectM-visualizer/frontend-sdl-cpp/blob/080e48b303fe9d7eebaba6d266ddef0543bba0d3/src/AudioCaptureImpl_SDL.cpp#L127-L128

On my request, icculus thankfully added a hint to tell SDL to also list "Monitor" devices as well. Support for this hint was initially added in libSDL 2.0.16, versions before only ever list external input devices.

All that said, on the application side there's not too much we can change or fix, as the SDL audio API is super simple. How audio devices are listed and handled is completely wrapped inside the respective SDL audio driver, with varying quality - mostly depending on which features the actual audio backend library provides.

That's why I asked for a stack dump, as this makes it easy to see where something hangs.

Another thing to check is whether you're using the "real" libSDL2 library or the libSDL2 shim for libSDL3, which is known to (currently) have some issues. PR #101 addresses an issue with audio channel count, but this didn't really crash/hang the application, only prevent it from recording audio when using the libSDL 2->3 shim.

[kblaschke]

Since there's no further activity on this issue, I'll close it.

Regarding the initially reported issues:

• Using Pipewire, the current app is shown as "projectMSDL" in my audio panel. If anything else is shown there, this is either caused by libSDL or the OS audio server, as there's no option to set the application's display name in the code.
• Which audio devices are listed and work highly depends on which SDL audio driver is being used and which audio server the OS is running. Ideally, if Pipewire runs on the OS, using the pipewire SDL driver is suggested. If that doesn't work (e.g. I'm getting very low audio levels), try using a different audio driver such as pulseaudio or even alsa by setting the environment variable SDL_AUDIODRIVER to one of these values.

If you still experience issues with audio capturing and can provide additional information that this is caused by projectMSDL's capture code, please open a new issue and provide addtional context such as stack traces or information on how to reproduce the issue.

[NiciTheNici]

I have found a workaround using pavucontrol. Under Recording >> SDL Application you can set the audio source, even those not showing up in the projectM-sdl app.