On Mon, 15 Dec 2003 09:59:16 +0100 (CET), Jaroslav Kysela <[EMAIL PROTECTED]>
wrote:
On Sun, 14 Dec 2003, Arve Knudsen wrote:
On Mon, 15 Dec 2003 01:17:26 +0900, Patrick Shirkey
<[EMAIL PROTECTED]> wrote:
> If we have a DB of info how would we define the abilities of each
device?
>
> I assume t
On Sun, 14 Dec 2003, Manuel Jander wrote:
> I looked into "alsa-kernel/core/control.c" and after finding out that
> every control interaction does a control lookup (iterated through all
> controls), i don't feel very confortable about using kcontrols to update
> hardware parameters in at tens of m
On Sun, 14 Dec 2003, Arve Knudsen wrote:
> On Mon, 15 Dec 2003 01:17:26 +0900, Patrick Shirkey
> <[EMAIL PROTECTED]> wrote:
>
> > If we have a DB of info how would we define the abilities of each device?
> >
> > I assume this info is available in the driver layer because there is a
> > point wh
Hi,
While writing a advanced capabilities (positional audio) interface for
ALSA, i encountered this same problem.
So far i have "architected" the thing like this:
- The ALSA driver loads as usual.
- When OpenAL or whatever fires up, it queries the device for
capabilties, using a well defined con
On Mon, 15 Dec 2003 01:17:26 +0900, Patrick Shirkey
<[EMAIL PROTECTED]> wrote:
If we have a DB of info how would we define the abilities of each device?
I assume this info is available in the driver layer because there is a
point where ALSA will return false eg. if a card is not able to run at
>My opinion is that a simple function could be included in alsactl which
>scans for available devices, makes a list of their abilities. Everyone
>uses "post-insert alsactl restore" in the modules.conf file so it would
>be essentially a non issue from a user perspective.
i think it needs to be s
If we have a DB of info how would we define the abilities of each device?
I assume this info is available in the driver layer because there is a
point where ALSA will return false eg. if a card is not able to run at
48000Hz
My opinion is that a simple function could be included in alsactl which
On 08-Dec-2003 Arve Knudsen wrote:
> Wether its done via the control or pcm interface, it'd be good to have a
> loose coupling between configuration and streams, so one could could access
> configuration space without locking a stream don't you think?
Yes, of course. Perhaps it can be done alread
On Mon, 8 Dec 2003 17:57:03 +0100 (CET), Jaroslav Kysela <[EMAIL PROTECTED]>
wrote:
On Mon, 8 Dec 2003, Arve Knudsen wrote:
Wether its done via the control or pcm interface, it'd be good to have a
loose coupling between configuration and streams, so one could could
access
configuration space wi
>I don't agree. The control API (usually) is for things that don't affect
>the way data is transferred between the card the the computer.
it is *now*. i was just imagining a different conception of what it
could be used for.
> Sample
On Mon, 8 Dec 2003, Arve Knudsen wrote:
> Wether its done via the control or pcm interface, it'd be good to have a
> loose coupling between configuration and streams, so one could could access
> configuration space without locking a stream don't you think? I mean,
> with ASIO, from what I can see
On Mon, 8 Dec 2003 16:19:36 +0100, Giuliano Pochini <[EMAIL PROTECTED]>
wrote:
On Sun, 07 Dec 2003 14:19:28 -0500
Paul Davis <[EMAIL PROTECTED]> wrote:
i personally am heading towards believing that we made a design
decision that was wrong here. i now tend to think that the PCM
interface should n
On Sun, 07 Dec 2003 14:19:28 -0500
Paul Davis <[EMAIL PROTECTED]> wrote:
> i personally am heading towards believing that we made a design
> decision that was wrong here. i now tend to think that the PCM
> interface should not be involved with configuring the hardware at all,
> and that this shoul
Hallo,
Arve Knudsen hat gesagt: // Arve Knudsen wrote:
> On Mon, 8 Dec 2003 11:49:45 +0100, Frank Barknecht <[EMAIL PROTECTED]>
> wrote:
> >Which reminds me to ask: how does Portaudio currently cope with
> >user-defined, not enumerable interfaces in ALSA?
> Only concrete hardware devices are cons
On Mon, 8 Dec 2003 11:49:45 +0100, Frank Barknecht <[EMAIL PROTECTED]>
wrote:
Hallo,
Arve Knudsen hat gesagt: // Arve Knudsen wrote:
I'm one of the developers responsible for the ALSA implementation of a
cross
platform audio wrapper called PortAudio (www.portaudio.com), which
gathers
info about
Hallo,
Arve Knudsen hat gesagt: // Arve Knudsen wrote:
> I'm one of the developers responsible for the ALSA implementation of a
> cross
> platform audio wrapper called PortAudio (www.portaudio.com), which gathers
> info about available devices during startup.
Which reminds me to ask: how does Por
On Sun, 7 Dec 2003 21:44:16 +0100 (CET), Jaroslav Kysela <[EMAIL PROTECTED]>
wrote:
On Sun, 7 Dec 2003, Arve Knudsen wrote:
On Sun, 7 Dec 2003 21:00:13 +0100 (CET), Jaroslav Kysela <[EMAIL PROTECTED]>
wrote:
> On Sun, 7 Dec 2003, Arve Knudsen wrote:
>
>> > We all think in the same way, but there
On Sun, 7 Dec 2003, Arve Knudsen wrote:
> On Sun, 7 Dec 2003 21:00:13 +0100 (CET), Jaroslav Kysela <[EMAIL PROTECTED]>
> wrote:
>
> > On Sun, 7 Dec 2003, Arve Knudsen wrote:
> >
> >> > We all think in the same way, but there's no simple solution for this
> >> > problem. I prefer to have such con
On Sun, 7 Dec 2003 21:00:13 +0100 (CET), Jaroslav Kysela <[EMAIL PROTECTED]>
wrote:
On Sun, 7 Dec 2003, Arve Knudsen wrote:
> We all think in the same way, but there's no simple solution for this
> problem. I prefer to have such configuration information in an
user-space
> database accessed via
On Sun, 7 Dec 2003, Paul Davis wrote:
> >We all think in the same way, but there's no simple solution for this
> >problem. I prefer to have such configuration information in an user-space
> >database accessed via an alsa-lib API. It's nothing for the kernel space.
>
> i'm not sure i agree with t
On Sun, 7 Dec 2003, Arve Knudsen wrote:
> > We all think in the same way, but there's no simple solution for this
> > problem. I prefer to have such configuration information in an user-space
> > database accessed via an alsa-lib API. It's nothing for the kernel space.
>
> I dunno, I think Paul's
>We all think in the same way, but there's no simple solution for this
>problem. I prefer to have such configuration information in an user-space
>database accessed via an alsa-lib API. It's nothing for the kernel space.
i'm not sure i agree with that. a user-space config DB could be used
to desc
On Sun, 7 Dec 2003 20:38:48 +0100 (CET), Jaroslav Kysela <[EMAIL PROTECTED]>
wrote:
On Sun, 7 Dec 2003, Arve Knudsen wrote:
On Sun, 07 Dec 2003 14:19:28 -0500, Paul Davis
<[EMAIL PROTECTED]> wrote:
I'd like to be able to query the capabilities (number of
channels,=20
buffer
size
On Sun, 7 Dec 2003, Arve Knudsen wrote:
> On Sun, 07 Dec 2003 14:19:28 -0500, Paul Davis
> <[EMAIL PROTECTED]> wrote:
>
> I'd like to be able to query the capabilities (number of channels,=20
> buffer
> size etc.) of ALSA devices in the system, even if they should be in
> us
On Sun, 07 Dec 2003 14:19:28 -0500, Paul Davis
<[EMAIL PROTECTED]> wrote:
I'd like to be able to query the capabilities (number of channels,=20
buffer
size etc.) of ALSA devices in the system, even if they should be in
us=
e=20
by
some other process. The only current way to probe device capabili
>>> I'd like to be able to query the capabilities (number of channels,=20
>>> buffer
>>> size etc.) of ALSA devices in the system, even if they should be in us=
>e=20
>>> by
>>> some other process. The only current way to probe device capabilities =
>is
>>> to open a pcm, and use snd_pcm_hw_params,
On Sun, 7 Dec 2003 19:40:23 +0100 (CET), Jaroslav Kysela <[EMAIL PROTECTED]>
wrote:
On Sun, 7 Dec 2003, Arve Knudsen wrote:
I'd like to be able to query the capabilities (number of channels,
buffer
size etc.) of ALSA devices in the system, even if they should be in use
by
some other process. T
On Sun, 7 Dec 2003, Arve Knudsen wrote:
> I'd like to be able to query the capabilities (number of channels, buffer
> size etc.) of ALSA devices in the system, even if they should be in use by
> some other process. The only current way to probe device capabilities is
> to open a pcm, and use sn
I'd like to be able to query the capabilities (number of channels, buffer
size etc.) of ALSA devices in the system, even if they should be in use by
some other process. The only current way to probe device capabilities is
to open a pcm, and use snd_pcm_hw_params, correct? At least this is my
cu
1) just a quick note to point out that whether you know it or not, the
email program you are using is sending out copies of your mail in both
plain text and HTML formats. increasingly on the net, there are
filters being put in place that silently dump HTML-formatted
email. some mailing lists will
Hello !!! All the nice people out
there
I am new on the list and I need some queries
answered here about the ALSA.
I am trying to develop an application that can
record multiple channels i.e. about 8. I have looked into a few API's but have
not found anything promising. I have a ca
31 matches
Mail list logo
