[linux-audio-dev] Idea: fake OSS passback driver

[Daniel Risacher]

I had an idea the other day, and I wanted to bounce it around for
feedback before I invest any real time into it. While I have done
some minor kernel hackng over the years, I am not experienced in the
audio subject area.

Background:

Despite the various and sundry advances in linux audio, I find there
are still legacy apps that are built against the OSS API. This is
problematic since the legacy OSS model has blocking semantics. To get
multiple audio streams, one must use an audio server such as esd,
aRts, etc. Wouldn't it be nice if all the legacy apps "just worked"?
Without blocking each other?

Idea:

Suppose one were to write a kernel module that implemented the OSS
API, but had non-blocking semantics, and instead of driving a sound
card, the module encapsulated the OSS API calls somehow and passed
them back to a user-space audio server.

Ao, for example: suppose we had a system with alsa and the proposed
passback driver. xmms is playing via esd-passback-alsa, which is a
modified version that supports input from the passback driver and
outputs via alsa. The user fires up Ogle, which only has OSS output
code (I'm not sure if this is true; just an example). /dev/dsp is the
passback driver, and when ogle opens it, it succedes, even through
someone else is using the sound card (esd). The passback driver
"passes back" all of Ogle's ioctls to a modified version of esd,
which, in turn multiplexes the audio with whatever else is playing
(xmms, in this example), and plays it via alsa.

I'm not precisely sure how I would to handle the actual "passing
back". Probably a separate device file /dev/dsp-passback, which is
read by the audio server.

Can anyone say why this idea can not, or should not be implemented?

Now that I've articulated the idea, would anyone care to take over the
implementation?

[Jan Weil]

On Sun, 2004-02-01 at 11:02, Daniel Risacher wrote:
> Background:
>
> Despite the various and sundry advances in linux audio, I find there
> are still legacy apps that are built against the OSS API. This is
> problematic since the legacy OSS model has blocking semantics. To get
> multiple audio streams, one must use an audio server such as esd,
> aRts, etc. Wouldn't it be nice if all the legacy apps "just worked"?
> Without blocking each other?
>
> Idea:
>
> Suppose one were to write a kernel module that implemented the OSS
> API, but had non-blocking semantics, and instead of driving a sound
> card, the module encapsulated the OSS API calls somehow and passed
> them back to a user-space audio server.

I might be wrong, but I think this is already possible using the dmix
plugin from alsa-lib.

You'll have to setup a dmix slave and make your OSS emulation use it.

Never tried it myself, though.
So take this with the usual grain of salt.

Jan

[Florian Schmidt]

On Sun, 01 Feb 2004 12:05:19 +0100
Jan Weil <***@web.de> wrote:

> > Suppose one were to write a kernel module that implemented the OSS
> > API, but had non-blocking semantics, and instead of driving a sound
> > card, the module encapsulated the OSS API calls somehow and passed
> > them back to a user-space audio server.
>
> I might be wrong, but I think this is already possible using the dmix
> plugin from alsa-lib.
>
> You'll have to setup a dmix slave and make your OSS emulation use it.
>
> Never tried it myself, though.
> So take this with the usual grain of salt.
>

Yes, it is possible using the aoss script. But i have the feeling that
this still has problems with mmapped mode.

Well, here you go:

-----.asoundrc
#asym fun start here. we define one pcm device called "dmixed"
pcm.dmixed {
ipc_key 1025
type dmix
slave.pcm "hw:0,0"
}

#one called "dsnooped" for capturing
pcm.dsnooped {
ipc_key 1026
type dsnoop
slave.pcm "hw:0,0"
}

#asymed to combine the two
pcm.asymed {
type asym
playback.pcm "dmixed"
capture.pcm "dsnooped"
}

#a quick plug plugin for above device to do the converting magic for
#alsa apps [saves typing the "plug:" prefix in config dialogs and when
#testing with aplay]
pcm.pasymed {
type plug
slave.pcm "asymed"
}

#a ctl device to keep xmms happy
ctl.pasymed {
type hw
card 0
}


#ok and these are the two definitions used by aoss:
pcm.dsp0 {
type plug
#i could have used "pasymed" here, but then we would have the plug
thingie twice in the path
slave.pcm "asymed"
}

ctl.mixer0 {
type hw
card 0
}
-----.asoundrc

Well, anyways, with above definitions in your .asoundrc it should be
possible to use

aoss your_oss_app

and it should automatically use the "asymed" device. Now point your alsa
apps to "pasymed" and you should be ready to go. On my machine though,
sending to asymed or pasymed results in no error messages, but also in
no sound. So, to test an mmapped game i change the above definition of
pcm.dsp0 to

pcm.dsp0 {
type plug
slave.pcm "hw:0,0"
}

This disables the mixing, but at least i hear something. So when
starting enemy territory with

aoss et

i do get sound, but it crackles and the sound seems to get stuck
sometimes [buffers repeating, etc..], sometimes it also off for a minute
or so and then returns..

I also don't know if the ctl.mixer0 is honoured. i read that somewhere.
The aoss manpage only talks about pcm.dsp0.

Flo

--
signature :)

[Frank Barknecht]

Hallo,
Daniel Risacher hat gesagt: // Daniel Risacher wrote:

> Idea:
>
> Suppose one were to write a kernel module that implemented the OSS
> API, but had non-blocking semantics, and instead of driving a sound
> card, the module encapsulated the OSS API calls somehow and passed
> them back to a user-space audio server.
>
> Now that I've articulated the idea, would anyone care to take over the
> implementation?

Isn't this already done and described here:
http://alsa.opensrc.org/index.php?page=DmixPlugin
?

ciao
--
Frank Barknecht _ ______footils.org__

[RTaylor]

The label "Frank Barknecht" hathe been affixed to this message,
>Daniel Risacher hat gesagt: // Daniel Risacher wrote:
>
>> Idea:
>>
>> Suppose one were to write a kernel module that implemented the OSS
>> API, but had non-blocking semantics, and instead of driving a sound
>> card, the module encapsulated the OSS API calls somehow and passed
>> them back to a user-space audio server.
>>
>> Now that I've articulated the idea, would anyone care to take over the
>> implementation?
>
>Isn't this already done and described here:
>http://alsa.opensrc.org/index.php?page=DmixPlugin

Maybe something like a meta-driver that you could call from anything... a sort
of layer between the actual hardware setup and the rest of the system so that
application developers could simply reference the one consistent object without
dealing with any other issues.

Or will Dmix do that?
--
See these tears so blue. An ageless heart that can never mend.
Tears can never dry. A judgement made can never bend.
...
And I've been putting out fire with gasoline...
{Dave}

[Paul Davis]

>Can anyone say why this idea can not, or should not be implemented?

i don't think you can have both (all?) things you want.

either /dev/dsp (the OSS PCM data device) is being emulated by ALSA,
or by something like your idea, or its being handled by native OSS.

if its handled by ALSA, then you just need to (1) use ALSA's
facilities to allow this and (2) assist ALSA developers in debugging
rogue and errant behaviour with certain applications. ALSA can do
this, but its very hard for regular mortals to understand how to
configure it and according to some reports it still has problems,
especially with mmap-based applications (the infamous Quake being the
obvious example).

if its handled by something like your idea, then ALSA apps on the same
machine can't use the device.

if its handled by OSS, then you would still need an LD_PRELOAD hack of
some form (such as ALSA's "aoss" script) to make it work.

the biggest mistake (free) OSS makes it to put all of its functionality into
the kernel without a "shared layer" that all drivers use. this makes
it practically impossible to implement "OSS-wide" features like device
sharing, even if you thought it would be good to put it into the
kernel. why? because you would have to add it to each and every driver
individually.

ALSA's approach of putting additional functionality in user space
makes it much more flexible, and its internal design within the kernel
means that all drivers share a large blob of common code, enabling
features to be added that extend across all of them.

if you have energy to burn evangelizing this, why don't you instead
lobby freedesktop.org to adopt a system-wide callback-driven API for
audio along the same lines as OS X has with CoreAudio and its
AudioUnits API? then the situation can be dealt with once and for
all, and Linux ends up with a consistent, uniform, efficient and
powerful audio API rather than continuing to push hardware abstraction
layers like OSS and ALSA as the primary programming API for audio.

--p

ps. in case you didn't know, there is already an implementation of
such a system, which already runs almost all "music" apps
written for Linux and also runs on OS X. it wasn't written
to be suitable for all kinds of applications, but it probably
could be made to be so rather easily. http://jackit.sf.net.
in addition, there is an API that has existed for a long time
that promotes the callback style, and allows software to be
ported to all Linux drivers, Mac OS (9 and X) and Windows (ASIO
and MME and WDM). its called PortAudio.

[Dave Robillard]

On Sun, 2004-02-01 at 05:02, Daniel Risacher wrote:
> Despite the various and sundry advances in linux audio, I find there
> are still legacy apps that are built against the OSS API. This is
> problematic since the legacy OSS model has blocking semantics. To get
> multiple audio streams, one must use an audio server such as esd,
> aRts, etc. Wouldn't it be nice if all the legacy apps "just worked"?
> Without blocking each other?

Who really cares? The apps are going to get ported to alsa (or better
yet jack) eventually anyway. Otherwise, may they rest in peace.

Instead of spending that much time and effort solving a problem that
/barely/ exists, just port the apps!

-Dave

[Jussi Laako]

On Sun, 2004-02-01 at 12:02, Daniel Risacher wrote:

> aRts, etc. Wouldn't it be nice if all the legacy apps "just worked"?
> Without blocking each other?

This has already been implemented in commercial version of OSS. With
samplerate conversion and mixing.


--
Jussi Laako <***@pp.inet.fi>

[Dave Robillard]

Screenshot:
http://chat.carleton.ca/~drobilla/patchbay.png

Waiting on the Jack callback issue to make a pre-release. Anyway,
basically I need a name for this thing, and any (UI) suggestions anyone
has.

Eventually it will be a combined jack/alsa patch bay, so it'd be nice if
the name reflected both jack and alsa, but I'd rather not have "Linux"
in the title.

Any interface ideas (other than the color of the modules ;) ) are
welcome... and if anyone has ideas for an elegant
automatic-module-placement solution, I'd love to hear them. Right now
they're just randomly placed. (Are there known algorithms in graph
theory for this sort of thing?)

-Dave

[Paul Winkler]

On Mon, Feb 02, 2004 at 12:37:32AM -0500, Dave Robillard wrote:
> Screenshot:
> http://chat.carleton.ca/~drobilla/patchbay.png

nice.

> Waiting on the Jack callback issue to make a pre-release. Anyway,
> basically I need a name for this thing, and any (UI) suggestions anyone
> has.

One thing that might be handy would be a "show connected ports only"
button for each client. So you could hide e.g. all those track_out_N
ports for hydrogen.

--

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's THE ENVIRONMENTAL IMPACT REPORT!
(random hero from isometric.spaceninja.com)

[Dave Robillard]

On Mon, 2004-02-02 at 01:11, Paul Winkler wrote:
> On Mon, Feb 02, 2004 at 12:37:32AM -0500, Dave Robillard wrote:
> > Screenshot:
> > http://chat.carleton.ca/~drobilla/patchbay.png
>
> nice.
>
> > Waiting on the Jack callback issue to make a pre-release. Anyway,
> > basically I need a name for this thing, and any (UI) suggestions anyone
> > has.
>
> One thing that might be handy would be a "show connected ports only"
> button for each client. So you could hide e.g. all those track_out_N
> ports for hydrogen.

Not a bad idea.. certainly not on by default, but it would be nice to
have hydrogen appear sane.

On the list..

[Marcus Andersson]

Dave Robillard wrote:

