this post was submitted on 18 Mar 2026
4 points (100.0% liked)

Learn Programming

2135 readers
7 users here now

Posting Etiquette

  1. Ask the main part of your question in the title. This should be concise but informative.

  2. Provide everything up front. Don't make people fish for more details in the comments. Provide background information and examples.

  3. Be present for follow up questions. Don't ask for help and run away. Stick around to answer questions and provide more details.

  4. Ask about the problem you're trying to solve. Don't focus too much on debugging your exact solution, as you may be going down the wrong path. Include as much information as you can about what you ultimately are trying to achieve. See more on this here: https://xyproblem.info/

Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 2 years ago
MODERATORS
 

All the tutorials I can find is just telling me to jUSt UsE tHe DefAUltS (or even to use SDL or some similar library instead of my own solution), but some more advanced features such as getting HD rumble working on controllers with such features would require to connect to select devices.

So far I've tried:

  • using library functions, but they give weird results for some reason.
  • reading the contents of /proc/asound/cards, which supposed to work and contains some very useful addresses, but not the PCM handles themselves.

Unfortunately, 99% of my search results is about how to configure ALSA to be used in Linux, which is obviously not what I need.

top 5 comments
sorted by: hot top controversial new old
[–] Gyroplast@pawb.social 2 points 14 hours ago (1 children)

The way is to use the appropriate ALSA library functions as mentioned in the associated docs, and see referenced examples for an outline how the flow is authoritatively supposed to look like, right from the tap.

Please elaborate "weird results for some reason" with minimal examples, as in "this is what I get running this code, and that is what I expected". More often than not, the process of writing up your problems for external review leads to understanding, or at least to a couple good ideas what you might be doing wrong, or expecting to work differently.

The ALSA API is dense, and very C. It's super-easy to make wrong assumptions about how things should work there. Great training for slogging through API docs, though. :)

[–] ZILtoid1991@lemmy.world 1 points 14 hours ago* (last edited 14 hours ago) (2 children)

On function snd_pcm_open():

name ASCII identifier of the PCM handle

What does this mean exactly? What can I pass to it besides of "default"?

Originally I tried the function snd_device_name_hint, but it only worked for MIDI devices so far. For PCM, it lists all kinds of things.

Update: I'll try to add "hw:" in front of the device handles.

[–] Gyroplast@pawb.social 2 points 13 hours ago

I’ll try to add “hw:” in front of the device handles.

Generally that'd be required if you're using the hw:<card>[,device] device addressing, yes. You probably want to treat all device names, addresses, and handles as "opaque", though, meaning you don't care what the actual string looks like, and select your intended device through some other criteria.

That's where default comes from, in a way. It leaves the device choice to the user. I understood that you intend to access some other audio device, typically non-default. In that case it's ideal if you have any uniquely identifiable device information associated with the class of device you want to use, enumerate all "sound cards" to find those matching your criteria, and "hand down" the associated PCM handle to where you need it, without needing to know what it actually looks like.

Another way is to get a list of all "sound cards" of the system, and offer a legible selection of names/descriptions to the user in your application's options to explicitly select the correct device, and have an internal mapping of that selection to it's ASCII identifiers of PCM handles. Again, no need to know what the identifier looks like, you only need to match the user's selection to it's internal ID. This offloads the potentially difficult decision what device to use to your user, though, who may be even more lost being asked that question.

[–] Gyroplast@pawb.social 1 points 14 hours ago (1 children)

With "pcm" as the iface parameter in snd_device_name_hint() this should not happen. Did you check out and pilfer the code from aplay.c as I suggested before?

Post minimal, compilable sources to show your issue and the output you get, please.

[–] ZILtoid1991@lemmy.world 1 points 13 hours ago

I'm not having problems with opening the default sound device, I'm having problems with specifying sound devices.