On Thu, 14 Jun 2001, Paul Davis wrote:
Here we get to the crux of my problem with understanding GLAME's
async model:
Note that the following is not true for GLAME, but for my LAAGA approach
(which shares with GLAME the async. model and the explicit buffer
management) - GLAME has input and
On Thu, 14 Jun 2001, Vincent Touquet wrote:
Maybe we could nail the synchronous vs. asynchronous discussion down to
this:
Synchronous (blocking) programming techniques work perfectly for low to
medium loads and has the _lowest_ latency.
Yes. It gets lowest possible latency. But for
Are you now speaking of a physical setup or about the equivalent
(i.e. all nodes above exchanged with an app) software setup?
either.
For the physical setup you plug before the quadra (i.e. a connection
that is not visible above)? Or you plug between the quadra and the
mixer?
before the
On Fri, 15 Jun 2001, Paul Davis wrote:
So there remains the case that you dont plug anything, but the quadra
app simply stops producing output with the connection still active.
This is obviously a bug in the quadra app (it has to be considered as
such for my model as else the mixer will
Paul Davis [EMAIL PROTECTED] writes:
When I route signals from a mixer
strip on either a digital or analog mixer onto a bus, there is no
additional node between the strip (which has gain control etc.) and
the bus.
Your model requires that either the bus be able to handle mixing
(which is
On Wed, 13 Jun 2001, Paul Davis wrote:
Ok, we seem to know what both approaches do and what advantages and
disadvantages are (but we dont agree on them). So I think we either
need input from some other guy or we can stop discussion.
More or less true, I agree. But not quite :)
So I'll
Richard Guenther wrote:
On Thu, 14 Jun 2001, Paul Davis wrote:
Busses dont scale. You use Crossbars. Think of a mix node as of a
crossbar.
How does a bus not scale, and what's a crossbar?
Crossbar is a graph - a bus is not a graph. A bus has collisions for
more than 2 members, a
On Wed, 13 Jun 2001, Paul Davis wrote:
automatic mixing means that clients don't have to deal with the
concept of connections or buffers or mixing. if the user
connects 6 outputs to a single input, the client doesn't have to
Not possible with my approach - there is no input port :) So I
Ok, we seem to know what both approaches do and what advantages and
disadvantages are (but we dont agree on them). So I think we either
need input from some other guy or we can stop discussion.
More or less true, I agree. But not quite :)
Perhaps I have time to do an implementation of my API,
Paul Davis wrote:
This is another reason I dont like signals - signals
and threads dont mix portably, with read()/write()/select() you have
maximum portability (even NT might support such style of operation).
But of course using signals is implementation dependant and no
Yes, your right, they are not very portable. But read/write can't work
without horrendous complexity unless you have fd passing, which is
also not portable. But you're also right that its not part of the API,
so we don't have to worry too much.
You're forgetting Unix socket/named pipe
Hi!
Just to speak with code, I've (quick and dirty) hacked something
up which is different from Pauls approach. Its in commented
header style, it helps if you know GLAME, but I'll try to
elaborate. Note that I dont explicitly show implementation details
(f.i. if using fds or not - I'm less
Just to speak with code, I've (quick and dirty) hacked something
up which is different from Pauls approach. Its in commented
header style, it helps if you know GLAME, but I'll try to
elaborate. Note that I dont explicitly show implementation details
(f.i. if using fds or not - I'm less convinced
parameter changes etc...
Kard.
- Original Message -
From: Richard Guenther [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, June 12, 2001 9:55 AM
Subject: [linux-audio-dev] LAAGA API Proposal
Hi!
Just to speak with code, I've (quick and dirty) hacked something
up which is different
Before answering the following questions I like to tell about my view
of the typical usage pattern from the UI point of view. Lets suppose
[ ... description elided ... ]
yes, that more or less matches my notion of things closely enough that
we clearly are aiming at the same general idea.
I
15 matches
Mail list logo