>Screenshot:
>http://chat.carleton.ca/~drobilla/patchbay.png
>
>Waiting on the Jack callback issue to make a pre-release. Anyway,
>basically I need a name for this thing, and any (UI) suggestions anyone
>has.
>
>Eventually it will be a combined jack/alsa patch bay, so it'd be nice if
>the name reflected both jack and alsa, but I'd rather not have "Linux"
>in the title.
>
>Any interface ideas (other than the color of the modules ;) ) are
>welcome... and if anyone has ideas for an elegant
>automatic-module-placement solution, I'd love to hear them. Right now
>they're just randomly placed. (Are there known algorithms in graph
>theory for this sort of thing?)
>
>

A simple idea would be to place them randomly initially, and thereafter
always place them where the user put them the last time. My guess is
that a typical user will have the same applications running from session
to session, and would prefer if they where positioned at the same place
every time.

Marcus

[Dave Robillard]

On Mon, 2004-02-02 at 01:20, Marcus Andersson wrote:
> A simple idea would be to place them randomly initially, and thereafter
> always place them where the user put them the last time. My guess is
> that a typical user will have the same applications running from session
> to session, and would prefer if they where positioned at the same place
> every time.

I do plan on having persistance (saving "states"), hopefully LADCCA
integrated, but it would be nice for the default placement to be
something sane.

At the very least I can put the modules in empty space so there's no
overlap. Maybe this plus some simple rules (ie "put modules with only
output ports to the left") will be good enough..

-Dave

[Steve Harris]

On Mon, Feb 02, 2004 at 12:37:32 -0500, Dave Robillard wrote:
> Screenshot:
> http://chat.carleton.ca/~drobilla/patchbay.png

Hey nice! antialiased too :)

> Any interface ideas (other than the color of the modules ;) ) are
> welcome... and if anyone has ideas for an elegant
> automatic-module-placement solution, I'd love to hear them. Right now
> they're just randomly placed. (Are there known algorithms in graph
> theory for this sort of thing?)

Yeah, there is, try citeseer or maybe the dot people have something?
http://www.research.att.com/sw/tools/graphviz/refs.html

The problem you will find is hat most gaph algorithms dont care about
consitency of positioning between graph changes (eg. adding a new client),
but you could have an "organise" button to hit if it gets messy.

- Steve

[Dave Robillard]

On Mon, 2004-02-02 at 04:16, Steve Harris wrote:
> On Mon, Feb 02, 2004 at 12:37:32 -0500, Dave Robillard wrote:
> > Screenshot:
> > http://chat.carleton.ca/~drobilla/patchbay.png
>
> Hey nice! antialiased too :)

Antialiased? Heck, the connections are translucent, true story - you
can read right through 'em. I hardly believe it myself. :)

> > Any interface ideas (other than the color of the modules ;) ) are
> > welcome... and if anyone has ideas for an elegant
> > automatic-module-placement solution, I'd love to hear them. Right now
> > they're just randomly placed. (Are there known algorithms in graph
> > theory for this sort of thing?)
>
> Yeah, there is, try citeseer or maybe the dot people have something?
> http://www.research.att.com/sw/tools/graphviz/refs.html

Already made tools are even better. I'll look into it.

> The problem you will find is hat most gaph algorithms dont care about
> consitency of positioning between graph changes (eg. adding a new client),
> but you could have an "organise" button to hit if it gets messy.

I guess it could be an option (reorganize the whole graph when a module
is added or just place the new one as best you can)..

[j***@dis-dot-dat.net]

On Mon, 02 Feb, 2004 at 12:37AM -0500, Dave Robillard spake thus:
> Screenshot:
> http://chat.carleton.ca/~drobilla/patchbay.png

I just dribbled on my keyboard. Just yesterday, I decided that I'd do
something like this if I ever got the time. Or the skill ;)

[Dave Robillard]

On Mon, 2004-02-02 at 00:37, Dave Robillard wrote:
> Screenshot:
> http://chat.carleton.ca/~drobilla/patchbay.png

I need some UI opinions here....

What's the best way to disconnect ports? I've thought of:

- putting a handle in the middle of connection lines, so you can
right-click them to get a menu

- making the lines really thick, same deal as above

- just being able to right click a port and disconnect all connections
(with the obvious disadvantage of forcing you to maybe disconnect
something you don't want to)

- clicking on the source port then the dest port (just like connecting),
except if they're already connected, disconnect them


Ideas? Opinions?

-Dave

[t***@informatik.uni-bremen.de]

On Thu, Feb 05, 2004 at 09:51:42PM -0500, Dave Robillard wrote:
> On Mon, 2004-02-02 at 00:37, Dave Robillard wrote:
> > Screenshot:
> > http://chat.carleton.ca/~drobilla/patchbay.png
>
> I need some UI opinions here....
>
> What's the best way to disconnect ports? I've thought of:
>
> - putting a handle in the middle of connection lines, so you can
> right-click them to get a menu

- or select them and press del.
>
> - making the lines really thick, same deal as above
>
> - just being able to right click a port and disconnect all connections
> (with the obvious disadvantage of forcing you to maybe disconnect
> something you don't want to)

- right click on a port makes a menupopup where you can select to
disconnect connection to foo or all connections.
like in galan. i find it quite useable.

>
> - clicking on the source port then the dest port (just like connecting),
> except if they're already connected, disconnect them
>
>
> Ideas? Opinions?
>
> -Dave
>

--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language

[Steve Harris]

On Thu, Feb 05, 2004 at 09:51:42 -0500, Dave Robillard wrote:
> - just being able to right click a port and disconnect all connections
> (with the obvious disadvantage of forcing you to maybe disconnect
> something you don't want to)

Context menu with disconnecat all + options for the invidual 'wires' if
there are multiple connections.

- Steve

[Dave Robillard]

On Thu, 2004-02-05 at 21:51, Dave Robillard wrote:
> On Mon, 2004-02-02 at 00:37, Dave Robillard wrote:
> > Screenshot:
> > http://chat.carleton.ca/~drobilla/patchbay.png
>
> I need some UI opinions here....
>
> What's the best way to disconnect ports? I've thought of:

So it seems the concensus is right clicking to get a disconnect menu, or
click on one port and then the other like connecting?

They're certainly not mutually exclusive, so I'll do both (I did the
"Disconnect All" menu item last night actually)

Thanks all

-Dave

[Nathaniel Virgo]

Dave Robillard wrote:

>Screenshot:
>http://chat.carleton.ca/~drobilla/patchbay.png
>
>Waiting on the Jack callback issue to make a pre-release. Anyway,
>basically I need a name for this thing, and any (UI) suggestions anyone
>has.
>
>Eventually it will be a combined jack/alsa patch bay, so it'd be nice if
>the name reflected both jack and alsa, but I'd rather not have "Linux"
>in the title.
>
>Any interface ideas (other than the color of the modules ;) ) are
>welcome... and if anyone has ideas for an elegant
>automatic-module-placement solution, I'd love to hear them. Right now
>they're just randomly placed. (Are there known algorithms in graph
>theory for this sort of thing?)
>
>-Dave
>
>
>
>
>
>
Wow. That's really cool. It's exactly what I wanted to do ages ago.
The best names I thought of were JackBay and MetaModular - you're
welcome to either.

Here are some GUI ideas I thought might be cool or useful:

The wires would look even cooler if they were splines, so that they came
out of their ports horizontally and gracefully curved their way to their
destination :) It looks cool and feedback loops display better. (if
you're using something like a GTK canvas it's pretty easy too)

When ardour is in use I imagine a feature where the output ports of a
program can appear as a seperate module from the input ports would be
handy (so that [ardour output]->[effects chain]->[ardour input] can be
drawn without a loop).

Being able to shift-drag to move all the wires connected to one port
directly to another would be really handy sometimes, as would click-drag
to copy connections (I often find myself doing these things by hand in
other apps).

Another potentially handy idea is to make it so that if a module is put
next to another so that the input ports of one line up to the output
ports of another, they automatically become connected.


A very ambitious idea would be to allow LADSPA plugins to be embedded
into the UI so that to the user it looks as if they've been put straight
into the JACK graph. In reality they would not be connected via JACK at
all of course.


Anyway, it looks great, I can't wait to try it out.

-Nathaniel

[Dave Robillard]

On Mon, 2004-02-09 at 10:56, Nathaniel Virgo wrote:
> Dave Robillard wrote:
>
> >Screenshot:
> >http://chat.carleton.ca/~drobilla/patchbay.png
> >
> >Waiting on the Jack callback issue to make a pre-release. Anyway,
> >basically I need a name for this thing, and any (UI) suggestions anyone
> >has.
> Here are some GUI ideas I thought might be cool or useful:
>
> The wires would look even cooler if they were splines, so that they came
> out of their ports horizontally and gracefully curved their way to their
> destination :) It looks cool and feedback loops display better. (if
> you're using something like a GTK canvas it's pretty easy too)

I was thinking about that (or even using bezier curves to have
connections cleverly avoid modules if possible).. If there's support in
the canvas it'd be easy enough. Otherwise... well, there's only so many
hours in the day. ;)

> When ardour is in use I imagine a feature where the output ports of a
> program can appear as a seperate module from the input ports would be
> handy (so that [ardour output]->[effects chain]->[ardour input] can be
> drawn without a loop).

I planned on this from day one, not because of ardour but because of
alsa_pcm. Audio input and output being on the same module always screws
things up pretty bad when you're running loops (like ardour).

> Being able to shift-drag to move all the wires connected to one port
> directly to another would be really handy sometimes, as would click-drag
> to copy connections (I often find myself doing these things by hand in
> other apps).

Good idea.

> Another potentially handy idea is to make it so that if a module is put
> next to another so that the input ports of one line up to the output
> ports of another, they automatically become connected.

Not sure about that one.. how many cases are there really going to be
where this happens, and all ports that should be connected are beside
each other?

> A very ambitious idea would be to allow LADSPA plugins to be embedded
> into the UI so that to the user it looks as if they've been put straight
> into the JACK graph. In reality they would not be connected via JACK at
> all of course.

This was touched upon before; but I'm not sure if the ideas of a modular
synth/effects rack and a jack patch bay should really be slammed
together. A few people seem to think it'd be good though.

Of course, it'd require a whole lot of time (ie rewrite) on my part, and
with my current workload something like that just isn't going to happen
anytime soon. :/ (I have to deal with the ALSA problem first)

> Anyway, it looks great, I can't wait to try it out.

Thanks; I'm /trying/ to get a prerelease out! (even though ATM it
depends on a simple jack patch). I might have a free day this week
sometime..

-Dave

[Steve Harris]

On Mon, Feb 09, 2004 at 02:13:57 -0500, Dave Robillard wrote:
> > When ardour is in use I imagine a feature where the output ports of a
> > program can appear as a seperate module from the input ports would be
> > handy (so that [ardour output]->[effects chain]->[ardour input] can be
> > drawn without a loop).
>
> I planned on this from day one, not because of ardour but because of
> alsa_pcm. Audio input and output being on the same module always screws
> things up pretty bad when you're running loops (like ardour).

This should be detectable automatically by looking at the
JackPortIsTerminal flag or whatever its called. Though being able to
override it by hand is good too.

- Steve

[Dave Robillard]

Through a painful process I'd rather not go into, I discovered that Jack
will not run in realtime mode with my Radeon's 3d drivers loaded.. I get
the error "cannot lock down memory for RT thread"

My idea-for-the-day was visualisation of realtime jack audio (from live
performance); needless to say my day ended up far less interesting than
I had hoped. :)

Is this a known problem, or screwy system configuration on my part?

(XFree-4.3.0, Radeon9000 Pro, Linux 2.4.24 lowlat)

-Dave

[Dave Griffiths]

jack works with intel830 DRI

see http://www.pawfal.org/Software/fluxus/ (you might be interested) -
it used to have a native jack interface, but now works through
portaudio.

On Mon, 2004-02-09 at 23:26, Dave Robillard wrote:
> Through a painful process I'd rather not go into, I discovered that Jack
> will not run in realtime mode with my Radeon's 3d drivers loaded.. I get
> the error "cannot lock down memory for RT thread"
>
> My idea-for-the-day was visualisation of realtime jack audio (from live
> performance); needless to say my day ended up far less interesting than
> I had hoped. :)
>
> Is this a known problem, or screwy system configuration on my part?
>
> (XFree-4.3.0, Radeon9000 Pro, Linux 2.4.24 lowlat)
>
> -Dave
--
................................. www.pawfal.org/nebogeo

