My issues with the ALSA API

My issues with the ALSA API

[Lennart Poettering]

Heya!

A while back I compiled a list of issues I found with the ALSA API
while I was hacking PulseAudio. I kept it up to date ever since. It
has the title "Why I hate ALSA", but this is merely a catchy
title, I am not trying to offend anyone, nor do I think that the ALSA
API is particularly bad.

Back at FOMS in January this year, I showed this list to James. He
acknowledged most of those issues. But I am sure that the other ALSA
devs might be interested too:

http://pulseaudio.org/wiki/WhyIHateALSA

Comments welcome!

Thank you,

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: My issues with the ALSA API

[Jaroslav Kysela]

On Thu, 10 Apr 2008, Lennart Poettering wrote:

> http://pulseaudio.org/wiki/WhyIHateALSA

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.

Re: My issues with the ALSA API

[Lennart Poettering]

On Thu, 10.04.08 10:16, Jaroslav Kysela (perex@perex.cz) wrote:

> 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.'

I can think of many reasons, they all have to do with the fact that
the dB scale is not integral, i.e. in contrast for the normal integer
scale you won't always get what you are asking for, because the
hardware only supports a value below or above what you asked for: a) a
volume control tool might want to show a slider that is linear to the
dB scale, but also shows which dB values are actually selectable from
it via small black lines on the side (or suchlike) b) PA doesn't make
use of positive dB values -- it limits itself to attenuation via the
mixer. However, right now there is no way to find out which actually
supported dB value is the nearest one to 0dB. c) Several different dB
values may refer to the same actual hw setting. It would be good if a
specific dB value actually maps to the same integer hw setting as some
other value, to surpress redundant "volume change" events.

And I am pretty sure people could think of more cases.

> PCM
> ===
> 
> Timestamps - since 1.0.16 monotonic clocks are usable

Hmm, not really, as I hope I made clear in my other posting.

> plughw: issue - since 1.0.16 you can pass SND_PCM_NO_AUTO flags to open 
> function to disable specific conversions

Awesome, thank you very much! This is exactly what I need. I updated
the page accordingly.

> 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

I am doing this now. I'd still love to see an API for naked
interrupts, though.

> 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.

> 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.

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.

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.

regarding hw params: What exactly is "double buffering",
"sample-resolution mmap", "block transfer", "batch", "sync_start" ,
"fifo_size", "subformat", "export buffer", "min align"; why there is a
need for a seperate can_pause() and can_resume()? When and how should
all these options be used?

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.

regarding sw params: What exactly is a "boundary"? Difference between
tstamp modes? how do silence_size and silence_threshold relate?

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

Why is snd_pcm_scope included in the normal PCM docs?

> stderr output - you can redirect all outputs via 
> snd_lib_error_set_handler().

Ah, awesome, didn't find that one. Thanks.

> My plans for near future are to implement a better PCM device enumeration 
> and try to simplify mixer and add the mixer <-> PCM relationship.

That would be great.

> Also, could you explain why current device enumeration is not useful to 
> hotplug? There is information which card will be used (CARD=).

It's an API that returns a static list. That's all. 

Thanks,

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: My issues with the ALSA API - mixer

[Eliot Blennerhassett]

Greetings,

re Lennart's mixer comments (basically no way to find out grouping or 
connectivity between elements, some other constraints)

Does the info exposed by the intel-hda driver 
http://helllabs.org/codecgraph/
meet some or all of these requirements?

Would it be possible for
a) other drivers to export info in the same format
b) this info to be made part of the control api. I.e. adding nodes and 
connections to the control info
--
Eliot

Re: 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

Re: My issues with the ALSA API

[Lennart Poettering]

On Tue, 15.04.08 14:19, Takashi Iwai (tiwai@suse.de) wrote:

> > 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.

What is "much" if I may ask?

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

Please remove from the docs, then!

Also the part in the "Managing parameters" chapter in the PCM
introduction text.

