24 Jan
2003
24 Jan
'03
6:43 a.m.
Hi all,
I was looking for a good, up-to-date documentation pointer upon software features provided
by alsa. But I'm new to this architecture and I might be "intoxicated" by
some kernel streaming architectures : is there a kind of hardware abstraction with ALSA,
e.g. features that are managed by the software at usr or kernel level, in a +/-transparent
way, when the HW does not provide them ?
My understanding is that Alsa does not provide multiple device open (a second open can be
blocking, or return with an error, but won't succeed, as no sw mixing is available).
is there anything that can be emulated by alsa on user request, when the hw cannot ? (for
instance frequency change, frame conversion (n channels to m channels) etc...).
How would you implement such thing ? With a kind of abstraction layer daemon, that exports
the same api but perform missing hw features ?
Could the LADSPA plugin architecture be a solution to implement multiple device open ?
tx
Marc.
24 Jan
24 Jan
9:11 a.m.
New subject: [linux-audio-dev] Linux Audio Hardware Selection
I was looking for a good, up-to-date documentation
pointer upon software featu
res provided by alsa. But I'm new to this architecture and I might be "intoxic
ated" by some kernel streaming architectures : is there a kind of hardware ab
straction with ALSA, e.g. features that are managed by the software at usr or
kernel level, in a +/-transparent way, when the HW does not provide them ?
yes, its called alsa-lib. its big, its bold, and to some people its
beautiful.
My understanding is that Alsa does not provide multiple
device open (a second
open can be blocking, or return with an error, but won't succeed, as no sw mix
ing is available).
that's correct right at this very moment in time. however, the
mythical "mix" ALSA PCM "plugin" provides
multi-open-without-h/w-support by streaming data to a server called
"aserver". at this time, the mix plugin is not part of the ALSA source
base. its far from clear that anyone is doing any work on it.
is there anything that can be emulated by alsa on user
request, when the hw ca
nnot ? (for instance frequency change, frame conversion (n channels to m chan
nels) etc...).
all of it.
the other alternative that many of us here like rather a lot is JACK
(http://jackit.sf.net/), which provides a different model: data
sharing between applications, shared access to hardware,
sample-synchronous execution of all applications, and no hardware
parameters to be configured. it sits on top of ALSA (and potentially
other similar hardware abstractions).
--p
12:13 p.m.
New subject: [linux-audio-dev] Linux Audio Hardware Selection
At Fri, 24 Jan 2003 08:09:44 -0500,
Paul Davis wrote:
the other alternative that many of us here like rather a lot is JACK
(http://jackit.sf.net/), which provides a different model: data
sharing between applications, shared access to hardware,
sample-synchronous execution of all applications, and no hardware
parameters to be configured. it sits on top of ALSA (and potentially
other similar hardware abstractions).
what i've thought of is to make libjack runnable as standalone without
jack server. i know it sounds useless for serious purpose.
but, at least, people can write the application using a simple API,
and have possiblity to debug in different environment.
for example, in the standalone mode, libjack will initialize the
necessary hardware setup silenty according to the config file, so that
in the application you don't need to set up the nasty things.
(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?)
Takashi
12:29 p.m.
New subject: [linux-audio-dev] Linux Audio Hardware Selection
At Fri, 24 Jan 2003 08:09:44 -0500,
Paul Davis wrote:
not at all. it would allow programs to be run with no context switch
overhead if they are started alone without jackd, which would be
rather nice. we need to get in-process clients done first, though.
imagine: your program can run in either mode - networked to other
applications and sharing the audio interface, or running with high
efficiency all by itself. all this with no code changes to your
application!
the other alternative that many of us here like rather a lot is JACK
(http://jackit.sf.net/), which provides a different model: data
sharing between applications, shared access to hardware,
sample-synchronous execution of all applications, and no hardware
parameters to be configured. it sits on top of ALSA (and potentially
other similar hardware abstractions).
what i've thought of is to make libjack runnable as standalone without
jack server. i know it sounds useless for serious purpose. but, at least, people can write the application using a
simple API,
and have possiblity to debug in different environment.
i've had the same idea. my approach would basically be to have libjack
try to contact the server. if it fails, then it just starts up a
thread to run the audio loop, and then instantiate the client as an
in-process client.
for example, in the standalone mode, libjack will
initialize the
necessary hardware setup silenty according to the config file, so that
in the application you don't need to set up the nasty things.
(btw, why jackd doesn't read /etc/jackrc or
~/.jackrc ?)
because that means we have a config file, which means we need a config
file parser, which means we need to replicate a bunch of code or link
against another library. if jackd was a commonly executed command for
users, i could justify that. as it is, i can't.
--p
12:55 p.m.
New subject: [linux-audio-dev] Linux Audio Hardware Selection
On Friday 24 January 2003 17.27, Paul Davis wrote:
[...]
Seems like it would be useful for the "no jackd" case, though. (Or
you'd have to force code changes upon applications anyway.)
For Kobo Deluxe, I just hacked a simple integrated command line and
config file parser. Inherit the parser class, add your argument
variables and implement a function that registers the variables. Then
tell it to read your config file and/or hand it argc + argv. You can
have default values and check whether default values were overidden,
and there's support for integers, floats, switches and strings.
Unfortunately, it's in C++, though the actual code is mostly C style,
and shouldn't be too hard to port. (The key registering won't look as
sexy, but that's no major issue.)
Licence is LGPL, like most of my engine/lib sort of stuff. I don't
have it as a separate package, but that can be arranged if there's
interest.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
(btw, why jackd
doesn't read /etc/jackrc or ~/.jackrc ?)
because that means we have a config file, which means we need a
config file parser, which means we need to replicate a bunch of
code or link against another library. if jackd was a commonly
executed command for users, i could justify that. as it is, i
can't.
1:25 p.m.
New subject: [linux-audio-dev] Linux Audio Hardware Selection
(btw, why jackd doesn't read /etc/jackrc or
~/.jackrc ?)
because that means we have a config file, which means we need a
config file parser, which means we need to replicate a bunch of
code or link against another library. if jackd was a commonly
executed command for users, i could justify that. as it is, i
can't.
1:51 p.m.
New subject: [linux-audio-dev] Linux Audio Hardware Selection
On Friday 24 January 2003 18.22, Paul Davis wrote:
Seems like it would be useful for the "no jackd" case, though. (Or
you'd have to force code changes upon applications anyway.)
For Kobo Deluxe, I just hacked a simple integrated command line
and config file parser. Inherit the parser class, add your
argument
there are plenty of decent config file parsers floating around.
the goal is to avoid JACK requiring other libraries, as much as
possible.
Yeah. The point is that it's just two files you throw into your
project. Not incredibly sexy, but it works for tiny things that
evolve very slowly or not at all.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
(btw, why jackd
doesn't read /etc/jackrc or ~/.jackrc ?)
because that means we have a config file, which means we need a
config file parser, which means we need to replicate a bunch of
code or link against another library. if jackd was a commonly
executed command for users, i could justify that. as it is, i
can't. 
2:05 p.m.
New subject: [linux-audio-dev] Linux Audio Hardware Selection
On Fri, Jan 24, 2003 at 11:27:12 -0500, Paul Davis wrote:
What about having a simple config file that is just a set of default
options, eg. /root/.jackrc:
-R -d alsa -d Hammerfall -r 44100 -p 256
Then this can be chopped up and prepended to argv[] before being thrown at
the argv parser.
It doesn't work as well as it might because of the -d thing (so you cant
override the driver easily), but you can still override the rate, number
of periods etc.
- Steve
not at all. it would allow programs to be run with no
context switch
overhead if they are started alone without jackd, which would be
rather nice. we need to get in-process clients done first, though.
Agreed and agreed.
(btw, why jackd
doesn't read /etc/jackrc or ~/.jackrc ?)
because that means we have a config file, which means we need a config
file parser, which means we need to replicate a bunch of code or link
against another library. if jackd was a commonly executed command for
users, i could justify that. as it is, i can't. 
3:41 p.m.
New subject: [linux-audio-dev] Linux Audio Hardware Selection
(btw, why jackd doesn't read /etc/jackrc or
~/.jackrc ?)
What about having a simple config file that is just a
set of default
options, eg. /root/.jackrc:
-R -d alsa -d Hammerfall -r 44100 -p 256
Then this can be chopped up and prepended to argv[] before being thrown at
the argv parser.
It doesn't work as well as it might because of the -d thing (so you cant
override the driver easily), but you can still override the rate, number
of periods etc.
Why not just distribute an /etc/init.d/jackd script? It would be
useful, and such a script can easily read config files with no extra
library dependencies in JACK.
--
Jack O'Quin
Austin, Texas, USA
BTW, like everyone else, I like Takashi and Paul's idea of running the
JACK engine in-process if libjack finds that no daemon is running.
2:33 p.m.
New subject: [linux-audio-dev] Linux Audio Hardware Selection
(btw, why jackd
doesn't read /etc/jackrc or ~/.jackrc ?)
because that means we have a config file, which means we need a config
file parser, which means we need to replicate a bunch of code or link
against another library. if jackd was a commonly executed command for
users, i could justify that. as it is, i can't. 
2:36 p.m.
New subject: [linux-audio-dev] Linux Audio Hardware Selection
On Fri, Jan 24, 2003 at 11:27:12AM -0500, Paul Davis wrote:
i've had the same idea. my approach would
basically be to have libjack
try to contact the server. if it fails, then it just starts up a
thread to run the audio loop, and then instantiate the client as an
in-process client.
i must be missing the point. Where does the audio go? isn't jackd
responsible for connecting to alsa?
--
Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's X-PERVERT WHO LIVES NEXT DOOR!
(random hero from isometric.spaceninja.com)
2:44 p.m.
New subject: [linux-audio-dev] Linux Audio Hardware Selection
On Friday 24 January 2003 19.29, Paul Winkler wrote:
On Fri, Jan 24, 2003 at 11:27:12AM -0500, Paul Davis
wrote:
Well, yes - but if the lib fails to find jackd, it can do pretty much
anything, instead of just failing. Like trying try to set up some
direct audio I/O instead and "fake" jackd. :-)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
i've had the same idea. my approach would
basically be to have
libjack try to contact the server. if it fails, then it just
starts up a thread to run the audio loop, and then instantiate
the client as an in-process client.
i must be missing the point. Where does the audio go? isn't jackd
responsible for connecting to alsa?
7938
days inactive
7938
days old
linux-audio-dev@lists.linuxaudio.org
11 comments
8 participants
participants (8)
-
David Olofson -
Fernando Pablo Lopez-Lezcano -
Jack O'Quin -
Marc Titinger -
Paul Davis -
Paul Winkler -
Steve Harris -
Takashi Iwai