[Dave Robillard]

On Mon, 2004-02-09 at 18:50, Dave Griffiths wrote:
> jack works with intel830 DRI

Hmm.. I only have Radeon's, so I'm a bit out of luck as far as testing
other cards I guess.

Anyone else have a positive/negative experience?

(For clarification, it's only realtime jack (ie jackstart -R) that
doesn't work).

> see http://www.pawfal.org/Software/fluxus/ (you might be interested) -
> it used to have a native jack interface, but now works through
> portaudio.

I remember seeing that page a little while back, I'll definately look
into it.. looks pretty crazy!

(If it's based on portaudio can I still connect it to my jack graph
somehow? Never used portaudio..)

-Dave

[Benjamin Flaming]

On Monday 09 February 2004 05:58 pm, Dave Robillard wrote:
> On Mon, 2004-02-09 at 18:50, Dave Griffiths wrote:
> > jack works with intel830 DRI
>
> Hmm.. I only have Radeon's, so I'm a bit out of luck as far as testing
> other cards I guess.
>
> Anyone else have a positive/negative experience?

No real-time JACK problems with my Radeon 7500.

|)
|)enji

[Jens M Andreasen]

On tis, 2004-02-10 at 03:45, Benjamin Flaming wrote:
> On Monday 09 February 2004 05:58 pm, Dave Robillard wrote:
> > On Mon, 2004-02-09 at 18:50, Dave Griffiths wrote:
> > > jack works with intel830 DRI
> >
> > Hmm.. I only have Radeon's, so I'm a bit out of luck as far as testing
> > other cards I guess.
> >
> > Anyone else have a positive/negative experience?
>
> No real-time JACK problems with my Radeon 7500.

I didn't know there was an optimized 3D driver for the 7500?

/jens

> |)
> |)enji
>

[Benjamin Flaming]

On Monday 09 February 2004 09:57 pm, Jens M Andreasen wrote:
> On tis, 2004-02-10 at 03:45, Benjamin Flaming wrote:
> > On Monday 09 February 2004 05:58 pm, Dave Robillard wrote:
> > > On Mon, 2004-02-09 at 18:50, Dave Griffiths wrote:
> > > > jack works with intel830 DRI
> > >
> > > Hmm.. I only have Radeon's, so I'm a bit out of luck as far as testing
> > > other cards I guess.
> > >
> > > Anyone else have a positive/negative experience?
> >
> > No real-time JACK problems with my Radeon 7500.
>
> I didn't know there was an optimized 3D driver for the 7500?

I specify "ati" as the driver in my XF86Config. As long as the "radeon" and
"agpgart" modules from my 2.4.23 kernel are loaded, DRI works just fine for
my purposes.

glxinfo | grep rendering
direct rendering: Yes

"glxgears" maximized at 1024x768 reports 176.800 FPS.

|)
|)enji

[Joern Nettingsmeier]

Dave Robillard wrote:
> On Mon, 2004-02-09 at 18:50, Dave Griffiths wrote:
>
>>jack works with intel830 DRI
>
>
> Hmm.. I only have Radeon's, so I'm a bit out of luck as far as testing
> other cards I guess.
>
> Anyone else have a positive/negative experience?

i'm using dri with an ancient 3dfx voodoo3 3000 agp card, and i have
no problems with jack in realtime mode.


--
The handles of a craftsman's tools bespeak an absolute simplicity,
the plainest forms affording the greatest range of possibilities for
the user's hand.
That which is overdesigned, too highly specific, anticipates
outcome; the anticipation of outcome guarantees, if not failure, the
absence of grace.
- William Gibson, "All Tomorrow's Parties"

Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxaudiodev.org (Linux Audio Developers)

[Dave Phillips]

Greetings:

Recently I've been having a lot of trouble with extraneous noise from
my system. Some apps are worse than others, but it does seem that
JACK-enabled apps fare the worst. Following this thread it occurred to
me that perhaps my video driver is at fault. I have a gForce2 and am
using nVidia's driver. I realize I could use the Linux kernel driver,
but I'll lose the OpenGL acceleration I need for Pd.

DRI is "off" in XF86Config, I've added the no-hlt instruction to my
lilo.conf, and I added the pci_burst option to XF86Config (though the
card is an AGP board). The worst offender right now is Csound,
especially when I run Oeyvind Brandtsegg's ImproSculpt. The noise from
the mouse movement is nasty, there are audible glitches when I switch
workspaces (I'm using the Blackbox WM) or even switch tabs with the app,
and occasionally the sound simply "derails". It's hard to describe what
happens: the sound keeps playing, it's just "zippery" for a while, then
it seems to come back to its senses and plays normally for a while
before it zips again.

I'm also one of those folks who can't get jackd to run in realtime
mode, I get the same lock-down error others have reported here. So I'm
wondering how I can best troubleshoot my system. The problem appears to
be either JACK, the video driver, or maybe something to do with disk I/O
(? it's an ext3 system). If anyone else out there is using a similar
setup please let me know if you've done anything special to reduce
digital noise.

Machine is an 800 MHz AMD w. 512 MB RAM, system is Planet CCRMA RH 9.
Any help on this matter would be greatly appreciated. I haven't had this
kind of noise problem before now, I'd certainly like to get rid of it,
and I'm willing to try about anything at this point (as long as it
doesn't cost much ;).

Best regards,

Dave Phillips

[Vincent Touquet]

On Tue, Feb 10, 2004 at 08:31:10AM -0500, Dave Phillips wrote:
> Machine is an 800 MHz AMD w. 512 MB RAM, system is Planet CCRMA RH 9.
>Any help on this matter would be greatly appreciated. I haven't had this
>kind of noise problem before now, I'd certainly like to get rid of it,
>and I'm willing to try about anything at this point (as long as it
>doesn't cost much ;).

Personally, if I would have to buy a new video card, I'd rather give the
money to a knowledgeable hacker for a workaround :)

I'm not yet sure if the problem will affect me (I think it will though,
I want to use jack in realtime mode together with accelerated 3D on a
laptop, which I will get in a few weeks time), but if it does, I'll certainly
consider forking over some cash to pour in a GPLed solution.

v

[Steve Harris]

On Tue, Feb 10, 2004 at 02:26:03 +0100, Vincent Touquet wrote:
> On Tue, Feb 10, 2004 at 08:31:10AM -0500, Dave Phillips wrote:
> > Machine is an 800 MHz AMD w. 512 MB RAM, system is Planet CCRMA RH 9.
> >Any help on this matter would be greatly appreciated. I haven't had this
> >kind of noise problem before now, I'd certainly like to get rid of it,
> >and I'm willing to try about anything at this point (as long as it
> >doesn't cost much ;).
>
> Personally, if I would have to buy a new video card, I'd rather give the
> money to a knowledgeable hacker for a workaround :)
>
> I'm not yet sure if the problem will affect me (I think it will though,
> I want to use jack in realtime mode together with accelerated 3D on a
> laptop, which I will get in a few weeks time), but if it does, I'll certainly
> consider forking over some cash to pour in a GPLed solution.

Hear hear. I think that GL accelration is a (potentially) important
optimisation for audio apps - it saves a lot of cache and memory bandwidth
that can be better used number-crunching audio.

Paul is right that its a kludge, but detecting the QT library and
unlocking it doesnt actually look that hard.

- Steve

[Vincent Touquet]

On Fri, Feb 13, 2004 at 12:14:53PM +0000, Steve Harris wrote:
>Hear hear. I think that GL accelration is a (potentially) important
>optimisation for audio apps - it saves a lot of cache and memory bandwidth
>that can be better used number-crunching audio.

Right.

>Paul is right that its a kludge, but detecting the QT library and
>unlocking it doesnt actually look that hard.
>- Steve

Cool, only right now I don't have the time to chase it down myself,
at least not fast enough without help.

v

[Tim Goetze]

Steve Harris wrote:

>On Tue, Feb 10, 2004 at 02:26:03 +0100, Vincent Touquet wrote:
>> On Tue, Feb 10, 2004 at 08:31:10AM -0500, Dave Phillips wrote:
>> > Machine is an 800 MHz AMD w. 512 MB RAM, system is Planet CCRMA RH 9.
>> >Any help on this matter would be greatly appreciated. I haven't had this
>> >kind of noise problem before now, I'd certainly like to get rid of it,
>> >and I'm willing to try about anything at this point (as long as it
>> >doesn't cost much ;).
>>
>> Personally, if I would have to buy a new video card, I'd rather give the
>> money to a knowledgeable hacker for a workaround :)
>>
>> I'm not yet sure if the problem will affect me (I think it will though,
>> I want to use jack in realtime mode together with accelerated 3D on a
>> laptop, which I will get in a few weeks time), but if it does, I'll certainly
>> consider forking over some cash to pour in a GPLed solution.
>
>Hear hear. I think that GL accelration is a (potentially) important
>optimisation for audio apps - it saves a lot of cache and memory bandwidth
>that can be better used number-crunching audio.

i'm a bit skeptical about this GL + audio business. over the years,
these splendid 3D accelerator cards have 'improved' to the point of
being one of the noisiest parts in a system, and consuming serious
wattage.

true open-source support for these chips verges on non-existence.
wasn't the point of linux to have an all-open-source system? i for
one won't run binary GL drivers.

and if you design your application around it, a system that does
GL in software will suffer big time from the cache, memory bandwidth
*and* CPU cycle hit. i've seen some simple GL-enabled applications
freeze software GL systems to a virtual standstill because it never
dawned on the author that this has to be taken into account.

i do agree that GL is a potentially important optimization. i don't
expect the potential to manifest itself within the next cople of years
though. :)

tim

[David Olofson]

On Friday 13 February 2004 13.53, Tim Goetze wrote:
[...]
> >Hear hear. I think that GL accelration is a (potentially)
> > important optimisation for audio apps - it saves a lot of cache
> > and memory bandwidth that can be better used number-crunching
> > audio.
>
> i'm a bit skeptical about this GL + audio business. over the years,
> these splendid 3D accelerator cards have 'improved' to the point of
> being one of the noisiest parts in a system, and consuming serious
> wattage.

Yes... That's a really rather annoying side effect. However, there are
actually quite powerfull cards with large, fan-less heatsinks. It
doesn't get more silent than that! ;-)

And there's always the option of replacing the original heatsink + fan
assembly with a water cooling block (provided you have a water cooled
machine) or a big fan-less heatsink, like this one:

http://www.zalman.co.kr/english/product/ZM80C-HP.htm


I've mounted these on two ATI FireGL 8800 cards without (major)
problems. The heatsinks are supposed to support bigger/hotter cards
as well, but you should definitely use the optional fan for those.
(I'm using the fan anyway, as there isn't much self circulation with
horizontal heatsinks. Very silent but quite sufficient at 5 V.)


> true open-source support for these chips verges on non-existence.
> wasn't the point of linux to have an all-open-source system? i for
> one won't run binary GL drivers.

Well, as annoying as it it, it seems like we'll just have to accept
that the drivers are part of the package. You buy a video card, and
you get drivers one way or another; drivers that are pretty close to
firmware, except that it runs on the host CPU. And you don't have the
source of the firmware in your printer, modems and other devices, do
you? Doesn't really matter as long as they work, and speak some
comprehensible standard protocol.

Still, I'd really prefer if I could debug these bl**dy ATI drivers
myself, rather than wasting time posting bug reports to ATI. And
having the source of my laser printer's firmware could be fun...


> and if you design your application around it, a system that does
> GL in software will suffer big time from the cache, memory
> bandwidth *and* CPU cycle hit. i've seen some simple GL-enabled
> applications freeze software GL systems to a virtual standstill
> because it never dawned on the author that this has to be taken
> into account.

