On Thu, 10 Apr 2008, Lennart Poettering wrote:
I started to work on some issues. Note that your requirements are a bit more complex than normal applications need and we're mostly driven by user requests. Some things are misleading (or they are already implemented) in your comments:
Mixer =====
Please explain this question (why you need the dB <-> value conversion, we assumed that application works in dB or integer range not both):
'It is possible to query the dB range of a smixer element. And it is possible to query and set the current dB level. However, it is not possible to have a dB value converted to an integer level or vice versa, without touching the actual setting. i.e. a question like "What is the integer level 0 dB corresponds to?" can not be answered by ALSA. Which happens to be a serious limitation.'
PCM ===
Timestamps - since 1.0.16 monotonic clocks are usable
plughw: issue - since 1.0.16 you can pass SND_PCM_NO_AUTO flags to open function to disable specific conversions
buffer mananagement - I think we already discussed this - use sw_params or PCM timer to be updated when buffer position changes (interrupt was processed), you can use poll() as well
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.
General =======
Documentantion - if you ask specific questions, we try to update documentantion for other developers.. unfortunately, saying that whole documentantion is bad is not productive
stderr output - you can redirect all outputs via snd_lib_error_set_handler().
========================================
My plans for near future are to implement a better PCM device enumeration and try to simplify mixer and add the mixer <-> PCM relationship.
Also, could you explain why current device enumeration is not useful to hotplug? There is information which card will be used (CARD=).
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.