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