Actually, many OpenGL developers do sort of take s/w OpenGL in
account: They explicitly do not support it, as it's dog slow pretty
much by definition, and there isn't much to do about that. OpenGL
doesn't lend itself well to s/w implementation.


> i do agree that GL is a potentially important optimization. i don't
> expect the potential to manifest itself within the next cople of
> years though. :)

Well, M$ and Apple desktop environments seem to be moving towards
using 3D acceleration for all rendering, but 3D acceleration probably
isn't cheap and widely available enough for this approach to
completely replace s/w rendering and 2D acceleration just yet.
Embedded PC hardware still generally comes without 3D acceleration,
and it'll probably stay that way until GPU power consumption has been
reduced by at least an order of magnitude. I'd assume your average
laptop user would really rather not waste power on eyecandy either.

So, I guess the 2D acceleration and s/w rendering APIs will be
relevant for several more years to come - and applications should
preferably support *both* 2D and 3D APIs when appropriate. (Could be
done through 2D-over-3D wrappers or backends.)


//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---

[Steve Harris]

On Fri, Feb 13, 2004 at 01:53:50 +0100, Tim Goetze wrote:
> >Hear hear. I think that GL accelration is a (potentially) important
> >optimisation for audio apps - it saves a lot of cache and memory bandwidth
> >that can be better used number-crunching audio.
>
> i'm a bit skeptical about this GL + audio business. over the years,
> these splendid 3D accelerator cards have 'improved' to the point of
> being one of the noisiest parts in a system, and consuming serious
> wattage.

I'm only talking about doing flat-projection bitmap layering and so on,
nothing onerous. I bought a cheap, fanless nvidia card recently and there
are free drivers for the low-end ATI cards (which are plently fast
enough).

Matrox have just release a card designed for audio that has no fans (due
to downclocked 3d processor) and lots of acceleration on all heads.

> and if you design your application around it, a system that does
> GL in software will suffer big time from the cache, memory bandwidth
> *and* CPU cycle hit. i've seen some simple GL-enabled applications
> freeze software GL systems to a virtual standstill because it never
> dawned on the author that this has to be taken into account.

I'm not thinking of a 3D UI, just using GL to accelerate 2D.

> i do agree that GL is a potentially important optimization. i don't
> expect the potential to manifest itself within the next cople of years
> though. :)

Right, well in the meantime im doing it as optional - eg. I have an alpha
version of meterbridge which can use GL - if you have it, it's massivly
more efficient, it looks better and you can resize the windows.

- Steve

[Vincent Touquet]

On Fri, Feb 13, 2004 at 03:24:05PM +0000, Steve Harris wrote:
>Matrox have just release a card designed for audio that has no fans (due
>to downclocked 3d processor) and lots of acceleration on all heads.

Which one ? :)

>Right, well in the meantime im doing it as optional - eg. I have an alpha
>version of meterbridge which can use GL - if you have it, it's massivly
>more efficient, it looks better and you can resize the windows.
>- Steve

Nice !

v

[Steve Harris]

On Fri, Feb 13, 2004 at 04:34:59 +0100, Vincent Touquet wrote:
> On Fri, Feb 13, 2004 at 03:24:05PM +0000, Steve Harris wrote:
> >Matrox have just release a card designed for audio that has no fans (due
> >to downclocked 3d processor) and lots of acceleration on all heads.
>
> Which one ? :)

http://www.matrox.com/mga/workstation/audio/

- Steve

[David Olofson]

On Friday 13 February 2004 16.52, Steve Harris wrote:
> On Fri, Feb 13, 2004 at 04:34:59 +0100, Vincent Touquet wrote:
> > On Fri, Feb 13, 2004 at 03:24:05PM +0000, Steve Harris wrote:
> > >Matrox have just release a card designed for audio that has no
> > > fans (due to downclocked 3d processor) and lots of acceleration
> > > on all heads.
> >
> > Which one ? :)
>
> http://www.matrox.com/mga/workstation/audio/

Looks very nice, but (always "but" :-/ ) it appears to have a RAMDAC
bandwidth restriction that limits the maximum dual head resolution to
1920x1440. Is it possible to use 2048x1536 + 1808x1356 or similar, or
is the big, noisy (*how* noisy, actually?) Parhelia still the only
viable option for my apparently insanely high end setup...? (The 750
has the same limitation *and* a fan, so that's not an option.)

How about OpenGL? I heard there's an unsupported OpenGL driver now.
Tried it?


//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---

[Steve Harris]

On Fri, Feb 13, 2004 at 06:49:25 +0100, David Olofson wrote:
> On Friday 13 February 2004 16.52, Steve Harris wrote:
> > On Fri, Feb 13, 2004 at 04:34:59 +0100, Vincent Touquet wrote:
> > > On Fri, Feb 13, 2004 at 03:24:05PM +0000, Steve Harris wrote:
> > > >Matrox have just release a card designed for audio that has no
> > > > fans (due to downclocked 3d processor) and lots of acceleration
> > > > on all heads.
> > >
> > > Which one ? :)
> >
> > http://www.matrox.com/mga/workstation/audio/
>
> Looks very nice, but (always "but" :-/ ) it appears to have a RAMDAC
> bandwidth restriction that limits the maximum dual head resolution to
> 1920x1440. Is it possible to use 2048x1536 + 1808x1356 or similar, or

I think they are mostly aiming at LCDs (especially for audio work - less
EMR, colour fidelity not important) where 1920x1440 is the practical
maximum.

- Steve

[Joern Nettingsmeier]

Steve Harris wrote:
>
> Right, well in the meantime im doing it as optional - eg. I have an alpha
> version of meterbridge which can use GL - if you have it, it's massivly

where?

> more efficient, it looks better and you can resize the windows.



--
The handles of a craftsman's tools bespeak an absolute simplicity,
the plainest forms affording the greatest range of possibilities for
the user's hand.
That which is overdesigned, too highly specific, anticipates
outcome; the anticipation of outcome guarantees, if not failure, the
absence of grace.
- William Gibson, "All Tomorrow's Parties"

Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxaudiodev.org (Linux Audio Developers)

[Tim Goetze]

[Steve Harris]

>> i do agree that GL is a potentially important optimization. i don't
>> expect the potential to manifest itself within the next cople of years
>> though. :)
>
>Right, well in the meantime im doing it as optional - eg. I have an alpha
>version of meterbridge which can use GL - if you have it, it's massivly
>more efficient, it looks better and you can resize the windows.

i think you're doing the right thing to offer this as an alternative,
but i must confess i don't envy your position as code maintainer. :)

tim

[Chris Pickett]

Dave Phillips wrote:

> So I'm
> wondering how I can best troubleshoot my system. The problem appears to
> be either JACK, the video driver, or maybe something to do with disk I/O
> (? it's an ext3 system). If anyone else out there is using a similar
> setup please let me know if you've done anything special to reduce
> digital noise.
>
> Machine is an 800 MHz AMD w. 512 MB RAM, system is Planet CCRMA RH 9.

Maybe it's your sound card. I know that my crap laptop sound card
definitely responds to keyboard, mouse, and cpu activity. Maybe though
it's some kind of audio buffer problem. What happens to audio if you
don't run X?

Best way in theory to troubleshoot is to divide the problem in half by
taking away half of the pieces, and iterate until you find it. In
practice it can be hard to determine where "half" is. Try no X :)

Chris

[Dave Phillips]

Hi Chris:

Well, the soundcard is an SBLive Value that I've used for quite a
while without problems.

Yes, I'll try removing things and seeing what happens next. The nVidia
driver is the first to go...

Best,

dp




Chris Pickett wrote:

> Dave Phillips wrote:
>
>> So I'm wondering how I can best troubleshoot my system. The problem
>> appears to be either JACK, the video driver, or maybe something to do
>> with disk I/O (? it's an ext3 system). If anyone else out there is
>> using a similar setup please let me know if you've done anything
>> special to reduce digital noise.
>>
>> Machine is an 800 MHz AMD w. 512 MB RAM, system is Planet CCRMA RH 9.
>
>
> Maybe it's your sound card. I know that my crap laptop sound card
> definitely responds to keyboard, mouse, and cpu activity. Maybe
> though it's some kind of audio buffer problem. What happens to audio
> if you don't run X?
>
> Best way in theory to troubleshoot is to divide the problem in half by
> taking away half of the pieces, and iterate until you find it. In
> practice it can be hard to determine where "half" is. Try no X :)
>
> Chris
>

[Dave Robillard]

On Tue, 2004-02-10 at 08:31, Dave Phillips wrote:
> Greetings:
>
> Recently I've been having a lot of trouble with extraneous noise from
> my system. Some apps are worse than others, but it does seem that
> JACK-enabled apps fare the worst.

- Take that binary driver out of your kernel (I know you need it, but
remove it temporarily to see if it's the problem)

- Get jack running in realtime mode! (The 'zippering' and other really
brutal errors are probably because of this)

- For noise problems (hum), google for the Linux Sound Quality HOWTO

I hope for your sake the vid driver isn't the problem, because if it is
there's not a single thing you or anyone else can do. < insert rant
here >

-Dave

[Vincent Touquet]

On Mon, Feb 09, 2004 at 06:58:49PM -0500, Dave Robillard wrote:
>I remember seeing that page a little while back, I'll definately look
>into it.. looks pretty crazy!

It definitely looks great.
I want to test it too.

>(If it's based on portaudio can I still connect it to my jack graph
>somehow? Never used portaudio..)

Sure, portaudio is a generic layer which you can code for. It has
support for jack in the new development series (v19):
http://www.portaudio.com/status.html

v

[Dave Griffiths]

On Tue, 10 Feb 2004 13:21:08 +0100, Vincent Touquet wrote
> On Mon, Feb 09, 2004 at 06:58:49PM -0500, Dave Robillard wrote:
> >I remember seeing that page a little while back, I'll definately look
> >into it.. looks pretty crazy!
>
> It definitely looks great.
> I want to test it too.
>
> >(If it's based on portaudio can I still connect it to my jack graph
> >somehow? Never used portaudio..)
>
> Sure, portaudio is a generic layer which you can code for. It has
> support for jack in the new development series (v19):
> http://www.portaudio.com/status.html

I've had problems getting v19 to work, so I don't think the released fluxus
version supports the new api yet - it's only a few small changes though.

cheers,

dave

................................. www.pawfal.org/nebogeo

[Vincent Touquet]

Do you use the Radeon binary driver ?

v

On Mon, Feb 09, 2004 at 06:26:20PM -0500, Dave Robillard wrote:
>Through a painful process I'd rather not go into, I discovered that Jack
>will not run in realtime mode with my Radeon's 3d drivers loaded.. I get
>the error "cannot lock down memory for RT thread"
>My idea-for-the-day was visualisation of realtime jack audio (from live
>performance); needless to say my day ended up far less interesting than
>I had hoped. :)
>Is this a known problem, or screwy system configuration on my part?
>(XFree-4.3.0, Radeon9000 Pro, Linux 2.4.24 lowlat)
>-Dave

[Jesse Chappell]

Dave Robillard wrote on Mon, 02-Feb-2004:

> > One thing that might be handy would be a "show connected ports only"
> > button for each client. So you could hide e.g. all those track_out_N
> > ports for hydrogen.
>
> Not a bad idea.. certainly not on by default, but it would be nice to
> have hydrogen appear sane.

Heh, note that if you aren't using Hydrogen's track outputs for
anything you can turn them off in the preferences.... saving some
resources probably.

About a name... there's always 'jamp', which is at least pronouncable.

jlc

[Dave Robillard]

On Mon, 2004-02-02 at 10:21, Jesse Chappell wrote:
> Dave Robillard wrote on Mon, 02-Feb-2004:
>
> > > One thing that might be handy would be a "show connected ports only"
> > > button for each client. So you could hide e.g. all those track_out_N
> > > ports for hydrogen.
> >
> > Not a bad idea.. certainly not on by default, but it would be nice to
> > have hydrogen appear sane.
>
> Heh, note that if you aren't using Hydrogen's track outputs for
> anything you can turn them off in the preferences.... saving some
> resources probably.

