2071774178374812018
This commit is contained in:
1 parent
34075a79d5
commit
969eaa61f0
3 files changed
+56
-2
No files matched your search
+1
-1
@@ -7,7 +7,7 @@ author: "Alex Burrows"
|
||||
handle: AlexABPerson
|
||||
post_id: "2071714528635527401"
|
||||
date: 2026-06-29
|
||||
archived: 2026-08-23
|
||||
archived: 2026-08-25
|
||||
draft: true
|
||||
tags:
|
||||
- archive
|
||||
|
||||
+45
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "@NOTimothyLottes tinyplay does SNDRV_PCM_IOCTL_HW_PARAMS ioctl (referenced in the article alongside REFINE)"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/mrsteyk1/status/2071774178374812018"
|
||||
author: "mrsteyk"
|
||||
handle: mrsteyk1
|
||||
post_id: "2071774178374812018"
|
||||
date: 2026-06-30
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "@NOTimothyLottes tinyplay does SNDRV_PCM_IOCTL_HW_PARAMS ioctl (referenced in the article alongside REFINE)"
|
||||
in_reply_to: ""
|
||||
parent_post_id: "2071725181576319370"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/mrsteyk1/status/2071774178374812018
|
||||
- Author: mrsteyk (@mrsteyk1)
|
||||
- Posted: 2026-06-30 01:53:50
|
||||
|
||||
## Branch
|
||||
|
||||
**1/**
|
||||
|
||||
@NOTimothyLottes tinyplay does SNDRV_PCM_IOCTL_HW_PARAMS ioctl (referenced in the article alongside REFINE)
|
||||
|
||||

|
||||
|
||||
**2/**
|
||||
|
||||
@mrsteyk1 I believe the method the ALSA people wanted users to go by was to first REFINE to grab the full PCM limits, then iteratively make changes (via REFINE ioctl) until it converges to one configuration, at which point the HW_PARAMS ioctl is used to finalize that config.
|
||||
|
||||
**3/**
|
||||
|
||||
@mrsteyk1 Maybe it works sometimes to just use HW_PARAMs directly, but I have not got that working. I also cannot seem to get the refinement process to work either. And I don't get error returns, so still no idea what is wrong yet.
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/NOTimothyLottes/2026-06-29-alsa-hell-month-continues-remember-it-might-be]]
|
||||
+10
-1
@@ -7,7 +7,7 @@ author: "NOTimothyLottes"
|
||||
handle: NOTimothyLottes
|
||||
post_id: "2071706805114216559"
|
||||
date: 2026-06-29
|
||||
archived: 2026-08-23
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
@@ -30,6 +30,7 @@ in_reply_to: ""
|
||||
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 ...
|
||||
|
||||

|
||||
|
||||
Branches: [[archive/threads/NOTimothyLottes/2026-06-29-alsa-hell-month-continues-remember-it-might-be/2026-06-29-AlexABPerson-have-you-actually-reached-out-to-said-developers]]
|
||||
|
||||
**2/**
|
||||
@@ -37,16 +38,19 @@ Branches: [[archive/threads/NOTimothyLottes/2026-06-29-alsa-hell-month-continues
|
||||
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()
|
||||
|
||||

|
||||
|
||||
**3/**
|
||||
|
||||
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.
|
||||
|
||||

|
||||
|
||||
**4/**
|
||||
|
||||
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.
|
||||
|
||||

|
||||
|
||||
**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).
|
||||
@@ -56,17 +60,22 @@ In theory a good API, SNDRV_PCM_IOCTL_PREPARE would fail if the next SNDRV_PCM_I
|
||||
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.
|
||||
|
||||

|
||||
|
||||
**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)
|
||||
|
||||

|
||||
|
||||
Branches: [[archive/threads/NOTimothyLottes/2026-06-29-alsa-hell-month-continues-remember-it-might-be/2026-06-30-mrsteyk1-tinyplay-does-sndrv-pcm-ioctl-hw-params-ioctl]]
|
||||
|
||||
**8/**
|
||||
|
||||
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
|
||||
|
||||

|
||||
|
||||
**9/**
|
||||
|
||||
magiz/
|
||||
|
||||
Reference in new issue
Block a user