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
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
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
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
On Friday 24 January 2003 17.27, Paul Davis wrote:
[...]
(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
(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
On Friday 24 January 2003 18.22, Paul Davis wrote:
(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
On Fri, Jan 24, 2003 at 11:27:12 -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.
Agreed and agreed.
(btw, why
(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
On Friday 24 January 2003 19.29, Paul Winkler wrote:
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
(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?)
On Fri, Jan 24, 2003 at 11:27:12 -0500, Paul Davis wrote:
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
Hello,
I've been watching the mail on this list for some time. I've looked at as
much documentation on the web as I can find. From alsa's web site to the
linux audio developers web site. What I would like to know (or see in a
FAQ or HOWTO) is how to setup a linux pro audio system. With
12 matches
Mail list logo