Hmm.. so there is. I swear I looked for that before. That makes using
hydrogen with alsa-patch-bay a lot more pleasant..

> About a name... there's always 'jamp', which is at least pronouncable.

Yep, that's the working title.

[Jesse Chappell]

Jesse Chappell wrote on Mon, 02-Feb-2004:

> About a name... there's always 'jamp', which is at least pronouncable.

Forget that... too many already. How about jackbox?

jlc

[Juhana Sadeharju]

>From: Dave Robillard <***@connect.carleton.ca>
>
>Screenshot:
>http://chat.carleton.ca/~drobilla/patchbay.png
[ ... ]
>Eventually it will be a combined jack/alsa patch bay

How about adding an application menu from which user may
launch new applications and insert to the patchbay?
Patchbay would store application's command line parameters.

How about a custom application menu where user has edited the default
command line parameters? E.g., a Fluidsynth would start with a sample
file: "fluidsynth-808perc". Of course, applications should support
configuration and sample loading via command line.

How Alsa mixer relates to Patchbay? If I record Alsa's line-in,
the reverberated output should not be mixed to the recording.
And other way, if I record reverberation, the original should not
be recorded. Could there be a Alsa module which has more connections
than capture1,2 and playback1,2? When I launch Alsamixer, I would
control levels with it and use Patchbay for routing. Sounds difficult
if Alsa has only one recording source: "Mix".

>and if anyone has ideas for an elegant
>automatic-module-placement solution

How about manual placement first? User could organize the modules
and then save the whole thing to file. When user loads the file,
the display looks the same -- and also all applications are launched.

If applications are launched from shell or if Patchbay figures out
the currently running Jack/Alsa system, then automatic placement would
be needed. But I would like to always build the system from scratch
or from file with Patchbay.

Patchbay could recognize all new applications launched from shell.
Usually one application is launched at a time and manual placement
is no problem. Again, the end result can be saved to file and there
is no need to redo the placement each time.

Patchbay files could be inserted to the current patchbay. E.g.,
a reverb patch could have four reverb related modules which together
makes the reverb. That is, four different Jack applications.

Inserted Patchbay files may need null nodes. If multiple modules
needs the same input, then with the null node the inputs can be
combined. There is no Jack application for the null node.
User who inserts the reverb to the patchbay then don't have to guess
how to connect the inputs to the reverb related modules -- their
inputs would not be connected at all without the null node.
A subpatches/macros would make the same thing, but would be more
complicated.

Should users be able to set the launching order of applications
in the patchbay files?

Regards,
Juhana

[Dave Robillard]

On Thu, 2004-02-05 at 01:07, Juhana Sadeharju wrote:
> >From: Dave Robillard <***@connect.carleton.ca>
> >
> >Screenshot:
> >http://chat.carleton.ca/~drobilla/patchbay.png
> [ ... ]
> >Eventually it will be a combined jack/alsa patch bay
>
> How about adding an application menu from which user may
> launch new applications and insert to the patchbay?
> Patchbay would store application's command line parameters.
>
> How about a custom application menu where user has edited the default
> command line parameters? E.g., a Fluidsynth would start with a sample
> file: "fluidsynth-808perc". Of course, applications should support
> configuration and sample loading via command line.

This is what LADCCA is for really.. session management is well out of
the domain of a patch bay, IMO

> How Alsa mixer relates to Patchbay? If I record Alsa's line-in,
> the reverberated output should not be mixed to the recording.
> And other way, if I record reverberation, the original should not
> be recorded. Could there be a Alsa module which has more connections
> than capture1,2 and playback1,2? When I launch Alsamixer, I would
> control levels with it and use Patchbay for routing. Sounds difficult
> if Alsa has only one recording source: "Mix".

That's the beauty of jack. You have your alsa in, patch it through
jack-rack running a reverb plugin (for example), and record that, or the
raw audio, or both.

> >and if anyone has ideas for an elegant
> >automatic-module-placement solution
>
> How about manual placement first? User could organize the modules
> and then save the whole thing to file. When user loads the file,
> the display looks the same -- and also all applications are launched.
> If applications are launched from shell or if Patchbay figures out
> the currently running Jack/Alsa system, then automatic placement would
> be needed. But I would like to always build the system from scratch
> or from file with Patchbay.

I do plan on having the ability to save module positions (with LADCCA
sessions), and of course manual placement is there. But it would still
be nice to have a nice algorithm for automatic placement. Just being
able to start all your programs paying no attention to your patch bay,
but having it nicely organized when you get to it would be nice.

If course, as someone already said (Steve?) if you loaded up all the
apps you use frequently, positioned them well and saved that, it would
be what you want most of the time (people tend to use the apps they use,
heh). Of course, only apps that are running would show up.

> Patchbay could recognize all new applications launched from shell.
> Usually one application is launched at a time and manual placement
> is no problem.

Not true really, especially as LADCCA becomes more popular.

> Again, the end result can be saved to file and there
> is no need to redo the placement each time.
>
> Patchbay files could be inserted to the current patchbay. E.g.,
> a reverb patch could have four reverb related modules which together
> makes the reverb. That is, four different Jack applications.

This doesn't have anything to do with the patch bay, but anyone who
implements a reverb like this should be taken out back and shot
regardless. ;) This is definately LADSPA-domain.

> Inserted Patchbay files may need null nodes. If multiple modules
> needs the same input, then with the null node the inputs can be
> combined.

Jack allows multiple connections.

You seem to consider the patch bay as much more of a "master"
application than myself. To me, the ideal patch bay is just there:
facilitates connections apps as nicely as possible, and displays the
current state of connection clearly.

You should definitely look into Jack and LADCCA - alot of your dreams
are already a reality. :)

Thanks for the suggestions..

-Dave

[Juhana Sadeharju]

>From: Dave Robillard <***@connect.carleton.ca>
>
>This is what LADCCA is for really.. session management is well out of
>the domain of a patch bay, IMO

So what is the purpose of Patchbay?
Users launch applications from a shell and then uses Patchbay for
connecting the applications?

That would mean a lot of manual connection work each time.
A few weeks ago I tested a midi keyboard with Fluidsynth.
Each time I changed the sample file in the shell, I had to
reconnect the thing. Very annoying.

I could not see a screenshot of the LADCCA? Does it provide
what I suggested? Is the case that either we should add the requested
features to Patchbay or add GUI to LADCCA? If both are out of question,
we need yet another application.

>This doesn't have anything to do with the patch bay, but anyone who
>implements a reverb like this should be taken out back and shot
>regardless. ;) This is definately LADSPA-domain.

I tried LADSPA already. :-(

>> Inserted Patchbay files may need null nodes. If multiple modules
>> needs the same input, then with the null node the inputs can be
>> combined.
>
>Jack allows multiple connections.

Yes, but how user would know what connections to make?
The reverb was just one example figured out in frustation,
but maybe people would like to provide such connections
for other applications? A synth application followed by effect
applications.

LADSPA requires a host. If one places multiple effects to the
path, then the host must support multiple effects and their easy
control. Too complicated. Jack + multiple simple LADSPA hosts would
work better -- if there would be some way to easily control the Jack
system.

Now I would like to have a completely graphical control application,
such as Patchbay.

Regards,
Juhana

[Dave Robillard]

On Thu, 2004-02-05 at 15:42, Juhana Sadeharju wrote:
> >From: Dave Robillard <***@connect.carleton.ca>
> >
> >This is what LADCCA is for really.. session management is well out of
> >the domain of a patch bay, IMO
>
> So what is the purpose of Patchbay?
> Users launch applications from a shell and then uses Patchbay for
> connecting the applications?

The patchbay will also be LADCCA supported, so you can save your
connections and module placement and all that in the session as well.

> That would mean a lot of manual connection work each time.
> A few weeks ago I tested a midi keyboard with Fluidsynth.
> Each time I changed the sample file in the shell, I had to
> reconnect the thing. Very annoying.

That's just a FluidSynth braindead-ism. It annoys the heck out of me
too, if I get the time I'd like to look into it (can't be that hard).

> I could not see a screenshot of the LADCCA? Does it provide
> what I suggested? Is the case that either we should add the requested
> features to Patchbay or add GUI to LADCCA? If both are out of question,
> we need yet another application.

LADCCA is a session management 'system', not really an application.. it
does come with a gtk frontend.. I'm afraid you're just going to have to
read about it to understand it. :)

> Yes, but how user would know what connections to make?
> The reverb was just one example figured out in frustation,
> but maybe people would like to provide such connections
> for other applications? A synth application followed by effect
> applications.

Synth --(jack)--> jack-rack

> LADSPA requires a host. If one places multiple effects to the
> path, then the host must support multiple effects and their easy
> control. Too complicated. Jack + multiple simple LADSPA hosts would
> work better -- if there would be some way to easily control the Jack
> system.

No, it would work a LOT worse. The overhead of an application for every
plugin? BAD idea. Besides, effects rack programs do exist that do
what you're talking about (and they're not that complicated ;) ). Some
are even modular (see SSM, AMS).

I don't mean this in a negative way at all, but you need to learn about
(what I call) the 'linux audio architechture' - alsa sequencer, jack,
LADSPA, and LADCCA before recommending features to apps like this one.
With a better understanding of the architechture you'll be able to
express your ideas in ways that make sense to the developers. The
linux-audio-user archives would be a good place to start.

> Now I would like to have a completely graphical control application,
> such as Patchbay.

I think perhaps what you're thinking is a patch bay combined (somewhat
seamlessley) with a LADSPA host? So you could, say, run fluidsynth into
freeverb into alsa audio out?

I've certainly thought of this before, and it is possible, but
definately not trivial. It would be marginally cool, but a
synth/effects rack and a patch bay are fundamentally different things,
and I'm a big proponent of the 'unix philosophy'.. tools that do one
thing and do them right.

Now on the other hand, the idea of a nice simple little modular LADSPA
host (usable as both a synth and/or an effects rack) is a good one
indeed...

-Dave

[Steve Harris]

On Thu, Feb 05, 2004 at 08:16:34 -0500, Dave Robillard wrote:
> Now on the other hand, the idea of a nice simple little modular LADSPA
> host (usable as both a synth and/or an effects rack) is a good one
> indeed...

Yeah, thats probably why we have 5 allready ;)

- Steve

[Dave Robillard]

On Fri, 2004-02-06 at 07:33, Steve Harris wrote:
> On Thu, Feb 05, 2004 at 08:16:34 -0500, Dave Robillard wrote:
> > Now on the other hand, the idea of a nice simple little modular LADSPA
> > host (usable as both a synth and/or an effects rack) is a good one
> > indeed...
>
> Yeah, thats probably why we have 5 allready ;)

I can think of two (AMS and SSM).. SSM has no polyphony which puts it
out.

AMS is actually pretty good, if it would only work with LADSPA control
ports. Not being able to control the frequency of your oscillators is a
little bit of a limiting factor! (AMS's MIDI control stuff is
definately awesome..)

Enlighten me to a polyphonic LADSPA host with a modular GUI (and control
ports work) and you'll be my new best friend. :)

-Dave

[Steve Harris]

On Fri, Feb 06, 2004 at 12:56:18 -0500, Dave Robillard wrote:
> On Fri, 2004-02-06 at 07:33, Steve Harris wrote:
> > On Thu, Feb 05, 2004 at 08:16:34 -0500, Dave Robillard wrote:
> > > Now on the other hand, the idea of a nice simple little modular LADSPA
> > > host (usable as both a synth and/or an effects rack) is a good one
> > > indeed...
> >
> > Yeah, thats probably why we have 5 allready ;)
>
> I can think of two (AMS and SSM).. SSM has no polyphony which puts it
> out.
>
> AMS is actually pretty good, if it would only work with LADSPA control
> ports. Not being able to control the frequency of your oscillators is a
> little bit of a limiting factor! (AMS's MIDI control stuff is
> definately awesome..)

Just click on "Export control ports as module ports".

