Linux-audio-dev December 2009

linux-audio-dev@lists.linuxaudio.org

87 participants
71 discussions

Start a nNew thread

Faust MIDI?

by Carlo Capocasa

Hi, is it possible to send and receive MIDI with a FAUST program? Carlo

12 years, 7 months

Re: [LAD] FOSS Ethernet Soundcard - IETF Ethernet AVB

by errordeveloper＠gmail.com

Hi everybody, Fallowing up the long discussion i'm trying to sort of give the information you all seem to be missing. there was a meantion of this, but not too many of you have paid any attention: here you can find an article about the current status of the protocol mess: http://prosoundnewseurope.com/pdf/PSNLive/PSNLive_2009.pdf (page 28) obviously eas50 is good to go, but Ethernet AVB is right thing really. the only thing that it's still work in progress, but many of the proprietary vendors, which already have their own networking solution (like Harman with HiQ-net, the one i can name of top of my head) are involved in AVB stadard deveelopment. The idea of AVB is to bypass the IP layer, which is right thing really. you don't need to assign IPs to your audio nodes, really! in avb you'd just have to select channels that nodes whant to listen to. there is a fair bit of documentation on the ietf.org AVB group's page. but XMOS is looking to be the best point of refference: http://www.xmos.com/news/15-jun-2009/xmos-simplifies-ethernet-avb-implement… is think we should forget everything else and crack on with the XS1 AVB implementation! their XS1 chips seem to be really great, their are basically every innovative and open-source minded. the official toolchain is LLVM-GCC based. you can use C, C++ or their own XC. XC is basically C with some stuff omited (like goto and floats) and XMOS IO stuff added, don't just say WTF, look at it first! you should also watch the videos here: http://www.xmoslinkers.org/conference-online-wf especialy the two about the "XMOS Architecture" and the AVB presentation. some dev-kits are quite expencive, but that's due to low-volume really ;) there is alos a nice USB Audio kit! plus there is alittle board that is cheap and has two RJ45's on it already :) I'm myself studying the XC book at the moment. And geting familiar with the tool set :)~~ looks very exciting, cause these are the invovative chips! ok, may be an FPU is really missing on XCore, but how many DSPs have it anyway? well quite a few, but there was no FPU on dsps for ages! :)) also XC or C/C++ are so much more obvious then the bloody "menthal american military engeneers non-sense" called HDL-whatever! Cheers Everyone, Hope you will appreciate my excitment :)~ (l0l) -- ilya .d

14 years, 1 month

Linux Audio Conference 2010

by Marc Groenewegen

Dear Linux Audio developer, user, composer, musician, philosopher and anyone else interested, you are invited to the... Linux Audio Conference 2010 The conference about Open Source Software for music and audio May 1-4 2010 Hogeschool voor de Kunsten Utrecht (HKU) Utrecht, The Netherlands Registration is open, and so is the call for abstracts and papers. More information can be found on the website: http://lac.linuxaudio.org/2010 For previous editions, look here: http://lac.linuxaudio.org For concerts, music and workshops a submission system and protocol will be available soon. In the meantime, ideas and announcements can be sent by e-mail ("lac -at- linuxaudio -dot- org ") or written on the wiki: http://wiki.linuxaudio.org/lac2010 We hope to see you all in Utrecht ! Kind regards on behalf of the LAC team, Marc Groenewegen, lecturer music software design @ HKU

14 years, 10 months

LADI

by Nedko Arnaudov

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>

14 years, 11 months

Congratulations Ardour Team!!!

by Ricardus Vincente

I just got the the January 2010 issue of Electronic Musician in the mail today, and Harrison Mixbus (based on Ardour) was named the "Download of the month." Don't forget us linux guys. ;-) Ricardus... -- Richard V. Wielgosz Audio Engineer, Writer www.richwielgosz.com

14 years, 11 months

workflow

by rosea grammostola

