Building LADI and installing LADI tools for 64 Studio 3.0-beta3 seems to
be fine, *when ignoring the warnings for flowcanvas*, but I had no time
to check if the installs will work. So compiling only for Suse failed.
Recent discussion on LAU morphed into an idea for an Ethernet driven
sound card, and as this is now becoming a real development the
suggestion was made that it would be better to transfer the discussion
here.
The rationale in brief:
No proprietry hardware soundcard needed.
Almost all modern computers have reasonably fast Ethernet connections.
Potentially up to 20 channels per card - reality will probably be a lot
different!
FOSS drivers to connect Ethernet to whatever audio server is on the
computer - looking at jack right now.
FOSS within the soundcard module so that protocols/algorythings can be
tuned for best results.
FOSH design enabling hardware to be developed and inproved by anyone.
A number of people have shown interest in this, and we are at the stage
of starting to knock together some basic hardware for a feasibility
study.
State of play:
On Mon, 23 Nov 2009 14:39:48 +0100 (CET)
karl(a)aspodata.se (Karl Hammar) wrote:
> Folderol:
> > On Sat, 21 Nov 2009 12:25:36 +0100 (CET)
> > karl(a)aspodata.se (Karl Hammar) wrote:
> >
> > <snip>
> >
> > > Would this project plan be ok:
> > >
> > > software and hw: Karl
> > > testing and spec's: Folderol
> > > publication via web: anyone??
> > >
> > > git repo: git://aspodata.se/openhw.git
> > > mailing list: hopefully this list, else I put one up at my site
> > > web site: ??
> > >
> > > intial platforms (both by Atmel):
> > > . ATNGW100 (cheap), and
> > > . AT91SAM9260-EK (expensive)
> > >
> > > Next step:
> > > . set up development platform
> > > . simple test with spi and shift registers
> > >
> > > Regards,
> > > /Karl
> >
> > This is all fine by me, but I would make quite clear that if someone
> > comes along with access to a {loadsamoney} spectrum analyser I'd be
> > perfectly happy to step back and take a more supporting role.
>
> Ok, I should get starting then.
>
> Regards,
> /Karl
Others would be welcome to come on board - pardon the pun!
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Wow! A lot been said since I opened my mouth :o
First an apology!
When I started this thread I CC'd LAU hoping to just bring interested
people over. I didn't expect the cross-post deluge that followed -
Sorry. I won't do it again :(
For those in doubt the original discussion started over on LAU as a
complaint about the state of USB support on Linux.
My take is very much like Karl's in many respects.
I want to keep well clear of any propriety issues such as patents,
licenses etc. You can't get much more 'free' that real analog audio,
and Ethernet is a pretty much universal and unencumbered standard. If
all the software and hardware remains open then I think we're pretty
much covered.
Another reason for going for a nuts & bolts build is that it will be a
*fun* challenge. I certainly do not expect broadcast standard feeds from
our first attempt, but if we can produce something that is reliable and
repeatable then I'm sure those that are more experienced than myself
will be able to point us in the right direction for fine tuning both
the hardware and software, but we really need a brick in place first.
Karl and I and some others I think more or less agreed that the first
step was to produce a simple development board with just two inputs as
a starter. The unit that Karl though most promising already has 16bit
DACs on board so a complete 2 in 2 out should be realisable fairly
quickly. For this first test, I'm not at all concerned about noise
levels. I think getting a reasonably low distortion conversion without
any discontinuities is the first target.
If the triggering of fast ADCs is controlled by a reasonably accurate
Xtal standard is doesn't really matter if the computer end drifts
about a bit, the odd lost packet should be recoverable and jack really
won't care as long as it's buffers are filled and emptied within the
overall time frame.
I know very little about networking, but the Wikipedia link very
much confirms my early thoughts that there aren't
any effective standards in place.
UDP also looks the way to go. Everything is permanently listening to
everything else, but only the master controller sends out polling
messages dictating which slaves will 'speak'. To me, this keeps the
protocol as simple, fast and flexible as possible and should completely
avoid collisions. It would seem other people have come to a similar
conclusion.
As we are working FOSS, everything is open for scrutiny and later
development of the messaging system is not a great hardship. Practical
experience can dictate what *really* is good and what isn't.
A little bit of sad news.
I decided to fire up my ancient valve voltmeter, notch filters etc. and
have a look at the distortion products from a mathematically generated
1kHz sinewave spat out by my 2496 sound card, just to give some form of
reference. Unfortunately the meter has gone to that great repair shop in
the sky :(
So...
My immediate project is now to build myself a battery operated digital
AC millviltmeter with true RMS volts and dB scaling based around Analog
Devices AD636.
Parts are on order :D
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
"Gabriel M. Beddingfield":
> So you see, by using a mutex... you have to consider
> those sections of code as being a part of your
> process() function.
Great explanation, but you forgot to explicitly mention
that those sections of code also has to run with higher
or equal priority as the jack process to avoid priority
inversion.
Arnold Krille:
> Locks and waits are not realtime save.
Not always true. But usually: yes. :-)
>
> And how many of them are open standards?
>
>
> Flo
The only "usefull" would be AES50-2005 because it is royalty-free.
([..] SuperMAC provides 48 channels bi-directionally over Cat 5 cable,
while HyperMAC provides up to 384 channels bi-directionally over Cat 5 or Cat 6 or fibre.
The signal format includes embedded clocks in the same way that AES3 does. [...] )
There is association AES50 Trade Association http://www.aes50ta.org/http://www.supermac-hypermac.com/
For non commercial usage they are planning to give free SDK for dsp platforms.
([...] Software Development Kits (SDKs) for use with Xilinx Spartan-3E and -3S series field programmable gate arrays (FPGAs) [...])
http://www.prosoundweb.com/article/klark_teknik_announces_several_aes50_pro…http://www.techietalk.co.uk/news/klark-teknik-announces-major-aes50-develop…
For commercial usage they charge £500 towards administration costs.
Details of licensing can be found here http://www.supermac-hypermac.com/licensing.php
Nevertheless, I can support open protocol development with my work since I am writing right no my theses on audio networking.
Pawel
----------------------------------------------------------------------
Wygraj pobyt w Alpach dla ca�ej rodziny
Kliknij >>> http://link.interia.pl/f2446
Dear reader,
as has been announced here 2 days ago by Marc Groenewegen, the next Linux
Audio Conference (LAC#8) will take place at the HKM in Utrecht, Netherlands,
from May 1st - 4th, 2010 (see http://lac.linuxaudio.org/2010).
We have now opened the Website that accepts paper submissions. Please direct your
browser to http://lac.linuxaudio.org/2010/openconf
For those who have been following the LAC activities in the past years: It's
the same used&tested "OpenConf" web-based system that allows us to easily collect
paper submissions, review them and create a programme from accepted papers.
The available categories for paper submission looks like this:
* Ambisonics
* Education
* Live performance
* Audio Hardware Support
* Signal Processing
* Music Composition
* Audio Languages
* Sound Synthesis
* Audio Plugins
* MIDI
* Music Production
* Linux Kernel
* Physical Computing
* Interface Design
* Linux Distributions
* Networked Audio
* Video
* Games
* Media Art
* Licensing
Note that "Video" is also in the list. Yes, that's not strictly Audio :-), but
we feel that the two disciplines are close enough to one another to allow
opening up the conference scope a bit here. After all, we have already had
several very nice audio/video gigs in the past (some might remember the YUE
concert in Karlsruhe 2006 with a remote VJ live from Italy, which was pretty
groundbreaking at that time).
Also, we very much welcome practical papers resp. software demos ("how I use
Linux Audio applications to create my music/media art").
The web page also holds the paper templates that have to be used for submissions.
Pick one of the two provided templates (LaTeX or OpenOffice), author your paper
and convert it to PDF, then upload that PDF. Make sure you are using A4 as
paper size.
Some constraints:
- The conference is held in English, so the paper has to be in English too.
- Length of a paper is 4-8 pages. Papers have to include an abstract (50-100
words). Also, papers should include up to 5 keywords.
- The copyright of the paper remains with you (of course), but we reserve the
right to create printed proceedings from all submitted (and accepted) papers.
- We have fixed the following dates:
- Deadline for paper submissions: February 14th, 2010
- Notification of paper acceptance: March 14th, 2010
- Deadline for final version of paper: April 4th, 2010
Please note that the OpenConf system is only to be used for paper submissions;
for concert pieces ("Call for Music") or sound installation proposals, please
contact us directly by email ("lac -at- linuxaudio -dot- org ").
We are looking forward to many interesting submissions for the 8th
Linux Audio Conference and we hope to see you in Utrecht in 2010!
Please feel free to forward this e-mail to anybody who might be
interested - mailing lists, blogs, Linux portals, magazines, you name them.
Public relation work for this conference is something we need, and where
everybody can easily help.
Thanks for reading.
On behalf of the LAC2010 organisation team,
Frank Neumann
Kevin Cosgrove wrote:
>> Yes, there is an overview over protocols here:
>> http://en.wikipedia.org/wiki/Audio_over_Ethernet
> Seems like the latter reference is quite far ahead of the IEEE
> thoughts.
And how many of them are open standards?
Flo
--
Machines can do the work, so people have time to think.
public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net
Atte André Jensen wrote:
> I wonder why no company took up this idea already, it seems so sleek and
> logical. (Almost) every computer has ethernet and the ethernet standard
> is (in my experience) problem free...
A lot of companies are working on this, but for anything but a simple
audio in/audio out you need technology that's not yet available to the
broad public - at least not to the usual prices. Check out the AVB
specification (IEEE 802.1).
In the broadcast/studio segment, transport over ethernet is already in
use by some manufacturers.
Flo
--
Machines can do the work, so people have time to think.
public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net
Hi :)
*Clarification from the viewpoint of a user*
For me, as a user only, there are some "reasons", resp. "fears" why I
never tested LADI:
I don't know what exactly it can handle. Which apps can be handled by
LADI? What needs to be set up for the apps? In other words, will it
really handle a session or just some points of a session? I once tested
LASH and it wasn't able to handle anything I need. Without much
knowledge about writing shell scripts, I'm able to launch wanted apps
and restore connections, not the perfect way I would like to have, e.g.
because I still need to place the windows, but without trouble, while
e.g LASH does not do this this job, maybe because I missed to google for
hours to learn the basics about LASH.
Are there packages or do I have to compile it by solving a dependency hell?
How will it handle a session when some audio apps tend to crash on my
machine? Will this cause trouble for LADI? Is LADI some kind of program
that will run during the session or will it just run similar to a shell
script just to launch and restore a set up, resp. just when saving a set
up? When using a session handler, will it be possible that an app that
normally is stable, become unstable?
A shell script isn't a session handler, but anyway it can restore a lot
and that without any requirements, limitations, because of apps that are
not compiled to be fine with LASH, LADI or what session handler ever.
*Willing to test it*
I'm willing to give LADI a chance and try to add it to my 64 Studio
3.0-beta3 x86_64 and openSUSE 11.2 x86_64.
I'm willing to spend some hours to google and read about LADI.
*But*
I'm not willing to troubleshoot any problems, if it would make handling
my sessions more difficult, than it would be without "a", resp. "this"
session handler.
I guess I can try to add LADI this week to my Linux installs :).
Cheers,
Ralf
>
> [LAD] LADI
>
> * This message: [ Message body
> <http://lalists.stanford.edu/lad/2009/11/0310.html#start> ] [
> Respond
> <mailto:linux-audio-dev@@music.columbia.edu?subject=Re:%20%5BLAD%5D%20LADI&replyto=87aayhdkbr.fsf@usbix.spacelabs.org>
> ] [ More options
> <http://lalists.stanford.edu/lad/2009/11/0310.html#options2> ]
> * Related messages: [ Next message
> <http://lalists.stanford.edu/lad/2009/11/0311.html> ] [ Previous
> message <http://lalists.stanford.edu/lad/2009/11/0309.html> ] [
> Next in thread
> <http://lalists.stanford.edu/lad/2009/11/0312.html> ] [ Replies
> <http://lalists.stanford.edu/lad/2009/11/0310.html#replies> ]
>
> From: Nedko Arnaudov <nedko@email-addr-hidden
> <mailto:nedko@email-addr-hidden?subject=Re:%20%5BLAD%5D%20LADI&replyto=87aayhdkbr.fsf@usbix.spacelabs.org>>
>
> Date: Fri Nov 20 2009 - 22:15:20 EET
>
> 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>
>
>
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
hi...
on a side note to the LADI discussion, which might even be my fault,
i want to tell you what i am currently up to.
in my opinion the inherent fail of session handler stuff, is that
somehow it wasnt easy enough or too complex to integrate lash support
into apps.
also many people didnt like to use some other ipc mechanism...
so to me the most natural way to do session notification was adding it
to jack. most apps are already listening for some jack callbacks.
(at least they should be listening for shutdown :)
so in my working copy of jack1 i have added 2 API calls:
typedef char *(*JackSessionCallback)(jack_session_event_t code, const char* session_dir, const char* prefix, void *arg);
int jack_set_session_callback(jack_client_t *client,
JackSessionCallback session_save_callback,
void *arg);
struct session_command * jack_session_notify (jack_client_t* client, jack_session_event_t code, const char *path );
by calling jack_session_notify() the session callbacks of the listening
clients are invoked.
they are supposed to save their state, and return a string which
specifies, how they want to be restarted. the prefix parameter is unique
and there is a method to make this persistent over session reload.
the aggregation of the returned strings and unique ids is returned by
the notify call.
i have also changed jack_client_open which is able to accept a client
specified unique id. (this must be used when reloading state, so that
clients can be found again
so... a potential session handler is still required. and it needs to be
able to query the portconnections.
in order to restore them.
but clients are not required to have an extra dependency in order to
support sessions.
you may have noticed that this is currently ignoring alsa connections.
but i think we only need to add a way to publish an alsa seq id
via this protocol.
then a pure alsa client would also need to link to libjack and create a
jackclient with no ports and no process callback, in order to
participate in session handling.
i dont see a difference. it just links to "some" session handler lib.
the only disadvantage i am seeing currently is that apps are treating
jack like an abstract audio output, and getting a jack signal up to the
gui layers where the invokation of save is generally happening is a bit
cumbersome.
so far i have only patched oom and ardour. and ardour doesnt quit yet,
when requested.
well... tell me what you think :)
--
torben Hohn