- Steve

[Dave Robillard]

On Fri, 2004-02-06 at 16:00, Steve Harris wrote:
> On Fri, Feb 06, 2004 at 12:56:18 -0500, Dave Robillard wrote:
> > On Fri, 2004-02-06 at 07:33, Steve Harris wrote:
> > > On Thu, Feb 05, 2004 at 08:16:34 -0500, Dave Robillard wrote:
> > > > Now on the other hand, the idea of a nice simple little modular LADSPA
> > > > host (usable as both a synth and/or an effects rack) is a good one
> > > > indeed...
> > >
> > > Yeah, thats probably why we have 5 allready ;)
> >
> > I can think of two (AMS and SSM).. SSM has no polyphony which puts it
> > out.
> >
> > AMS is actually pretty good, if it would only work with LADSPA control
> > ports. Not being able to control the frequency of your oscillators is a
> > little bit of a limiting factor! (AMS's MIDI control stuff is
> > definately awesome..)
>
> Just click on "Export control ports as module ports".

Sure, but they don't actually work. At least not for me, from the AMS
discussion on this list I thought it was a known limitation (since
everything in AMS is audio rate).

Does it actually work for anyone?

-Dave

[Fons Adriaensen]

On Fri, Feb 06, 2004 at 04:08:31PM -0500, Dave Robillard wrote:

> > Just click on "Export control ports as module ports".
>
> Sure, but they don't actually work. At least not for me, from the AMS
> discussion on this list I thought it was a known limitation (since
> everything in AMS is audio rate).
>
> Does it actually work for anyone?

Just did a test with a few plugins (no time to test them all :-).
Seems to work, using the CONVERTER module to convert from 1/oct to Hz.

--
FA

[Dave Robillard]

On Fri, 2004-02-06 at 18:31, Fons Adriaensen wrote:
> On Fri, Feb 06, 2004 at 04:08:31PM -0500, Dave Robillard wrote:
>
> > > Just click on "Export control ports as module ports".
> >
> > Sure, but they don't actually work. At least not for me, from the AMS
> > discussion on this list I thought it was a known limitation (since
> > everything in AMS is audio rate).
> >
> > Does it actually work for anyone?
>
> Just did a test with a few plugins (no time to test them all :-).
> Seems to work, using the CONVERTER module to convert from 1/oct to Hz.

Odd.. (FYI I was converting) I'll look into that one further I guess. I
think it was one of Steve's oscillator plugins that wasn't working..

More on that later (few days at least)

-Dave

[t***@informatik.uni-bremen.de]

On Fri, Feb 06, 2004 at 12:56:18PM -0500, Dave Robillard wrote:
> On Fri, 2004-02-06 at 07:33, Steve Harris wrote:
> > On Thu, Feb 05, 2004 at 08:16:34 -0500, Dave Robillard wrote:
> > > Now on the other hand, the idea of a nice simple little modular LADSPA
> > > host (usable as both a synth and/or an effects rack) is a good one
> > > indeed...
> >
> > Yeah, thats probably why we have 5 allready ;)
>
> I can think of two (AMS and SSM).. SSM has no polyphony which puts it
> out.
>
> AMS is actually pretty good, if it would only work with LADSPA control
> ports. Not being able to control the frequency of your oscillators is a
> little bit of a limiting factor! (AMS's MIDI control stuff is
> definately awesome..)
>
> Enlighten me to a polyphonic LADSPA host with a modular GUI (and control
> ports work) and you'll be my new best friend. :)

galan-0.3.0-beta3 its here finally :)
you will need some time to get into it.
but if you have questions i will be there to help.

polyphony is realized through a voice_allocator.
and you will have to instantiate each voice on the sheet and connect
them to the allocator.

LADPSA events a sample accurate if you use internal galan sequencers or
jack-midi (well there is no jack-midi sequencer yet)

--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language

[Dave Robillard]

On Sun, 2004-02-08 at 09:05, ***@informatik.uni-bremen.de wrote:
> > Enlighten me to a polyphonic LADSPA host with a modular GUI (and control
> > ports work) and you'll be my new best friend. :)
>
> galan-0.3.0-beta3 its here finally :)
> you will need some time to get into it.
> but if you have questions i will be there to help.
>
> polyphony is realized through a voice_allocator.
> and you will have to instantiate each voice on the sheet and connect
> them to the allocator.

Eeck. Is there at least subpatches? I can deal with arranging 12+
individual modules as voices and just working on a subpatch, but
actually setting up all those voices is definately out of the question..

> LADPSA events a sample accurate if you use internal galan sequencers or
> jack-midi (well there is no jack-midi sequencer yet)

I'll check it out (compiling right now..) and take any questions to LAU.

-Dave

[t***@informatik.uni-bremen.de]

On Sun, Feb 08, 2004 at 01:47:39PM -0500, Dave Robillard wrote:
> On Sun, 2004-02-08 at 09:05, ***@informatik.uni-bremen.de wrote:
> > > Enlighten me to a polyphonic LADSPA host with a modular GUI (and control
> > > ports work) and you'll be my new best friend. :)
> >
> > galan-0.3.0-beta3 its here finally :)
> > you will need some time to get into it.
> > but if you have questions i will be there to help.
> >
> > polyphony is realized through a voice_allocator.
> > and you will have to instantiate each voice on the sheet and connect
> > them to the allocator.
>
> Eeck. Is there at least subpatches? I can deal with arranging 12+
> individual modules as voices and just working on a subpatch, but
> actually setting up all those voices is definately out of the question..

subpatches are realised. you can have an arbitrary number of sheets
and have references on other sheets.

if you save a sheet to your sheet library you can instantiate it
through the lib menu.

--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language

[Juhana Sadeharju]

>From: Dave Robillard <***@connect.carleton.ca>
>
>What's the best way to disconnect ports? I've thought of:
>
>- putting a handle in the middle of connection lines, so you can
>right-click them to get a menu

No no.

>- making the lines really thick, same deal as above

Make the lines thick only if it is visually justified.
If you only want grab the cable, then make the grabbing distance
long enough. The same for the grabbing distances of the ports.
When working fast, any tiny things are no no -- there are plenty
of examples on tiny things already.

Change the cable and the port colors when they are in focus, to
indicate that something can be done to them.

Probably three distances are needed:
-Port picking distance
-Cable-end picking distance
-Cable picking distance
If one may start a new cable by picking the port, then cable-end picking
distance must be slighly larger -- and the area between the port picking
distance and the cable-end picking distance are used to pick the ends
of the cables.

- Grab and drag the end of the cable; the cable-end picking distance
should be long enough so that grabbing a cable is possible even
if the port has multiple connections (Note: this does not delete
the cable)

- Grabbing both ends deletes the cable

Change color only of the end of the cable to indicate that it can be
picked up.

- Ctrl + mouse button 1 on a cable: deletes cable; the menu is
ok too, but I prefer faster ctrl+mb1

- Sweeping a rectangle area on canvas, followed by a deletion operation

Make enough alternatives because usability is a matter of choise.

Regards,
Juhana

[Dave Robillard]

On Fri, 2004-02-06 at 12:35, Juhana Sadeharju wrote:
> >- making the lines really thick, same deal as above
>
> Make the lines thick only if it is visually justified.
> If you only want grab the cable, then make the grabbing distance
> long enough. The same for the grabbing distances of the ports.
> When working fast, any tiny things are no no -- there are plenty
> of examples on tiny things already.

The problem with this is it will become ambiguous which line you're
trying to select.. connections often will be very close together.

> Change the cable and the port colors when they are in focus, to
> indicate that something can be done to them.
>
> Probably three distances are needed:
> -Port picking distance

Having some fuzziness to the port picking is a good idea.. I'll do
that. Of course, it's going to be way way more of a pain to implement
than just clicking on the port, but oh well. I'll have the port hilite
when the mouse is within it's clicking region.

Actually.. better idea. Right now you have to actually click on the
little port box to connect things, but you should be able to click the
port label to select the port.. that's the entire width of the module.
Quite the braindead-ism on my part to not think of THAT before...

-Dave

[Steve Harris]

On Fri, Feb 06, 2004 at 01:05:11 -0500, Dave Robillard wrote:
> Actually.. better idea. Right now you have to actually click on the
> little port box to connect things, but you should be able to click the
> port label to select the port.. that's the entire width of the module.
> Quite the braindead-ism on my part to not think of THAT before...

You should be able to drag and drop, with snap-to when you get near too.

- Steve

[Dave Robillard]

On Fri, 2004-02-06 at 16:01, Steve Harris wrote:
> On Fri, Feb 06, 2004 at 01:05:11 -0500, Dave Robillard wrote:
> > Actually.. better idea. Right now you have to actually click on the
> > little port box to connect things, but you should be able to click the
> > port label to select the port.. that's the entire width of the module.
> > Quite the braindead-ism on my part to not think of THAT before...
>
> You should be able to drag and drop, with snap-to when you get near too.
>
> - Steve

You think so? SSM does this, but I always much preferred the AMS-style
click-then-click. I suppose there's no harm in supporting both.
Eventually. :)

~ Dave

[vanDongen/Gilcher]

My preference :
The line doesn't need to be thick. Clicking it selects it (and shows it by
changing the color, maybe making it thicker as well ), pressing delete
removes it.

Handles of some sort to create segmented patch cords would be nice. As would
the ability to rotate a client box over 90 degrees, so you have the
connection at the top and bottom.
Another feature could be symbolic link objects. Sometimes you have a signal
detour to some part of an app that is somewhere else on the graph and
allready heavilly connected to all kinds of other stuff. A symbolic-link to
foo:input12 foo:output12 could be nice then.


Gerard

On Friday 06 February 2004 13:50, Dave Robillard wrote:

> What's the best way to disconnect ports? I've thought of:
>
> - putting a handle in the middle of connection lines, so you can
> right-click them to get a menu
>
> - making the lines really thick, same deal as above
>
> - just being able to right click a port and disconnect all connections
> (with the obvious disadvantage of forcing you to maybe disconnect
> something you don't want to)
>
> - clicking on the source port then the dest port (just like connecting),
> except if they're already connected, disconnect them
>
>
> Ideas? Opinions?
>
> -Dave


--
electronic & acoustic musics-- http://www.xs4all.nl/~gml

[Dave Robillard]

On Fri, 2004-02-06 at 19:19, vanDongen/Gilcher wrote:
> My preference :
> The line doesn't need to be thick. Clicking it selects it (and shows it by
> changing the color, maybe making it thicker as well ), pressing delete
> removes it.

I think clicking on a line is just far too difficult to bother.

> Handles of some sort to create segmented patch cords would be nice. As would
> the ability to rotate a client box over 90 degrees, so you have the
> connection at the top and bottom.
> Another feature could be symbolic link objects. Sometimes you have a signal
> detour to some part of an app that is somewhere else on the graph and
> allready heavilly connected to all kinds of other stuff. A symbolic-link to
> foo:input12 foo:output12 could be nice then.

Whew, now this is getting complicated. :) These things are nice in
modular synths, but wouldn't it be overkill in a patch bay?

I guess with LADCCA you could have a really complicated setup that you
want to be able to visualize as clearly as possible... I'll put some
thought into it.

-Dave

[vanDongen/Gilcher]

On Friday 06 February 2004 23:38, Dave Robillard wrote:
> On Fri, 2004-02-06 at 19:19, vanDongen/Gilcher wrote:
> > My preference :
> > The line doesn't need to be thick. Clicking it selects it (and shows it
> > by changing the color, maybe making it thicker as well ), pressing delete
> > removes it.
>
> I think clicking on a line is just far too difficult to bother.
>
Have you tried pd? It uses this system. I find it very fast and intuitive.

Gerard

[Joern Nettingsmeier]