> > 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.

Uh, and that's the part I don't get. I did read it, and didn't get
it. What exactly does _hwsync() do that _update_avail() doesnt?

> > 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.

The question remains: what exactly is is a "device" and what is a
"subdevice"? Examples?

For a while I thought that for those sound cards wich can output to
SPDIF and analog at the same time we have two different device
indexes, but a single card index. However, for my HDA card that is
listed in /proc/asound/pcm as "04-00 ALC882 Analog" and "04-01 ALC882
Digital", aplay -L suggests to use "ec958:CARD=Intel,DEV=0" for spdif
and "front:CARD=Intel,DEV=0" for analog -- both times with DEV=0!
Since then I have no idea what devices, subdevices and stuff should
actually be.

So again, what exactly qualifies subdevices? Do they share a single
crystal? Are they usually combined for multi-channel output? What's
the story?

> > 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.

Really? "block transfer" sounds to me like something that would be
interesting for mmap playback for cases where i randomly seek around
in my mmap buffer, with frame granularity. Which is exactly what I do
all the time in PA.

> > 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.

Uh. This has very confusing naming.

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

But what is this interesting for? I mean, I cannot read the raw
hardware pointer index anyway from ALSA, so why should I care?

Or is it all for the case where I create a *major* buffer underrun
with disabled stop_threshold and the value of _update_avail() keeps
increasing but eventually wraps around?

> > 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.

But in which way? Please elaborate!

> > 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.

You can use stuff like \cond in doxygen to hide certain parts of the
API pretty easily. 

> > Why is snd_pcm_scope included in the normal PCM docs?
> 
> I guess it was thought it'd be pretty useful.

Maybe the plugin is useful. But why is it part of the API docs?

Thanks,

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: My issues with the ALSA API

[Takashi Iwai]

At Sun, 20 Apr 2008 03:31:32 +0200,
Lennart Poettering wrote:
> 
> On Tue, 15.04.08 14:19, Takashi Iwai (tiwai@suse.de) wrote:
> 
> > > 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.
> 
> What is "much" if I may ask?

10 to 100 msec, IIRC.  Maybe depends on HZ and system loads.

> > > > 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 :)
> 
> Please remove from the docs, then!

Patch please :)

> Also the part in the "Managing parameters" chapter in the PCM
> introduction text.
> 
> > > 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.
> 
> Uh, and that's the part I don't get. I did read it, and didn't get
> it. What exactly does _hwsync() do that _update_avail() doesnt?

There are two PCM pointers in ALSA implementation: hw-pointer and
appl-poiter.  The former is a kind of DMA position, and the latter the
position the app filled.  In principle, hwsync() updates the former.
When you use normal read/write method (snd_pcm_wrieti(), etc), the
latter is updated automatically.  But, in the case of mmap mode, you
have to update it manually.  This is snd_pcm_avail_update() for.

The hw and appl pointers may be updated by some other methods, but the
above two calls are ones that (are supposed to) update directly.

> > > 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.
> 
> The question remains: what exactly is is a "device" and what is a
> "subdevice"? Examples?
> 
> For a while I thought that for those sound cards wich can output to
> SPDIF and analog at the same time we have two different device
> indexes, but a single card index. However, for my HDA card that is
> listed in /proc/asound/pcm as "04-00 ALC882 Analog" and "04-01 ALC882
> Digital", aplay -L suggests to use "ec958:CARD=Intel,DEV=0" for spdif
> and "front:CARD=Intel,DEV=0" for analog -- both times with DEV=0!

Because actually both of these point to the same device.  They are
exclusive.

> Since then I have no idea what devices, subdevices and stuff should
> actually be.
> So again, what exactly qualifies subdevices? Do they share a single
> crystal? Are they usually combined for multi-channel output? What's
> the story?

