[alsa-devel] My issues with the ALSA API

[Takashi Iwai]

At Thu, 10 Apr 2008 17:20:38 +0200,
Lennart Poettering wrote:
> 
> > What do you mean with 'There is no API to query the granularity of 
> > snd_pcm_delay()' ? Application should not know details about bottom 
> > implementation.
> 
> As far as I understood there are a few soundcards around where
> the playback sample index is only known each time the hw changes to
> the next fragment. It would be good to know about this, to tweak the
> time interpolation in timer-based scheduling.

We may add some hints to the PCM information, but I think maybe this
isn't only the question about granualrity.  For example, on some
hardwares, the query of the current position costs much due to the
hardware design.


> > Documentantion - if you ask specific questions, we try to update 
> > documentantion for other developers.. unfortunately, saying that whole 
> > documentantion is bad is not productive
> 
> Sorry. I'll make sure I'll ask for clarifications more clearly on
> alsa-devel from now on.
> 
> Here's my first batch of questions:
> 
> I am not sure I get what the "transfer align" is about.

Just ignore, this is obsoleted in the latest version :)

> It is not clear how snd_pcm_update_avail() and snd_pcm_hwsync()
> actually play together, why they exist at all, and how exactly the
> optimization they are apparently useful for should  be used.

The detailed description is found in PCM documentation.

> It would be good to have an explanation what a "card", what an "id",
> what a "name", what a "device" and what a "subdevice" actually refers
> to, with examples.

The card (index) is the index number of the sound card instance.
Each card has an id string and name string(s).
One card instance may have several belonging components.  And each
component has (usually) a device index.  Some components (e.g. PCM or
rawmidi) can have multiple subdevices (or substreams).  Each subdevice
has a subdevice index.

> regarding hw params: What exactly is "double buffering",
> "sample-resolution mmap", "block transfer", "batch", "sync_start" ,
> "fifo_size", "subformat", "export buffer", "min align";

Most of them can be ignored, at least for PA :)  I'd love to get rid
of most of them in future, too.

sync_start might be interesting, though.  This indicates that the
full-duplex streams can start synchronously.

> why there is a
> need for a seperate can_pause() and can_resume()?

can_pause() means the ability to pause/restart the stream.

can_resume() means the ability to resume the suspended/hibernated
stream by the driver natively.

> When and how should
> all these options be used?

Well, these indicate the hardware functionalities that no one actually
cares much as originally expected.  You see similar cases in any
industry fields. 
So, just don't disturb, keep them rest in peace.  Then we'll be able
to gracefully obsolete them.

> BTW: the doc for is_batch is copied 1:1 from the double_buffer text.
> 
> The docs speak of "blocked" and "non-blocked" open. It should be
> "blocking", I believe.

Patch please.

> regarding sw params: What exactly is a "boundary"? Difference between
> tstamp modes?

The boundary defines the limit PCM position (frames) can reach.  When
the PCM position reaches to the boundary size, then it backs to 0 at
next.  The boundary size is aligned to the buffer size, and it's not
LONG_MAX (although close to it).

> how do silence_size and silence_threshold relate?

The PCM driver core has a feature to clear the samples automatically
at each period elapse call.  The silence_size and silence_threshold
defines this behavior.

> What is snd_pcm_xrun_t useful for? (I think it is obsolete, should
> also be removed from docs, then)

Right.  Maybe should be classified to the section "obsoleted
functions".  A part of the problem is that the reference document is
generated via doxygen, and it seems a bit confusing to arrange the
sections in a single file.

> Why is snd_pcm_scope included in the normal PCM docs?

I guess it was thought it'd be pretty useful.


Takashi