Dave Robillard wrote:
> On Fri, 2004-02-06 at 19:19, vanDongen/Gilcher wrote:
>
>>My preference :
>>The line doesn't need to be thick. Clicking it selects it (and shows it by
>>changing the color, maybe making it thicker as well ), pressing delete
>>removes it.
>
>
> I think clicking on a line is just far too difficult to bother.
>
>
>>Handles of some sort to create segmented patch cords would be nice. As would
>>the ability to rotate a client box over 90 degrees, so you have the
>>connection at the top and bottom.
>>Another feature could be symbolic link objects. Sometimes you have a signal
>>detour to some part of an app that is somewhere else on the graph and
>>allready heavilly connected to all kinds of other stuff. A symbolic-link to
>>foo:input12 foo:output12 could be nice then.
>
>
> Whew, now this is getting complicated. :) These things are nice in
> modular synths, but wouldn't it be overkill in a patch bay?

hmm. i don't like this symlink idea. kinda kludgy to me, but that's
surely a matter of taste.
how about a feature to collapse an arbitrary part of the graph into
a black box? rubber-band a couple of jack clients, press
ctrl-something and you get a blackbox with all inputs that
originally went into the subgraph and all outs as well, which is
labelled by default with a simple list of the clients inside,
regardless of their ordering.

just an idea...
--
"I never use EQ, never, never, never. I previously used to use mic
positioning but I've even given up on that too."
- Jezar on http://www.audiomelody.com


Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxaudiodev.org (Linux Audio Developers)

[Paul Davis]

>The wires would look even cooler if they were splines, so that they came
>out of their ports horizontally and gracefully curved their way to their
>destination :) It looks cool and feedback loops display better. (if
>you're using something like a GTK canvas it's pretty easy too)

last time i looked, the support for splines on the canvas was all
stub functions.

--p

[Paul Davis]

>On Mon, 2004-02-09 at 18:50, Dave Griffiths wrote:
>> jack works with intel830 DRI
>
>Hmm.. I only have Radeon's, so I'm a bit out of luck as far as testing
>other cards I guess.
>
>Anyone else have a positive/negative experience?
>
>(For clarification, it's only realtime jack (ie jackstart -R) that
>doesn't work).

its a basic problem with real time software, the POSIX API etc.

JACK tries to lock *all* the process memory. POSIX doesn't offer any
APIs that would allow us to lock only the parts we need locked without
a lot of impossibly ugly, non-portable kludgery. the part that needs
locking consists of any memory that will be touched by the code run in
the JACK-managed "audio" thread.

the implementation of DRI by certain video interface drivers means
that we end up trying to lock the video memory as well, and this tends
to fail for various reasons.

its not what to do about this. the most obvious answer is "don't try
to run real-time software on systems with these video drivers
installed". i know its not very satisfactory, but its all we have for
now.

--p

[Dave Robillard]

On Mon, 2004-02-09 at 19:32, Paul Davis wrote:
> its a basic problem with real time software, the POSIX API etc.
>
> JACK tries to lock *all* the process memory. POSIX doesn't offer any
> APIs that would allow us to lock only the parts we need locked without
> a lot of impossibly ugly, non-portable kludgery. the part that needs
> locking consists of any memory that will be touched by the code run in
> the JACK-managed "audio" thread.
>
> the implementation of DRI by certain video interface drivers means
> that we end up trying to lock the video memory as well, and this tends
> to fail for various reasons.
>
> its not what to do about this. the most obvious answer is "don't try
> to run real-time software on systems with these video drivers
> installed". i know its not very satisfactory, but its all we have for
> now.

Well.... crap. I guess I can play with video in non-realtime mode for
the time being.

I guess I'll have to wait for the day when I can afford two
multi-channel audio interfaces, two multi-channel MIDI interfaces, and a
dedicated machine to handle the visualisation aspect of things.

Those will be the days. ;)

-Dave

[Robert Jonsson]

On Tuesday 10 February 2004 01.32, Paul Davis wrote:
> >On Mon, 2004-02-09 at 18:50, Dave Griffiths wrote:
> >> jack works with intel830 DRI
> >
> >Hmm.. I only have Radeon's, so I'm a bit out of luck as far as testing
> >other cards I guess.
> >
> >Anyone else have a positive/negative experience?
> >
> >(For clarification, it's only realtime jack (ie jackstart -R) that
> >doesn't work).
>
> its a basic problem with real time software, the POSIX API etc.
>
> JACK tries to lock *all* the process memory. POSIX doesn't offer any
> APIs that would allow us to lock only the parts we need locked without
> a lot of impossibly ugly, non-portable kludgery. the part that needs
> locking consists of any memory that will be touched by the code run in
> the JACK-managed "audio" thread.
>
> the implementation of DRI by certain video interface drivers means
> that we end up trying to lock the video memory as well, and this tends
> to fail for various reasons.
>
> its not what to do about this. the most obvious answer is "don't try
> to run real-time software on systems with these video drivers
> installed". i know its not very satisfactory, but its all we have for
> now.
>
> --p

There is one other option that helped me. I had this exact problem with my ATI
card. 128mb memory and QT insisted that it should be mapped into it's memory
space (infact it must be mapping it twice!)

In usage this meant that QT apps on my machine had a memory footprint at 300+
MB. With my 512 MB memory I could seldomly lock more than one app.... strange
would be otherwise ;).
Now, I can't disable DRI since I wanted my TV-out to work so I looked for
other solutions.
I found an obvious one. Decrease the amount of memory that the X-server
utilizes on the card. 128MB of graphic memory is __alot__, atleast I don't
need that.
I added the following to my XF86Config-4 in section "Device":
VideoRam 32768

Apps still report to much memory (seeminly about twice the video memory, 64MB)
but it's no longer a problem.

/Robert

[Vincent Touquet]

On Mon, Feb 09, 2004 at 07:32:35PM -0500, Paul Davis wrote:
>the implementation of DRI by certain video interface drivers means
>that we end up trying to lock the video memory as well, and this tends
>to fail for various reasons.

Hm, that sounds bad.
Does this problem also happen with the open source drivers from dri.sf.net ?
I was just thinking of getting an IBM thinkpad and I might want to change
the model I want based on this.

>its not what to do about this. the most obvious answer is "don't try
>to run real-time software on systems with these video drivers
>installed". i know its not very satisfactory, but its all we have for
>now.

Too bad :/

v

[martin rumori]

On Tue, Feb 10, 2004 at 12:14:24PM +0100, Vincent Touquet wrote:
> On Mon, Feb 09, 2004 at 07:32:35PM -0500, Paul Davis wrote:
> >the implementation of DRI by certain video interface drivers means

> I was just thinking of getting an IBM thinkpad and I might want to change
> the model I want based on this.

i own a t40p and didn't encounter problems. jack-cvs, ati-binary
drivers, debian unstable (xfree 4.2.1), dri. builtin sound. there
are 512M of memory inside the machine, 64M graphics ram. top shows
that starting jack eats about 10M of memory. i don't know how to
figure out how much memory is actually locked by mlockall.

i didn't try the dri.sf.net drivers so far, but plan to do so in the
near or far future...

best,

martin

[Vincent Touquet]

On Mon, Feb 09, 2004 at 07:32:35PM -0500, Paul Davis wrote:
>its a basic problem with real time software, the POSIX API etc.
>JACK tries to lock *all* the process memory.

This is to ensure that nothing gets swapped out, right ?
Else it is very hard to ensure real time performance ?
(sorry for being somewhat ignorant in this matter).

>POSIX doesn't offer any
>APIs that would allow us to lock only the parts we need locked without
>a lot of impossibly ugly, non-portable kludgery.
>the part that needs
>locking consists of any memory that will be touched by the code run in
>the JACK-managed "audio" thread.
>the implementation of DRI by certain video interface drivers means
>that we end up trying to lock the video memory as well, and this tends
>to fail for various reasons.

Is this faillure due to the nature of the memory that we are trying to lock ?
Or is the problem that we try to lock the same part of memory multiple times ?

>its not what to do about this. the most obvious answer is "don't try
>to run real-time software on systems with these video drivers
>installed". i know its not very satisfactory, but its all we have for
>now.

Would the less obvious answer consist of one of the following ?:
- change the video drivers (at least the ones that are source based)
- do something at the API level, so we can lock selectively

>

[Robert Jonsson]

On Tuesday 10 February 2004 13.32, Vincent Touquet wrote:
> On Mon, Feb 09, 2004 at 07:32:35PM -0500, Paul Davis wrote:
> >its a basic problem with real time software, the POSIX API etc.
> >JACK tries to lock *all* the process memory.
>
> This is to ensure that nothing gets swapped out, right ?
> Else it is very hard to ensure real time performance ?
> (sorry for being somewhat ignorant in this matter).
>
> >POSIX doesn't offer any
> >APIs that would allow us to lock only the parts we need locked without
> >a lot of impossibly ugly, non-portable kludgery.
> >the part that needs
> >locking consists of any memory that will be touched by the code run in
> >the JACK-managed "audio" thread.
> >the implementation of DRI by certain video interface drivers means
> >that we end up trying to lock the video memory as well, and this tends
> >to fail for various reasons.
>
> Is this faillure due to the nature of the memory that we are trying to lock
> ? Or is the problem that we try to lock the same part of memory multiple
> times ?

I'm running quite happily with DRI enabled on my ATI card now, the problem was
definitely that it was trying to lock too much memory. Since shrinking the
amount of vidmem that X utilizes I haven't run into this problem again (see
other message for the actual remedy).

/Robert

>
> >its not what to do about this. the most obvious answer is "don't try
> >to run real-time software on systems with these video drivers
> >installed". i know its not very satisfactory, but its all we have for
> >now.
>
> Would the less obvious answer consist of one of the following ?:
> - change the video drivers (at least the ones that are source based)
> - do something at the API level, so we can lock selectively
>
>

[Vincent Touquet]

On Tue, Feb 10, 2004 at 01:45:49PM +0100, Robert Jonsson wrote:
>I'm running quite happily with DRI enabled on my ATI card now, the problem was
>definitely that it was trying to lock too much memory.

Ok. I assume that you have a Firegl T2 with 128Mb Ram (using the ATI 3.7.0 drivers) ?

>Since shrinking the
>amount of vidmem that X utilizes I haven't run into this problem again (see
>other message for the actual remedy).

Yep, I read that message.
I wasn't so sure if that was a complete solution though, as Paul talked
about faillure to lock memory for _various_ reasons :)

So another solution would be to add more RAM to the machine you're working on ? :)

best regards,

Vincent

[Robert Jonsson]

On Tuesday 10 February 2004 14.07, Vincent Touquet wrote:
> On Tue, Feb 10, 2004 at 01:45:49PM +0100, Robert Jonsson wrote:
> >I'm running quite happily with DRI enabled on my ATI card now, the problem
> > was definitely that it was trying to lock too much memory.
>
> Ok. I assume that you have a Firegl T2 with 128Mb Ram (using the ATI 3.7.0
> drivers) ?
>
> >Since shrinking the
> >amount of vidmem that X utilizes I haven't run into this problem again
> > (see other message for the actual remedy).
>
> Yep, I read that message.
> I wasn't so sure if that was a complete solution though, as Paul talked
> about faillure to lock memory for _various_ reasons :)

I'm no expert at this, but my own findings support only that the problem is
the amount of memory being locked, not the type of memory, neither that it
happens to be the same memory we are locking.

> So another solution would be to add more RAM to the machine you're working
> on ? :)
>
That's my prefered solution, buy my way out of trouble ;-P.

/Robert


> best regards,
>
> Vincent

