We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 2874

Summary: Audio device selection in ALSA
Product: SDL Reporter: Matt Windsor <matt.windsor>
Component: audioAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED ABANDONED QA Contact: Sam Lantinga <slouken>
Severity: enhancement    
Priority: P2 CC: dominik.frizel
Version: 2.0.3   
Hardware: x86_64   
OS: Linux   
Attachments: Allow device Selection Alsa

Description Matt Windsor 2015-02-09 21:00:47 UTC
Hi,

How feasible would it be to make the SDL2 audio subsystem able to select from any ALSA audio device instead of only the default?  This functionality would be very useful for SDL-using programs that need to be used in contexts demanding fine-grained control over which programs use which devices (eg. multi-channel output to mixing desks).

I would be interested in trying to make a patch for this if one would be helpful.  I have no experience with SDL other than as a user, however.

This is similar to #2730, and I would say #2730 is probably the priority request, but some of us do still use 'raw' ALSA.

~ Matt
Comment 1 Dominik Frizel 2015-02-21 17:06:49 UTC
Created attachment 2039 [details]
Allow device Selection Alsa

This patch allows the device selection for the ALSA system.
I did some basic tests (Mint Linux 17.1 - amd64), using alsa over the pulse plugin
A lot of devices show up
Comment 2 Ryan C. Gordon 2015-03-24 07:51:52 UTC
(In reply to Dominik Frizel from comment #1)
> A lot of devices show up

No kidding! PulseAudio shows me three devices (the on-board audio chip, the HDMI port in my Nvidia GPU, and a USB headset I have plugged in). ALSA shows me _fifty four_ devices for the same configuration (that's counting input and output, but still, that's a lot).

I'm pretty sure Pulse uses ALSA to talk to actual hardware; does anyone know how it cuts down this list so ruthlessly (and correctly)?!

--ryan.
Comment 3 Dominik Frizel 2015-03-24 18:20:12 UTC
Well I know where to get the information
cat /proc/asound/cards - but how to map that on the cards delivered by the alsa api call, I am not sure (yet). Also this is very Linux specific.
Comment 4 Ryan C. Gordon 2015-03-25 00:31:55 UTC
(In reply to Dominik Frizel from comment #3)
> Well I know where to get the information
> cat /proc/asound/cards - but how to map that on the cards delivered by the
> alsa api call, I am not sure (yet). Also this is very Linux specific.

It looks like it uses udev, which is also pretty Linux specific.

(but oh well, so is ALSA, in practice.)

http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/module-udev-detect.c?id=85f5d93306888bd3ee09497056bfa1b1e32bd51f

Still, that's some pretty complicated code. I'm inclined to just list everything here and be done with it.

--ryan.
Comment 5 Ryan C. Gordon 2015-04-07 04:57:57 UTC
(sorry if you get a lot of copies of this email, I'm marking several bugs at once)

Marking bugs for the (mostly) final 2.0.4 TODO list. This means we're hoping to resolve this bug before 2.0.4 ships if possible. In a perfect world, the open bug count with the target-2.0.4 keyword is zero when we ship.

(Note that closing a bug report as WONTFIX, INVALID or WORKSFORME might still happen.)

--ryan.
Comment 6 Ryan C. Gordon 2018-08-06 21:20:18 UTC
Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)

Thanks,
--ryan.