There is so strict definition at all for device/subdevice
classification.  The multiple subdevices are often provided to handle
the multi-playback streams (not multi-channels), such as emu10k1, or
multiplexing streams for captures.
With such a system, you can open multiple streams for the same
purpose, mixed or multiplexed on the hardware for the same I/O.
In the case of PCM, subdevice is often referred as "substream", BTW.  

Note that the multi-channel is often a different story.  On many
systems, the multi-channel output is implemented only as a single
interleaved stream, thus has only one subdevice.


> > > 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.
> 
> Really? "block transfer" sounds to me like something that would be
> interesting for mmap playback for cases where i randomly seek around
> in my mmap buffer, with frame granularity. Which is exactly what I do
> all the time in PA.

If it were implemented correctly through all devices, some information
might be useful.  But currently not, unfortunately.

> > > 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.
> 
> Uh. This has very confusing naming.

Yes.

> > > 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).
> 
> But what is this interesting for? I mean, I cannot read the raw
> hardware pointer index anyway from ALSA, so why should I care?

If you run a program for a long time, it much overwrap at some point.
The boundary defines that point.

> Or is it all for the case where I create a *major* buffer underrun
> with disabled stop_threshold and the value of _update_avail() keeps
> increasing but eventually wraps around?

Unlikely.

> > > 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.
> 
> But in which way? Please elaborate!

Later.

> > > 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.
> 
> You can use stuff like \cond in doxygen to hide certain parts of the
> API pretty easily. 

Hm, but what about to put these obsoleted functions to a dedicate
section?  Removing the API functions from a reference is a bad idea,
IMHO.

> > > Why is snd_pcm_scope included in the normal PCM docs?
> > 
> > I guess it was thought it'd be pretty useful.
> 
> Maybe the plugin is useful. But why is it part of the API docs?

Because the feature is included in alsa-lib.


thanks,

Takashi

Re: My issues with the ALSA API

[Jaroslav Kysela]

On Thu, 10 Apr 2008, Lennart Poettering wrote:

> On Thu, 10.04.08 10:16, Jaroslav Kysela (perex@perex.cz) wrote:
> 
> > 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.'
> 
> I can think of many reasons, they all have to do with the fact that
> the dB scale is not integral, i.e. in contrast for the normal integer
> scale you won't always get what you are asking for, because the
> hardware only supports a value below or above what you asked for: a) a
> volume control tool might want to show a slider that is linear to the
> dB scale, but also shows which dB values are actually selectable from
> it via small black lines on the side (or suchlike) b) PA doesn't make
> use of positive dB values -- it limits itself to attenuation via the
> mixer. However, right now there is no way to find out which actually
> supported dB value is the nearest one to 0dB. c) Several different dB
> values may refer to the same actual hw setting. It would be good if a
> specific dB value actually maps to the same integer hw setting as some
> other value, to surpress redundant "volume change" events.

OK. I see your points. I've added these functions to alsa-lib's API:

snd_mixer_selem_ask_playback_vol_dB
snd_mixer_selem_ask_capture_vol_dB
snd_mixer_selem_ask_playback_dB_vol
snd_mixer_selem_ask_capture_dB_vol

					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: My issues with the ALSA API

[Jaroslav Kysela]

On Thu, 10 Apr 2008, Lennart Poettering wrote:

> > Also, could you explain why current device enumeration is not useful to 
> > hotplug? There is information which card will be used (CARD=).
> 
> It's an API that returns a static list. That's all. 

Sure. but this list will update once new hardware is registered in system. 
So, if you know new card number of ID, you can ask again.

						Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: My issues with the ALSA API

[Jaroslav Kysela]

On Thu, 10 Apr 2008, Lennart Poettering wrote:

> > 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
> 
> I am doing this now. I'd still love to see an API for naked
> interrupts, though.

I've added snd_pcm_sw_params_set_period_event() function to ALSA API now. 
Actually, it uses PCM timer internally, but at least public API is defined 
so applications are not forced to use PCM timers explicitly. We can 
optimize this feature later.

					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.