[Jack O'Quin]

Vincent Touquet <***@pandora.be> writes:

> Would you consider implementing a work around (aka non portable kludgery)
> a waste of time ?

In the 2.4 kernel this test in mm/mlock.c limits page locking to half
of physical memory...

/* we may lock at most half of physical memory... */
/* (this check is pretty bogus, but doesn't hurt) */
if (current->mm->total_vm > num_physpages/2)
goto out;

Maybe that test is being confused by the presence of video memory somehow.

If you're looking for kludges, try commenting it out to see what
happens.

--
joq

[Paul Davis]

>I guess I'll have to wait for the day when I can afford two
>multi-channel audio interfaces, two multi-channel MIDI interfaces, and a
>dedicated machine to handle the visualisation aspect of things.

or ... you could just get a Matrox video interface, since they seem to
be just about the only company that understands the way that video h/w
interacts with audio and realtime issues. or maybe i should say the
only company that actually cares about it. they even had a booth a
NAMM ...

--p

[Dave Robillard]

On Mon, 2004-02-09 at 20:11, Paul Davis wrote:
> >I guess I'll have to wait for the day when I can afford two
> >multi-channel audio interfaces, two multi-channel MIDI interfaces, and a
> >dedicated machine to handle the visualisation aspect of things.
>
> or ... you could just get a Matrox video interface, since they seem to
> be just about the only company that understands the way that video h/w
> interacts with audio and realtime issues. or maybe i should say the
> only company that actually cares about it. they even had a booth a
> NAMM ...
>
> --p

I used to be all about Matrox back in the G-400 days, but when they
dropped off the acceptable-high-end-3d-card list, I went Radeon due to
ATI's (former) releasing of specs and whatnot.

Now that ATI has gone the way of Nvidia I don't know who to pledge
allegiance to. :)

Is Matrox still friendly?

-Dave

[Vincent Touquet]

On Mon, Feb 09, 2004 at 08:19:55PM -0500, Dave Robillard wrote:
>Now that ATI has gone the way of Nvidia I don't know who to pledge
>allegiance to. :)
>Is Matrox still friendly?

I would say that there is still hope as far as ATI is concerned.
They are delivering specs to the Linuxbios people, so they can
get VGA working through LinuxBIOS :)

regards,

v

[Robert Jonsson]

On Tuesday 10 February 2004 02.11, Paul Davis wrote:
> >I guess I'll have to wait for the day when I can afford two
> >multi-channel audio interfaces, two multi-channel MIDI interfaces, and a
> >dedicated machine to handle the visualisation aspect of things.
>
> or ... you could just get a Matrox video interface, since they seem to
> be just about the only company that understands the way that video h/w
> interacts with audio and realtime issues. or maybe i should say the
> only company that actually cares about it. they even had a booth a
> NAMM ...

I don't argue their concern, I'm sure they are nice people. But are you sure
there is really a technical difference, I thought the mapping of the memory
was done way above the driver?

/Robert

>
> --p

[Joern Nettingsmeier]

Paul Davis wrote:
>>I guess I'll have to wait for the day when I can afford two
>>multi-channel audio interfaces, two multi-channel MIDI interfaces, and a
>>dedicated machine to handle the visualisation aspect of things.
>
>
> or ... you could just get a Matrox video interface, since they seem to
> be just about the only company that understands the way that video h/w
> interacts with audio and realtime issues. or maybe i should say the
> only company that actually cares about it. they even had a booth a
> NAMM ...

i'm using a g550 w/ dual-head at work, and i must say this is god's
own video card for audio. if only i could afford a second screen at
home :(

--
The handles of a craftsman's tools bespeak an absolute simplicity,
the plainest forms affording the greatest range of possibilities for
the user's hand.
That which is overdesigned, too highly specific, anticipates
outcome; the anticipation of outcome guarantees, if not failure, the
absence of grace.
- William Gibson, "All Tomorrow's Parties"

Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxaudiodev.org (Linux Audio Developers)

[Paul Davis]

>On Mon, Feb 09, 2004 at 07:32:35PM -0500, Paul Davis wrote:
>>its a basic problem with real time software, the POSIX API etc.
>>JACK tries to lock *all* the process memory.
>
>This is to ensure that nothing gets swapped out, right ?
>Else it is very hard to ensure real time performance ?
>(sorry for being somewhat ignorant in this matter).

well, swapping is one aspect. page faults are the other. either way,
yes, we need to ensure that real-time code is never stalled waiting
for data to be bought into memory from disk storage.

>Would you consider implementing a work around (aka non portable kludgery)
>a waste of time ?

Mostly, though there are people who would probably find it valuable.

--p

[Chris Pickett]

Paul Davis wrote:
>>On Mon, Feb 09, 2004 at 07:32:35PM -0500, Paul Davis wrote:
>>
>>>its a basic problem with real time software, the POSIX API etc.
>>>JACK tries to lock *all* the process memory.
>>
>>This is to ensure that nothing gets swapped out, right ?
>>Else it is very hard to ensure real time performance ?
>>(sorry for being somewhat ignorant in this matter).
>
>
> well, swapping is one aspect. page faults are the other. either way,
> yes, we need to ensure that real-time code is never stalled waiting
> for data to be bought into memory from disk storage.

What are the factors influencing the amount of memory the JACK process
needs?

Maybe it's possible to reduce it.

Unless I misread what you wrote and by "*all* the process memory" you
mean the memory of all processes on the system and not just JACK.

Chris

[Dave Robillard]

On Tue, 2004-02-10 at 16:51, Chris Pickett wrote:
> Paul Davis wrote:
> >>On Mon, Feb 09, 2004 at 07:32:35PM -0500, Paul Davis wrote:
> >>
> >>>its a basic problem with real time software, the POSIX API etc.
> >>>JACK tries to lock *all* the process memory.
> >>
> >>This is to ensure that nothing gets swapped out, right ?
> >>Else it is very hard to ensure real time performance ?
> >>(sorry for being somewhat ignorant in this matter).
> >
> >
> > well, swapping is one aspect. page faults are the other. either way,
> > yes, we need to ensure that real-time code is never stalled waiting
> > for data to be bought into memory from disk storage.
>
> What are the factors influencing the amount of memory the JACK process
> needs?
>
> Maybe it's possible to reduce it.
>
> Unless I misread what you wrote and by "*all* the process memory" you
> mean the memory of all processes on the system and not just JACK.

For the record, since I started this whole thing, I have 512MB of RAM,
and it's usually well over half free. (ie I still get that problem when
I have hundreds of megs of free RAM).

But I discovered I'm having not-jack-related DRI problems to begin with,
so when I figure those out I'll see if there is indeed a conflict or if
it's just my screwy system.

When I figure it out, I'll post the verdict for future generations.

-Dave

[CK]

hi dave,

I read:
> I've had problems getting v19 to work, so I don't think the released fluxus
> version supports the new api yet - it's only a few small changes though.

I think I sent you patches to make fluxus work with the new API (didn't I?)
but AFAIK portaudio's jack implementation is currently broken anyway.

regards,

x

--
***@lo-res.org Postmodernism is german romanticism with better
http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)

[Dave Griffiths]

On Tue, 10 Feb 2004 14:45:30 +0100 (CET), CK wrote
> hi dave,
>
> I read:
> > I've had problems getting v19 to work, so I don't think the released fluxus
> > version supports the new api yet - it's only a few small changes though.
>
> I think I sent you patches to make fluxus work with the new API
> (didn't I?) but AFAIK portaudio's jack implementation is currently
> broken anyway.

yep indeed - cheers - I just haven't released this fix yet as v19 is broken on
my laptop, maybe I should release a test version (or give them a hand with
portaudio and make myself useful ;))

cheers,

dave

................................. www.pawfal.org/nebogeo

[Jesse Chappell]

Vincent Touquet wrote on Tue, 10-Feb-2004:

> On Tue, Feb 10, 2004 at 01:45:49PM +0100, Robert Jonsson wrote:
> >I'm running quite happily with DRI enabled on my ATI card now, the problem was
> >definitely that it was trying to lock too much memory.
>
> Ok. I assume that you have a Firegl T2 with 128Mb Ram (using the ATI 3.7.0 drivers) ?

BTW, i just ran JACK realtime on a T41p with the firegl T2 128MB,
using the ati 3.7.0 drivers on a 2.4.22 PE/LL kernel with no problems.
Alsa 0.9.8 using the builtin audio (snd-intel8x0). the machine
itself has 512MB of RAM.

I tested with alsaplayer, jack-rack and freqtweak together loading
the system to > 80% cpu utilization and no xruns at
256 period size (and possibly less) and 48k.

And yes, ATI's drivers have DRI enabled.... note that i didn't
try to run any opengl accelerated apps at the same time as jack
yet..... but i don't see any of the problems with regard to memory locking.
maybe 512 is too much RAM to notice the problem.

jlc

[Vincent Touquet]

On Tue, Feb 10, 2004 at 01:57:17PM -0500, Jesse Chappell wrote:
>BTW, i just ran JACK realtime on a T41p with the firegl T2 128MB,
>using the ati 3.7.0 drivers on a 2.4.22 PE/LL kernel with no problems.
>Alsa 0.9.8 using the builtin audio (snd-intel8x0). the machine
>itself has 512MB of RAM.

Great !
Thanks for testing :)
Which distribution are you running ?

>I tested with alsaplayer, jack-rack and freqtweak together loading
>the system to > 80% cpu utilization and no xruns at
>256 period size (and possibly less) and 48k.
Cool.
That's about 5.3 ms, which is good :)

>And yes, ATI's drivers have DRI enabled.... note that i didn't
>try to run any opengl accelerated apps at the same time as jack
>yet..... but i don't see any of the problems with regard to memory locking.
>maybe 512 is too much RAM to notice the problem.
>jlc

I'm aiming to get more memory, so the memory locking should really be no
problem :) I hope I can test fluxus once I get the laptop :)

v

[Jesse Chappell]

Vincent Touquet wrote on Tue, 10-Feb-2004:

> On Tue, Feb 10, 2004 at 01:57:17PM -0500, Jesse Chappell wrote:
> >BTW, i just ran JACK realtime on a T41p with the firegl T2 128MB,
> >using the ati 3.7.0 drivers on a 2.4.22 PE/LL kernel with no problems.
> >Alsa 0.9.8 using the builtin audio (snd-intel8x0). the machine
> >itself has 512MB of RAM.
>
> Great !
> Thanks for testing :)
> Which distribution are you running ?

Gentoo. That kernel is the gentoo patched one (with LL and PE).
At some point I might test it with the RME hdsp/cardbus, but I
think it will be fine, the cardbus chipset is TI.

> >I tested with alsaplayer, jack-rack and freqtweak together loading
> >the system to > 80% cpu utilization and no xruns at
> >256 period size (and possibly less) and 48k.
> Cool.
> That's about 5.3 ms, which is good :)

I think you could even go lower.... i actually tried 64 and non-intensive
audio duties (alsaplayer only) seemed fine even while compiling.
It all depends on your target application.... for low-impact softsynths
or samplers I think you can get some pretty impressive playability
even from the builtin audio. As it only has a mic input... i
don't think you'll be using it for realtime fx :)

jlc

[Juhana Sadeharju]

Hello.

I was reading Ableton Live tutorials at "www.creativesynth.com" and
found the following:

One important point about Rewire hosting - that is shutdown order.
If you try to shut down Live while Reason is running, you will get
a warning that looks something like this:

[ the program cannot quit ]

Don't panic, this is common with all Rewire hosting environments - if
you would quit Live, Reason would have no place to send its audio.
Therefore, you have to jump to Reason, quit the program (saving any
changes you might have made), return to Live and shutdown. A bit of
a hassle, but well worth the effort.

That is another good reason to have the application manager in the
Patchbay --- but it help only if one want to quit. It won't help if
one wants keep the other applications up and running.

If I remove a synth application in Jack, then what happens to the effect
applications in the path? Does they receive silent input or break up?
The silent input would be better because then I could switch the
synth application with a need to remake the whole system.

Regards,
Juhana

[Steve Harris]

On Fri, Feb 13, 2004 at 06:20:48 +0200, Juhana Sadeharju wrote:
> If I remove a synth application in Jack, then what happens to the effect
> applications in the path? Does they receive silent input or break up?
> The silent input would be better because then I could switch the
> synth application with a need to remake the whole system.

They receive silence.

- Steve

[Paul Davis]

>If I remove a synth application in Jack, then what happens to the effect
>applications in the path? Does they receive silent input or break up?
>The silent input would be better because then I could switch the
>synth application with a need to remake the whole system.

silent input, of course.