4.9 KiB
← Back to Twitter thread index
title: "ALSA hell month continues: remember it might be "open source" but it is definite" author: "NOTimothyLottes" handle: "@NOTimothyLottes" post_url: "https://x.com/NOTimothyLottes/status/2071706805114216559" post_id: "2071706805114216559" timestamp: "2026-06-29 21:26:07" post_count: 15 reply_count: 3 repost_count: 0 like_count: 21 view_count: 1713
@NOTimothyLottes — ALSA hell month continues: remember it might be "open source" but it is definite
Post 1 (2026-06-29 21:26:07)
ALSA hell month continues: remember it might be "open source" but it is definitely "closed documentation" [those docs are securely trapped in the minds of the authors]. Now that I have aplay playing a sound, it's time for garbage sifting through STRACE to see what is going on ...
Post 2 (2026-06-29 21:42:37) — reply to Post 1
For devs working on linux, strace is a good friend, besides reverse engineering undocumented crap, it's useful to run on your own app as a bug test, like look what this idiot [me] did with nanosleep()
Post 3 (2026-06-29 21:56:14) — reply to Post 2
In my ALSA interface I war-dial the possible /dev/snd/pcm devices instead of just listing the directory. It's a lot easier in source code.
Post 4 (2026-06-29 21:56:48) — reply to Post 1
@NOTimothyLottes Have you actually reached out to said developers and offered to start a documentation effort/ask them some questions about things? It seems a little unfair to be rage posting about this all the time when the point is you (and me, and everyone) have the power to make it better.
Post 5 (2026-06-29 22:02:25) — reply to Post 3
Using 'strace' showed another bug in my setting schedule priority code (I didn't yet validate that code and check for errors). Definitely my ALSA test app shows ZERO errors in ALSA system calls, but doesn't actually play anything. Broken without errors = crappy API.
Post 6 (2026-06-29 22:04:37) — reply to Post 5
In theory a good API, SNDRV_PCM_IOCTL_PREPARE would fail if the next SNDRV_PCM_IOCTL_WRITEI_FRAMES wouldn't accept the write. And that WRITEI should also fail instead of pass and setting .result=0 (of the snd xferi structure).
Post 7 (2026-06-29 22:07:22) — reply to Post 6
The best I can guess thus far is that the aplay app goes through some HW_REFINE ioctls before setting the HW_PARAMS, and perhaps the "magic missing thing" is in that process.
Post 8 (2026-06-29 22:12:52) — reply to Post 4
@AlexABPerson Haha I could start that with an email: hello godly ALSA dev, as a vintage pee-on programmer from the stone age, I was trying to ignore your advice about using the user-space API and thus needing GPL, and instead using the undocumented IOCTLs of the kernel driver directly ...
Post 9 (2026-06-29 22:19:03) — reply to Post 8
@AlexABPerson But on a serious note, I mostly shit post for the entertainment, because once in a while I actually learn something from a response. And often documenting the process might help someone else too ...
Post 10 (2026-06-29 22:39:08) — reply to Post 7
Best docs on REFINE that I've found yet is indirectly through this. Note tinyalsa doesn't seem to use this interface other than through pcm_params_get(), not the interative process seen in aplay strace. Maybe because tinyalsa is for android (different drivers)
Post 11 (2026-06-29 23:44:32) — reply to Post 9
@NOTimothyLottes That's fair, thank you for the honest reply! It is interesting to see a lot of these sorts of inner workings, and I definitely sympathise with the "I can't believe it works like this" feeling 😂 Stuff does have a tendency to get like that huh
Post 12 (2026-06-30 00:56:46) — reply to Post 10
SNDRV_PCM_IOCTL_HW_REFINE If send out a zeroed snd_pcm_hw_params, the ioctl will fail. There is a special magic sauce to the structure that must be initialized correctly before you can even fetch hardware parameters. It's high level skill in Obfuscation. See *_any( in ALSA src
Post 13 (2026-06-30 00:59:34) — reply to Post 12
magiz/ clear snd_pcm_hw_params set masks[0 ... 2].bits[0]=~0 set intervals[0 ... 11].max=~0 set rmask=~0 set info=~0
Post 14 (2026-06-30 01:26:54) — reply to Post 13
The rmask and cmask use bit indexed by the DEFINE so 1<<SNDRV_PCM_HW_PARAM_{thing}
Post 15 (2026-06-30 01:35:19) — reply to Post 14
Hats off to Abramo Bagnara of the ALSA project for the worst kernel system interface I have ever used in my life. This refinement required just to configure an audio device is a master class on the worst way to do something. And still have a few hours left in reverse engineering