Subject: [linux-audio-dev] Re: [Alsa-devel] XRuns and Low-Latency
From: Fernando Pablo Lopez-Lezcano (nando_AT_ccrma.Stanford.EDU)
Date: Wed Aug 08 2001 - 01:22:21 EEST
> >Would it be possible to return better values for:
> >
> >snd_pcm_hw_params_get_channels_min / max
> >snd_pcm_hw_params_get_rate_min / max
> >
> >when the plug layer is used?:
> >min_ch: 1
> >max_ch: 1073741823
> >min_rate: 1
> >max_rate: -1
> >
> >This way the users has to enter how many channels he want's to have. And I
> >hav e no possibility to check the count or provide meaningfull defaults or
> >selecta ble ranges for the card ... - and using the hw:x directly I have to
> >provide a ll format convertions myself ...
>
> this has been discussed on alsa-devel quite a lot in the last 2
> weeks. i suggest you start by reading the archives for that list, and
> then continue the discussion there.
Yep, it has been discussed a lot :-)
> basically, the values the plug layer returns are factually correct,
> and you are asking for something that ALSA doesn't properly or fully
> support at this time (which as you observe is something like "please
> add various parts of the plug layer, but not all it"). it may be that
> jaroslav or abramo or fernando added a patch recently to cover the
> channels case specifically.
Jaroslav and Abramo have added configuration options that help
somewhat. There is currently a configuration option for the
alsa.conf file that enables you to turn the completely correct
(but completely useless as well) number of channels returned
by querying the configuration space of a plug pcm. Something
like this should do it:
pcm.testchan {
type plug
slave {
pcm hw
channels unchanged
}
}
From alsa-lib's asoundrc.doc:
[format STR] # Slave format (default nearest) or "unchanged"
[channels INT] # Slave channels (default nearest) or "unchanged"
[rate INT] # Slave rate (default nearest) or "unchanged"
You can also make format and/or rate reflect the slave pcm's
supported formats or rates.
You may also find that alsa-lib does "mixing" behind your back
when the number of channels opened are less than the available
channels in the hardware interface that's hidden behind the
plug layer, adding this route_policy to the plug definition
will get rid of that behavior:
pcm.testchan {
type plug
slave {
pcm hw
}
route_policy copy
}
Jaroslav has hinted that there are internal functions in
alsa-lib that would make a programmatic equivalent feasible,
but there's no access to them from the current api (I'm not
going to touch them as they might change at any time). I
believe that at some point an API will _have_ to be designed
to get around this limitation of the plug pcm api. I may be
wrong, but I suspect that more and more programmers will ask
about how to circumvent this feature as they try to use the
api in real world applications. At this point it is not
possible (AFAIK) to write a program that queries an arbitrary
pcm and works equally well with hw or plug pcms, without
relying on an external configuration file to sanitize the
query results.
-- Fernando
This archive was generated by hypermail 2b28 : Tue Aug 07 2001 - 22:24:48 EEST