Hi, As this article points out (http://digitaldub.wordpress.com/2009/12/16/linux-audio-session-scripting/), Linux audio has advantages but also disadvantages, which lash/ ladish etc want to solve. But there is another feature in apps which makes the workflow much faster and that is a simple: 'Open recent documents/settings/files' Like you have in openoffice 'recent documents'. I do miss this feature in apps as jack-rack, lv2rack, jack-mixer etc. Btw. I saw an interesting research about open source and usability: http://ingimp.org/ Regards, \r

14 years, 11 months

Re: [LAD] GUI for audio application

by Ralf Beck

Basically every toolkit out there has widgets fader, button, knob. So one you usually only has to reimplement the paint method in order to change the appearance or write a different style. If you prefer a toolkit independent gui library you could use my stripped down version of the vstgui lib, which uses cairo as the drawing backend. Together with skinman and knobman, the two widely used windows programs for generating nice vst guis (running fine in wine) you have basically the same toolchain as the windows vst devs. Drumfix PS: Linux Vst developers, please write VST compliant code. The interface of effEditOpen is effEditOpen(void *), not effEditOpen(void *, void *) i.o.w hosts should send a pointer to a struct {Display *d; Window w;} in (ptr) instead of Display * (val) and Window (ptr)

14 years, 11 months

memory leak assistance

by Patrick Shirkey

Hi, I have some code in gtk2 that is leaking and I can't fix it. Over the past two nights I have managed to get the leak down from 200MB/minute to 200MB/10 minutes but I can't get rid of it completely. It's annoying because it increments in 200MB blocks so I have to wait for up to 10 mins to see if it is fixed or not. I have tried valgrind but it doesn't really like jack and did not give me any useful output. I have traced the leak through normal debugging and have verified that it does not happen if I disable this offending code. This code is run in the widgets realize event and the event is triggered every 500ms. PangoContext *pc = gtk_widget_get_pango_context(widget); PangoLayout *pl; PangoFontDescription *pfd; PangoRectangle rect; pfd = pango_font_description_new(); pango_font_description_set_family(pfd, "sans"); pango_font_description_set_size(pfd, 8 * PANGO_SCALE); pango_context_set_font_description(pc, pfd); pl = pango_layout_new(pc); pango_layout_set_text(pl, "99", -1); pango_layout_get_pixel_extents(pl, &rect, NULL); pango_font_description_free(pfd); g_object_unref(pc); If I add another g_object_unref(pl) ; The app code will compile but when I run it I get this segfault: *** glibc detected *** ./src/jackeq: free(): invalid pointer: 0x0000000001b87a60 *** I can have one g_object_unref for either pl or pc without segfaulting but not both. I'm pretty sure this is the last leak I have to catch for the merged gtkmeter.c/gtkmeterscale.c and I can't release jackeq until it is fixed. Any assistance with this one is appreciated. Cheers. -- Patrick Shirkey Boost Hardware Ltd

14 years, 11 months

Update of jconv

by fons＠kokkinizita.net

Hello all, Updates of jconv, now called jconvolver, and the zita-convolver library are available on the usual place: <http://www.kokkinizita.net/linuxaudio/downloads>/ The new zita-convolver is API-compatible to the previous release but not binary compatible. If you have any code using it please recompile. Release notes for jconvolver and fconvolver 0.8.4 ------------------------------------------------- Jconvolver is a real-time convolution engine. It can execute up to a 64 by 64 convolution matrix (i.e. 4096 simultaneous convolutions) as long as your CPU(s) can handle the load. It is designed to be efficient also for sparse (e.g. diagonal) matrices. Unused matrix elements do not take any CPU time. In contrast to e.g. BruteFir, jconvolver uses multiple partition sizes, small ones at the start of the impulse response and progressively longer ones for the rest. This allows it provide both zero processing delay while still remaining efficient in CPU use. Fconvolver performs the same processing on files instead of real-time. For this relaese the package and the binaries have been renamed to avoid a conflict with an existing 'jconv' package (related to the Japanese language). Functionally this version is identical to jconv 0.8.0. See README.CONFIG for the syntax of the config files. Since 0.8.0 it has been possible to name and connect the Jack ports. The related commands have been added to README.CONFIG. Jconvolver will work with libzita-convolver 1.0.0, but upgrading to 2.0.0 is recommended. Note that if you update the library you have to recompile this package. NOTE: Jconvolver will normally not work correctly when used with Jack's freewheeling mode, e.g. when exporting in Ardour. It _could_ actually work when used on a single processor system, but don't rely on this. This release of jconvolver will print a warning when freewheel mode is entered. The 'mkwavex' utility from previous versions has been replaced by 'makemulti' which offers some more options. Enjoy ! -- FA Wie der Mond heute Nacht aussieht ! Ist es nicht ein seltsames Bild ?

14 years, 11 months

Re: [LAD] [Alsamodular-user] ams 2.0.1

by Peter Geirnaert

Hi Karsten Thanks! First I had a little error returning ... checking for main in -lclalsadrv... no configure: error: clalsadrv is required Then I installed libclalsadrv-dev (1.2.2-1) and now it works. Just one question, (how) can I make ams stop echoing "Unsupported MIDI event received (type = 42)" to the terminal ? I guess it's my controller synth who's sending "active sensing" messages to ams. No showstopper to make some very nice sounds though. Cheers! Peter On Sat, Dec 26, 2009 at 3:52 AM, Karsten Wiese <fzuuzf(a)googlemail.com>wrote: > Hi, > > > ams 2.0.1 has just been released. > > tar.gzip and tar.bzip2 are available at > https://sourceforge.net/projects/alsamodular/files/ > > the NEWS: > ======================================== > ams-2.0.1 (2009-12-26) > > Fixed Bugs > o Compile error for Qt 4.2 fixed > o Highlight MIDI controller in Control Center, > if MIDI event has been received. > o Fix crash unbinding multiple controllables connected to the > same midi controller. > o Initialized variable in env-module. > Fixes env-module mute bug discribed by lee(mrleelee). > > General Changes > o MIDI channel numbering changed from 0..15 to 1..16. > > > > ams-2.0.0 (2009-06-12) > > New Features > o Redesign of 3D look > o Application icon > o German translation > o Keyboard shortcuts for menu and dialog items > o Menu item for recently opened files > o French translation (by Fank Kober) > o New --name command line option to specify the ALSASEQ/JACK > clientname > o Legato in monophonic mode using the "--poly 1" command line > option (by Atte Andre Jensen) > > General Changes > o Port form Qt 3 to Qt 4.x library. > o A newly written autoconf/automake environment now provides the > usual "./configure && make && make install" comfort. > o Command line options are reworked. > - JACK now is the default interface, if the connection fails ams > connects to ALSA. This behavior can be modified using the -J and > -A options. > - The initial patch file to be loaded no longer needs the -l > option. > ======================================== > > > regards & merry xmess, > karsten > > ------------------------------------------------------------- > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Alsamodular-user mailing list > Alsamodular-user(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/alsamodular-user >

14 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev December 2009