If low-latency is of minor importance, and the goal is to 'just' get that
OSS application's data into or from JACK, the LD_PRELOAD could be an viable
option, or otherwise simply creating some (kernel) loopback device. Though
not a candidate for the 'most beautiful design' contest it would get th
Joern Nettingsmeier wrote:
> François Déchelle wrote:
>
>
> iiuc, jack does not access the hardware directly. instead it uses a
> plugin which in turn talks to the alsa kernel driver or possibly other
> systems (not implemented).
JACK is the only process that opens a ALSA handle referring to
François Déchelle wrote:
>
>
> If I understand clearly the point, the foreseen working scheme would
> be the following, using alsaserver and JACK:
>
> App1 <->|<-> OSS |<-> ALSA<->| JACK <-> PCM HW
> App2 <->||server |
> ... <->|| |
>
Vincent Touquet wrote:
> On Mon, Jun 10, 2002 at 06:09:01PM -0300, Juan Linietsky wrote:
> (cut)
>
>>I think Kai Vehmanen did a much better job explaining this than
>>myself, since I dont know the internals of alsalib. I'll just repost
>>what he said:
>>
> (cut)
>
> Ok :)
> If you want what Kai
Juan Linietsky wrote:
> I choose my favorite audio composing app, say muse.
> Now i choose my favorite softsynth, iiwusynth.
> Alsa works great for this... now
> Using a theorical audio routing api Iiwusynth will
> proovide me with the following audio sources: A stereo channel (gobal
> mix) 16 m
On Mon, Jun 10, 2002 at 06:09:01PM -0300, Juan Linietsky wrote:
(cut)
>I think Kai Vehmanen did a much better job explaining this than
>myself, since I dont know the internals of alsalib. I'll just repost
>what he said:
(cut)
Ok :)
If you want what Kai and Taybin are referring to,
its doable, it
On Mon, 10 Jun 2002 22:49:01 +0200
Vincent Touquet <[EMAIL PROTECTED]> wrote:
> (cut)
> >I'm afraid i didnt make myself clear. I tried to expain this in
> >previous mails, but I think i'm failing so far.
> >I perfectly understand what JACK is, but as I said before,
> >it's primarily meant for lo
On Mon, 10 Jun 2002, Juan Linietsky wrote:
> Yes! This is super just exactly accuratedly the point of what I was
> proposing. My point is simply that not all apps you'd like to
> route/interconnect need low latency, thus there is no need to use JACK
> natively on them. When the app tries to open
(cut)
>I'm afraid i didnt make myself clear. I tried to expain this in
>previous mails, but I think i'm failing so far.
>I perfectly understand what JACK is, but as I said before,
>it's primarily meant for low latency stuff.
>So my proposal consisted in two things.
>1-The first one is to proovid
On Mon, 10 Jun 2002 09:36:30 -0400
Paul Davis <[EMAIL PROTECTED]> wrote:
> >Yeah, but what I mean is 2 things, first that you should be able to
> >change transparently where the app is sending the data, without the
> >app noticing, and second that such configuration shouldnt be stored
> >by the a
hi !
in reply to a posting by juan linietsky, Paul Davis wrote:
>
[allowing multiple apps to play at the same time (esound-style) on
hardware that does not support multi-open]
>
> * ALSA already has the "share" PCM device type which allows
> multiple access to the same underlying hardware
>Since I have hardly looked at Jack, and definately not tried to use it (as a
>developer) I can't really comment on the design.
but you still say:
>- harder to understand "what" goes "where", Jörn has made some
>nice schemantics but the design is rather complex, a novice would not
>understand i
>Yeah, but what I mean is 2 things, first that you should be able to
>change transparently where the app is sending the data, without the
>app noticing, and second that such configuration shouldnt be stored by
>the app but from an abstracted app/interface that handles connections.
You're asking f
Hi guys,
being mainly a lurker (and (potentially) a user) I may not have a say, but anyway...
>
> No, allow me to explain better why I think supporting JACK is
> pointless and why I wouldnt do it. I'll give you all the reasons I can
> think of.
>
> 1-It's not a standard. ALSA/OSS are. If i wan
On Mon, 10 Jun 2002 01:38:10 -0400
Paul Davis <[EMAIL PROTECTED]> wrote:
> >Here's a problem I commonly find in existing audio apps or in
> >programming audio apps: Audio routing.
> >
> >The way things work now, it's hard for apps to implement a standard
> >way of:
>
> First, you can't do any be
>Here's a problem I commonly find in existing audio apps or in
>programming audio apps: Audio routing.
>
>The way things work now, it's hard for apps to implement a standard
>way of:
First, you can't do any better on MacOS or Windows, because ReWire or
DirectConnect are the only (low latency) opt
Here's a problem I commonly find in existing audio apps or in
programming audio apps: Audio routing.
The way things work now, it's hard for apps to implement a standard
way of:
-Route audio from an app to another
-Share audio devices/routes
-Apply Audio modifiers (Effects)
LADSPA is great for i
17 matches
Mail list logo
