Michael Ost:
>
> Paul Davis wrote:
>> On Tue, Jan 12, 2010 at 1:15 PM, Michael Ost <most(a)museresearch.com> wrote:
>>> Hi,
>>>
>>> We are considering using PortAudio for Linux hardware support (and
>>> Windows/Mac as well). What's the word on the quality, reliability,
>>> ease-of-programming, latency and performance in Linux?
>>
>> it works. its development seems to be an issue. it will not fix any of
>> the issues that you'd otherwise have to tackle on linux.
>
> Can you say more about that last sentence? I'm not quite getting it.
>
>> however, i'm puzzled: you guys are already running on linux - what are
>> you using now, and why the switch? cross-platform?
>
> Yes, cross platform. I'm investigating Windows/MacOS support. We've got
> our own portability layer, but it's only really implemented for Linux.
>
> BTW - I looked at JACK, but a quick google scan suggests that its not
> quite ready for prime time in Windows.
>
For what it's worth; Jack on Windows is used for providing sound
in two permanent art installations (http://www.intravisiongroup.com/).
One of them has been running for over two years now. The machines
are rebooted each night, and the oldest one is still using a version of
jack for windows released in 2007.
We've had no problem with jack for windows.
Hi guys, I just wanted to give an update on the integration of
librubberband into TerminatorX.
To understand rubberband, i wrote a small console Jack app that can play
wav files at diferent speeds, keeping pitch. It works well. The code is
attached.
I have a question to for the devs out there though: It seems to me that
i have to run process() a few times with a fixed blocksize before,
getRequiredSamples() returns something >0 in Realtime-mode. All other
options are default options. Is this true? I need some help on this
issue.
thanx Gerald
Hi guys, I just wanted to give an update on the integration of
librubberband into TerminatorX.
To understand rubberband, i wrote a small console Jack app that can play
wav files at diferent speeds, keeping pitch. It works well. The code is
attached.
I have a question to for the devs out there though: It seems to me that
i have to run process() a few times with a fixed blocksize before,
getRequiredSamples() returns something >0 in Realtime-mode. All other
options are default options. Is this true? I need some help on this
issue.
thanx Gerald
Hi everyone!
I had to download a file (split into several parts). Something at the end of
a few of these parts seems to have gone wrong. So I was wondering:
Is split the right utility to split a large binary file? Seemed so.
If I canget the other party to split the big chunks into smaller (say 1M)
chunks and upload the last 1M chunk of the original files, would there be a
way of merging these bits into my files.
It's essentially a big bzip2-file. Might we probably use a bzip2 utility to
get small chunks from the original. Because with bzip2recover I can tell which
blocks are damaged.
Thanks for any help!
Kindest regards
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
Hi,
I don't know who locked himself up after the 'LADI' discussion to
actually write an session handler for Linux. :) But in meantime Ladish
has added 'level 1' support:
"When ladish studio is being saved, applications that are run at level 1
receive the SIGUSR1 UNIX signal.
In signal handler function, a global variable can be set to mark that
save is needed. On next main loop iteration, the global variable is
checked and eventually save is made.
Save of the internal state can be made in a fixed file path, but it is
more useful to supply the file path through commandline. When starting,
app loads its internal state from the file specified. When saving, app
saves its internal state to the file specified."
http://ladish.org/wiki/level1
Ams, Jack_Mixer and calfjackhost (in progress) has already added level
1 support, and it seems to work OK (all though there are some
improvements ahead).
An advantage compared to 'LASH' or 'Ladish' support seems to be that
level 1 is pretty easy to implement by the application developers.
Now I'm wondering whether this 'level 1' could be a point of agreement
between different (potential) Session Handlers for Linux. If other
Session Handlers also adds 'level 1' support, it would make the
implementation of more then one Session Handler more easy and less
problematic for the Linux Audio world in my opinion. What do you think?
Regards,
\r
Hello, this is my very first non trivial program. It's a little python
script that uses sox to create an "audio collage" out of the mp3s in
the directories you pass to it on the command line. I know the code is
very crude, but nonetheless I'm very happy I made it work
Any suggestions on how I could get it to check recursively in the
directories?
renato
Hi there,
some of my plugins stopped working.
Are there any up to date examples of using MIDI ports for LV2 plugins
and/or can someone explain me if and what changed?
Thanks in advance
Uli
dear #lad'ies,
just wanted to say sorry for becoming infected by the (IMO) rogue like behaviour of some person(s) on IRC. hope you don't mind. i think there is nothing wrong with wanting to live in an intact world. and i don't think that i am crazy (or sociopathic) because i have hope that we are in fact living in an intact world right now. if I accept that the world isn't perfect and that "they" *lie* when they say that we are killing the *oh so sensitive* ecosystem BY JUST LIVING OUR LIVES, then I can say that this world is indeed intact and there is no polar bear or planet to worry about! - you see, in the end, all I want is my peace of mind and not being fooled by some *possibly* outdated, interest powered science which just makes me feel ashamed of what we, mankind, have managed!
how do you manage to live your life knowing that you are killing the ecosystem? how can you take all that bullshit without becoming cynical?
down to -20°C tonight in germany - thats reeaaaally hot!
This msg was addressed to the list, not to previous poster.
J.
--- On Thu, 1/7/10, James Warden <warjamy(a)yahoo.com> wrote:
I suggest you continue this discussion in these possible
following forums:
aspo-usa.comwww.peakoil.netwww.theoildrum.comwww.powerswitch.org.ukwww.doomers.us/forum2/
etc, etc.
As to me, I would say: if you know you are fucking up
something, well then, stop fucking it up. And that includes
your own self (top of the list).
J.
>
> --- On Thu, 1/7/10, Bengt Gördén <bengan(a)bag.org>
> wrote:
>
> > From: Bengt Gördén <bengan(a)bag.org>
> > Subject: Re: [LAD] Science (OT)
> > To: linux-audio-dev(a)lists.linuxaudio.org
> > Date: Thursday, January 7, 2010, 9:52 AM
> > torsdag 07 januari 2010 09:20:21
> > skrev Victor Lazzarini:
> > > Well said, especially this one.
> >
> > Not that well though. Have a look into the scientific
> > debates regarding the
> > generation of oil from other sources than fossils of
> > animals and plants. In
> > Nature Geoscience, Volume 2, August 2009 [1]
> >
> >
> > >
> > > On 7 Jan 2010, at 07:51, Stéphane Letz wrote:
> > > > 3) Climate story is probably not the more
> > important short term
> > > > threat (although on long term it may be the
> > one...), I would say
> > > > "peak oil" is *the* short term threat but
> very
> > few people understand
> > > > that correctly.
> >
> >
> > [1] http://www.nature.com/ngeo/journal/v2/n8/full/ngeo591.html
> >
> >
> > /bengan
> > _______________________________________________
> > Linux-audio-dev mailing list
> > Linux-audio-dev(a)lists.linuxaudio.org
> > http://lists.linuxaudio.org/listinfo/linux-audio-dev
> >
>
>
>
>
After recent discussion on IRC I'm loosing faith in whether it is worth
to contribute to linux audio session handling/management. Two reasons
were given why it does not get testing from users. One is that what I
did so far is not mature, has annoying bugs and I'm not wanting to fix
them. The other one is that ladish is not giving more than users already
have with qjackctl. Also it was mentioned that D-Bus is not what users
find acceptable for controlling jack server.
Given the almost missing feedback about LADI development from community
members that could benefit from it, I'm not sure whether I should
continue to contribute. Maybe I should give up on trying to make linux
audio usable for my needs. I could also stop using computers and make
music only by using my guitar. Because alternatives to Linux Audio
(windows/mac) don't suit my needs. Moreover they don't have the
potential to suit. This is why I'm contributing to Linux Audio and not
making VST plugins or something. This anti-dbus movement is getting too
far. If there is no user that accepts my point of view, there is no point
of me contributing.
Because it may be possible that someone has missed the whole point of my
jackdbus and session handling effort, I'll try to explain what I find
wrong/unacceptable in JACK (dbus-less) system as we have it now.
* JACK server tries to kill clients that are suspected to misbehave and
cause xruns or expose other kind of bad behaviour. This can result in
qjackctl (or patchage for example) being killed. IMO, killing control
apps is wrong. Apps that that don't process audio/midi should be
treated differently.
* When jackd is autolaunched, log messages are going to stdout/stderr of
the app that launched them. This is wrong, unix daemons are supposed
to have a log file, even if they are per-user. One of the reasons why
log file is a good thing to have is that it allows to analyze problem
post factum. This helps a lot if some misbehaviour is rarely
reproducable.
* Control apps that start the jack server through jackd know only about
the parameters that were known at compile time. Somewhat recent
example, IIRC, jack2 specific parameters (-S) and firewire options
missing after upgrade of jack because qjackctl does not know about
them. IMO, control apps should be able to query parameters for jack
and display the available options to user.
* Control apps that manage jack connections, are subject to realtime
constraints. IMO, this complicates control apps development for no
good reason. This is valid only for jack1. jack2 already uses
non-realtime threads for port notifications.
* Implementing control app requires C level program or use of specially
crafted bindings. It will be good if control apps could be
implemented with few lines of code in a scripting language as Python,
Ruby, Perl, etc.
* JACK graph (clients, ports and connections) API is badly designed and
is prone to race conditions. Fons talked about this problem recently
too.
* Session handling capabilities are suboptimal. Various programs lurk
here. I'll mention the two most popular ones: qjackctl cant
save/restore internal state of the programs. It also cant save and
then relaunch them automatically. lash cannot manage jack
settings and cannot restore connections for applications that are not
linked against liblash. There are other problems but those are the most
frustrating ones.
* Hardware port virtualization is suboptimal. it is provided through
the JACK "system" client. The only reliable ports are first ones, they
are expected to be the main input/output. If applications wants to
connect to phones for example it does not know on what ports they
are. projects/session should be movable to other system, one with
different hardware setup and [extensive] reconnecting should not be
required.
* Hardware port names are not human readble. Aliases exist but are not
widely used for various reasons. Users should be able to name and
group their ports to match their hardware cable setup.
* JACK "system" client is used for non-hardware ports (-X seq).
* There is no global list of JACK enabled applications.
* JACK MIDI is not widely accepted. JACK AUDIO + ALSA seq appears to be
acceptable solution. IMO, sample accurate audio+midi is very
important.
* There is no session handling for netjack LAN setups.
* Session handling apps cannot restore apps to more than one X11 screen (do
not mix with X11 display).
* Patchage-like (flowcanvas based) patchbay interface is best what I've
seen. Unfortunately Patchage does not integrate well with other parts
of JACK infrastructure.
As you can see, I have collected enough problems to fight. Almost all of
these fixes need new software modules to be written or existing ones to
be rewritten. In past years I've tried to collaborate
with people behind JACK, LASH, Patchage and Qjackctl. At the end, I
think that this attempt was probably wrong, with the only excepton of
jack2 (Stephane Letz) who accepted my jackdbus development into jack2
and we worked toghether on improving it and on the more general
"control API" initiative. The jackdbus code, my first contribution, that
is supposed to improve this mess was rejected by Paul Davis whom
maintains jack1. I've got some patches accepted by Patchage`s
author and maintainer, Dave Robillard, but they were rather cosmetic
ones. This forced me to maintain a software branch (Dave calls it a
fork) called lpatchage. It was supposed to be dashboard for the JACK
system. I also actively participated in lash-0.6.x development. The only
other developper, Juuso Alasuutari, shared some of my ideas, but at the
end we ended with fundamental differences about how session handling
should behave and what lash should become.
As part of my LADI efforts, two people where very helpful. Marc-Olivier
Barre and I managed to create pyjackctl, later renamed to laditools. It
is set of minimalistic but very useful control apps for JACK, a2jmidid
and LASH/ladish. Krzysztof Foltman helped a lot with probably the most
complex app in the laditools suite, ladiconf.
I'd like to mention people with whom collaboration, even if attempted by
me was non-existing: Rui Nuno Capela and Bob Ham. They clearly declared
From start that wont help for various reasons and I appreciate
this. Because this saved my precious time of part-time contributor to
Linux Audio.
In May/June this year, Fons Andriaensen got hit by a forcibly packaged
jackdbus (i'd call it mispackaging of jack) and started a flame war
against D-Bus evilness. I tried to be constructive until I got message
From the packager that dbus was forced, even given that he earlier
stated that he explicitly enabled dbus support in that package for one
reason or another.
In June this year, it become evident that I'm not able to contribute to
LASH anymore and that I want something else. I left the LASH project and
started a new session manager, ladish (project page is at ladish.org).
The first preview was released not long after. It was not yet a real
session manager but it was able to save and restore multiple jack
configs, a foundation for what I call "studio" in ladish. Since then
I've implemented some more stuff and I was hoping that next preview that
will be able to relaunch applications and restore connections between
their jack ports will be ready by the end of this year.
In recent few months, I had less time to contribute to ladish and
development slowed. The anti-dbus statements from various people
continued almost always without real argumentation behind them. For
these that were complains about dbus problems in real setups, I've given
suggestions. Almost always I got ignorace and more anti-dbus statements
in return. Maybe what I did is really unusable by others, despite
it being obviously usable by me. Maybe I suck at trying to help & support
people who seem to think that ladi is not that bad. Or maybe D-Bus
is indeed evil and eats babies and I fail to understand why, even after
I've listen to so many "arguments". Or maybe there are happy people
using jackdbus and laditools (or even lash-0.6.x) and looking toward
ladish. But I dont see them. If community does not share my frustration
with problems of the JACK system I mentioned above and does not accept
my vision that D-Bus is just the most suitable (but not perfect)
technology for what I'm trying to achieve, then it would be better for
everybody if I don't contribute anymore. I can detach from the community
and I can even detach from linux and even computers.
So now is the time to give your positive feedback and constructive
critics. Don't troll and don't start another flame war unless your goal
is to alienate me to stage of me detaching from this community. I will
not respond to trolish and flamish mails, feel free to contact me
with private mails if you prefer so. As I'm cross posting this mail, if
you are subscribed to more than one of the mailing lists, please reply
only to one of them. In order of preference, lad, lau, jack-devel. This
should avoid discussions half-shared between lists. If they happen at
all.
This mail is not supposed to be offensive to anyone. If someone feels
so, I declare that offense is not intentional. I don't deny the right of
different opinion on any subject and thus I have no reason to burn
witches.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
