[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:

• This report is NOT about the Android apps in the Play Store
• 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:

frontend-sdl-cpp/src/AudioCaptureImpl_SDL.cpp

Lines 127 to 128 in 080e48b

	auto deviceName = SDL_GetAudioDeviceName(_currentAudioDeviceIndex, true);
	_currentAudioDeviceID = SDL_OpenAudioDevice(deviceName, true, &requestedSpecs, &actualSpecs, 0);

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.