On Wed, 05 Apr 2023 22:12:20 +0200, Oswald Buddenhagen wrote: > > @@ -1646,11 +1647,11 @@ Typically, you'll have a hardware descriptor as below:: > > The “period” is a term that corresponds to a fragment in the OSS > world. The period defines the point at which a PCM interrupt is > generated. This point strongly depends on the hardware. Generally, > a smaller period size will give you more interrupts, that is, > - more controls. In the case of capture, this size defines the input > + more controls (FIXME: huh? granularity, maybe?). In the case of capture, this size defines the input Well, "controls" might be no good choice of the word, it was meant as "the opportunities returned from kernel back to user-space for sending / receiving the defined size of data". This isn't really granularity, strictly speaking, but it may be a better fit. > DMA Buffer Information > ~~~~~~~~~~~~~~~~~~~~~~ > > +// FIXME: this is outdated; dma_private is available only through dma_buffer_p! It's written so: ``dma_private`` is used for the ALSA DMA allocator. And, this field can be used still freely if you implement the full stack in the driver by itself instead of using the standard helpers. > @@ -1709,10 +1711,11 @@ Running Status > The running status can be referred via ``runtime->status``. This is > a pointer to a struct snd_pcm_mmap_status record. > For example, you can get the current > DMA hardware pointer via ``runtime->status->hw_ptr``. > > +// FIXME: DMA application pointer is not explained. A better description please ;) > @@ -2010,10 +2013,12 @@ is called by the interrupt routine. Then the PCM middle layer updates > the position and calculates the available space, and wakes up the > sleeping poll threads, etc. > > This callback is also atomic by default. > > +FIXME: this does not specifiy whether this is the pre- or post-fifo position. > + Again, a patch to add more description please. > @@ -2384,10 +2389,14 @@ fields. > > The ``name`` is the name identifier string. Since ALSA 0.9.x, the > control name is very important, because its role is classified from > its name. There are pre-defined standard control names. The details > are described in the `Control Names`_ subsection. > +// This is a questionable design, IMO. Why user-space heuristics when > +// the driver could set the roles/capabilities? This would avoid > +// problems like the Tone Control sliders (unlike the switch?!) being > +// misclassified as applying also to capture. Why this has to be discussed here and now...? It's the thing that was *defined* over two decades ago. > The ``index`` field holds the index number of this control. If there > are several different controls with the same name, they can be > distinguished by the index number. This is the case when several > codecs exist on the card. If the index is zero, you can omit the > @@ -2485,10 +2494,11 @@ a control constantly. > When the control may be updated, but currently has no effect on anything, > setting the ``INACTIVE`` flag may be appropriate. For example, PCM > controls should be inactive while no PCM device is open. > > There are ``LOCK`` and ``OWNER`` flags to change the write permissions. > +// FIXME: explain. A patch please. > Control Callbacks > ----------------- > > info callback > @@ -3355,10 +3365,11 @@ Buffer and Memory Management > ============================ > > Buffer Types > ------------ > > +// FIXME: this appears obsolete, i only found one pair of functions. Yes, snd_malloc_pages() and snd_free_pages() have been replaced with the managed buffer. > @@ -3670,10 +3681,11 @@ user (root by default), do as follows:: > entry->mode = S_IFREG | S_IRUGO | S_IWUSR; > > and set the write buffer size and the callback:: > > entry->c.text.write = my_proc_write; > + // FIXME: something's missing here? No, that's fine. Rather the line above it (mentioning the write buffer size) is outdated; there is no size to be specified. thanks, Takashi
