Linux-audio-dev July 2009

linux-audio-dev@lists.linuxaudio.org

77 participants
66 discussions

by laseray＠gmail.com

>>> Thanks man. I'll forward this to Bob Keller too. >>> I think he mentioned in a message that he is willing to give developers >>> svn access to the recent code. >>> > > > > Really. Last year I found Improvisor and wanted to contribute to it, > > so I got in contact with Bob. I made some changes to integrate the > > application better into the desktop (on Mac OS X also) and did some > > initial cleanup. > > The reaction I received was less than welcoming. In fact, the message I > > got was that they were not interested in really allowing outside > > developers to contribute. Thus my changes were never used, or considered > > as far as I can tell. What I got was a bunch of excuses about the > > situation with the application until finally this Bob guy came straight > > out and harshly refused to cooperate on development. I even had to ask > > numbers of time before I could finally get the source code and this > > resulted in it finally being posted on the group. > > Basically the group that works on it is his student research group at the > > educational institution he is employed at. So it appears that they just > > want to keep all the glory and credit for the application to themselves by > > disallowing outside contributions. This is really not manner that we > > usually associate with FOSS. The fact that you have to subscribe to a user > > group even to get the binary is one big clue. To my mind the only reason > > it is under GPL is because they use other libraries that are, not because > > they see some benefit to doing so. > > The only way to go with this application, at the moment, is to fork it. I > > was considering doing this a while ago, but have other projects keeping me > > busy. If you can convince them to open it up, great. I wouldn't hold my > > breath though. If enough other developers are interested then I could give > > some time to a fork. > This is what he replied me > "If there are developers who are serious, I could provide svn access to > our repository. Right now there are 3 people who are active. We are > about to release version 4, which is almost a year out from version 3.39 > that is in the user group. " > So I think we have to go the working together way first. > I've forwarded the message of Lasconic to him, let's wait for his reply > on that. No, I think you are wrong here to even consider trying to cooperate. I waited after your initial reply to respond because obviously you weren't fully considering my points, so I decided to see what happens. Now a preview of the next version of impro-visor has been released and it is as I expected. No source code, again. Blatant GPL violation again. That was unexpected, not! Where's that SourceForge project also? That's right, it does not exist. I sent a message about the missing source code, again. I wonder what excuses he will give, again (or has he decided to not even respond to my legitimate inquiries now). Last time it was that he was on the road or busy or <enter lame excuse here>. He had the time to package up binaries for Linux, Mac, and Windows, but could not zip up the source and post it at the same time?! Go check that with him and let's see how the responses match what I am saying. Now I am seriously considering forking this application myself, to make sure that everyone can get the current source code, they do not have to join some group just to get the binary, and that real contributions can actually get in. Yeah, I'm a serious developer, but that guy never offered to give me any access and the new version still has bugs that I already fixed which he would not accept. I will give it a little longer, but if these people don't get their act together and start doing things in accord with the GPL, then they should either change their license and remove all GPL stuff or not be surprised when a forked version appears (Improvisor+ sounds good: Improvisor, plus the source code and the ability for others to contribute, and not needing to be in some group just to get it, and ...). There has been plenty of time for them to do the right thing. Time has run out already. Let's not be naive. Some people put out applications as GPL just so they can say they did, but really they just want to ride on the FOSS bandwagon to look good. Then when you try to get involved, contribute, or ask for the source code, all of a sudden they clamp down on things and show you that they want to control everything, as if it is a commercial proprietary program. Sorry this does not fly with me. I have had this experience with another project that thinks they are FOSS and that they can do no wrong. The end result was that I did actually end up having to fork the program because of their inability to conduct themselves properly. Perhaps some other people should get in contact with this project and voice their concerns and views about how FOSS and GPL based projects do things. If they start to do things right, then I won't have to fork it. But either way, the source code and binaries WILL be freely available and without need for membership in some group. Drive that point home if you will. Regards, Raymond Martin

15 years, 10 months

PHASEX-0.12.0-beta3

by William Weston

Announcing the new public beta release of phasex! All phasex users are encouraged to upgrade. Since the days of 0.11.1, all known bugs and many annoying quirks have been worked out, making PHASEX-0.12.0-beta3 is the most stable, best sounding, and most studio friendly release yet: * Fixed all currently known crash issues and build issues. Code has been updated for newer versions of gcc, gtk, and glibc. Realtime threading issues have been fine-tined, using realtime locks where appropriate. The build system has been fixed up for newer distributions and includes default optimizations for the entire x86 family (run './configure --enable-arch=foo', where foo is an architecture supported by your version of gcc). * Sound quality has been greatly refined by reshaping envelope curves (eliminating pops and clicks), adding hermite interpolation to the chorus (removing fuzziness from chorus), adding fine tuning to oscillator frequencies and FM amounts, adding sampled oscillators (currently with Juno-106 and vocal samples), fixing portamento and key triggering logic, and more. * The JACK code has been reworked to allow multiple instances with persistent instance numbers and resilience to JACK crashes and restarts. * The GUI has been refined slightly, with a new color scheme, patch folders in the file dialog shortcuts list, and a couple slight optimizations to the knob code. * There's more. See http://sysex.net/phasex/beta for details if you're that curious. Since 0.12.0-beta2, fixes have been implented for GTK >= 2.16 (fixing Fedora 11 builds), the max polyphony has been turned into a runtime configurable setting, and the build system and default architecture specific optimizations have been fixed up some more. Source tarball and arch specific Fedora 11 RPMS are now available for download: http://sysex.net/phasex/beta/phasex-0.12.0beta3.tar.gz http://sysex.net/phasex/beta/phasex-0.12.0-0beta3.fc11.src.rpm http://sysex.net/phasex/beta/phasex-0.12.0-0beta3.fc11.i386.rpm http://sysex.net/phasex/beta/phasex-0.12.0-0beta3.fc11.i586.rpm http://sysex.net/phasex/beta/phasex-0.12.0-0beta3.fc11.i686.rpm http://sysex.net/phasex/beta/phasex-0.12.0-0beta3.fc11.athlon.rpm http://sysex.net/phasex/beta/phasex-0.12.0-0beta3.fc11.amd64.rpm http://sysex.net/phasex/beta/phasex-0.12.0-0beta3.fc11.x86_64.rpm http://sysex.net/phasex/beta/phasex-0.12.0-0beta3.fc11.ia32e.rpm Build reports and bug reports, and package build files for all distributions are highly welcome. This is the final beta for 0.12.0. Any build and crash issues reported in the next two weeks will be fixed for the 0.12.0 stable release. Please direct any feedback to weston(a)sysex.net. The latest version of phasex can always be found at: http://sysex.net/phasex For those of you who use git: git clone http://sysex.net/git/phasex.git Thank you all for your support, feedback, and contributions over the years, helping to make PHASEX what it is today. Happy music making! --ww

15 years, 10 months

wrapper script (hack alert!) for jack + pulseaudio

by Fernando Lopez-Lezcano

Well, I could not find one so I wrote this simple perl jackd wrapper script[*], I really needed something that would enable jack and pulseaudio to coexist while the jack + pulseaudio situation stabilizes. Not a finished product but seems to work around here (tested lightly on Fedora 10). If you want to try it out (don't blame me if everything stops working!) you should rename your current jackd executable to "/usr/bin/jackd.bin" and put the script in its place ("/usr/bin/jackd" by default, don't forget to make it executable). You need to have pulseaudio, pacmd and pactl available in /usr/bin/. If pulseaudio is running the script will suspend it, start the real jack, wait for it to be ready and finally load the pulseaudio module module-jack-sink (but it does not make it the default). You could then manually transfer pulseaudio streams to it. If pulseaudio is not running the script just execs the real jackd (set $verbose to 0 in the script if you don't want the extra messages). The script also traps <ctrl>c and the kill signal, unloads the module-jack-sink module, passes the signal to the real jack and when it is dead unsuspends pulseaudio. I don't know if trapping more signals would be necessary. WARNING: if you transfer a pulseaudio stream to the jack sink module and then stop jack without unloading it, pulseaudio becomes very very unhappy and dies, oh well. You can get it going again with "pulseaudio --start" (at least in Fedora 10). I guess more code could be added to automagically transfer pulse audio streams back and forth to the jack sink module when jack starts and stops, and also make it the default. It seems it would take a lot of parsing of command outputs to do that. Anyway, as I said before, just a __temporary__ hack... Enjoy! -- Fernando [*] why perl? tried bash and could not get the signal stuff to work and don't know no python :-) Perl hackers: I could not make exception catching work around the open3 call to catch potential errors, help with that would be welcome!

15 years, 10 months

more ConsoleKit

by Fons Adriaensen

Hi all, Just happened to use top with all threads displayed (H). Anyone able to explain why console-kit-daemon is running more than 60 threads ? System is Fedora 10. -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

15 years, 10 months

Songanalysis and LADSPA plugins

by Julien Claassen

Hello all! I've known this package "songanalysis" for quite some time. But now I wondered, if it might be possible to build a LADSPA plugin from this, or if it would be possible to include it in ecasound as an option. It can do tempo analysis, but more importantly it can do frequency dependent volume analysis, which might be very helpful for text-based mastering. It uses a special scale Mel? or was it Cepstra? to set the static bandwidth. Not as good as graphic JaMIN output, but certainly of more help than ears only for a first stab. :-) The package is here: http://nixbit.com/cat/multimedia/audio/songanalysis/ You'll find a small description and a download link there. I know there's one limitation to the code as-is: It only works with 44100Hz, as I remember. I'd be greatful for any ideas, oppinios on this. 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

15 years, 10 months

ocaml bjack library

by Justin Smith

Is anyone out there using the ocaml bjack library? I am going to be working on a program that interprets an svg file as a synthesis graph, with just the basic puredata objects to start with. I will be using inkscape as the editor for the synthesis graph (polygons are processing units, diagram connectors are signal paths). It seems like, with the higher level processing I will be doing on the input .svg xml file, ocaml would be an interesting language to use for this. Has anyone out there used the bjack library for ocaml, and if so would you happen to have some example code I could look at, like maybe a program that just passes its input to its output? Google is not helping me much, mostly getting stuff related to the debian/ubuntu packages, and not the use of the library.

15 years, 11 months

Re: [LAD] USB2 audio?! (Re: Alesis AudioLink)

by Jonathan Woithe

Hi > On Wednesday 08 July 2009 17:43:47 Juhana Sadeharju wrote: > > Why Linux does not support USB2 audio devices? > > Where is the problem? (How can I help?) > > Repeating the archive: For a rather long time, there was no usb2 audio > standard. Each device had its own proprietary protocoll only the vendors know. > Hard to support in linux. Now there is a standard. But no device actually uses > it because they all already have their own protocols. So in the end nothing > has changed. > > And except from making the vendors publish their specs, there is nothing you > can do. This is of course very close to the problems we had with firewire devices: there were published standards but they weren't always used. The difference here was that some vendors *did* adopt the standard which made things a bit easier. Even so, most still utilised vendor-specific extensions (especially for device control). AFAIK FFADO got started through the cooperation of one or two vendors and as momentum has built additional vendors have come on board to a greater or lesser extent. I expect something similar will have to happen for professional USB2 audio devices to be generally supported under Linux. Of course the other way around the problem is to do protocol analysis, but this really is the "last resort". However, in many ways this is harder on USB because as I understand it you can't have two USB bus hosts (ie: two PCs) connected to the same bus. You can probably do it using virtualisation so long as the virtualiser supports USB passthrough. The kernel's usbmon facility may then give access to the traffic as it flows. For this to work you'll need a pretty fast PC since you'll be running audio applications under a virtualised environment - I'm not sure the required timing can be met even on today's fastest hardware. In any case, there will be a lot of work involved in getting a start on this if vendor documentation is not forthcoming. I should add that from my point of view, drivers written without vendor support are really to assist those moving to Linux from other platforms who already have considerable investment in interfaces which they cannot or will not replace just to switch platforms. If considering the purchase of an interface specifically for use under Linux I would encourage you to purchase from a vendor who actively supports Linux - thereby giving them a reason to keep doing so. Regards jonathan

15 years, 11 months

Re: [LAD] Linux-audio-dev Digest, Vol 29, Issue 7

by Jeff McClintock

Hi Chris, > > " 3.4 ?Install any non side-by-side shared files to the correct > locations > I've only just got around to reading this properly, but it seems to be > saying the opposite of what you said -- it seems to be saying that > components that are shared across multiple vendors (such as audio > plugins of this type, presumably) may indeed be placed in the system > directory. Am I reading it wrong? "to ensure backward compatibility" i.e. The old way was to write dlls to the system directory. This is the cause of 'dll hell' - updating one application breaks another. Windows now bends over backward to avoid this. The new way is 'side-by-side' system components where each version gets it's own directory. Virtualization ensures each application uses the version is was originally written with. Side-by-side doesn't apply to application plugins I think, more intended for operating system components. Shared plugins go in "../Program Files/Common Files/" Best Regards, Jeff

15 years, 11 months

USB2 audio?! (Re: Alesis AudioLink)

by Juhana Sadeharju

Why Linux does not support USB2 audio devices? Where is the problem? (How can I help?) USB2 digital TV device seems to output 10 GB in one hour. That would match 28 channels of audio. Juhana

15 years, 11 months

RFC: Default discovery paths for LADSPA, LRDF, LV2 and DSSI (and more?)

by Stefano D'Angelo

Hello LADSPA, LV2 and DSSI specifications do not reccomend default discovery paths where hosts may look for plugins, which IMO is bad for the end user because: * end users shouldn't be asked to know about path environment variables by reading documentation in header files or looking for it on the web; * when their environment path variables are not set, some hosts choose to scan some hard-coded directories, but this changes among hosts and gets a lot worse on non UNIX-like operating systems (read Windows) - for example some might look inside some subdirectory of the current user's home, others might only look in /usr/lib/<api>, etc. Hereby I propose some default paths which could be used, in the hope that API authors lurking around here might want to recommend them and host authors might want to use them: LADSPA Unix-like OSes with FHS/Unix-like filesystem layout: /usr/lib/ladspa, /usr/local/lib/ladspa, ~/.ladspa Windows: %PROGRAMFILES%\LADSPA, %APPDATA%\LADSPA Mac OS X: /Library/Audio/Plug-Ins/LADSPA, ~/Library/Audio/Plug-Ins/LADSPA DSSI Unix-like OSes with FHS/Unix-like filesystem layout: /usr/lib/dssi, /usr/local/lib/dssi, ~/.dssi Windows: %PROGRAMFILES%\DSSI, %APPDATA%\DSSI Mac OS X: /Library/Audio/Plug-Ins/DSSI, ~/Library/Audio/Plug-Ins/DSSI LV2 Unix-like OSes with FHS/Unix-like filesystem layout: /usr/lib/lv2, /usr/local/lib/lv2, ~/.lv2 Windows: %PROGRAMFILES%\LV2, %APPDATA%\LV2 Mac OS X: /Library/Audio/Plug-Ins/LV2, ~/Library/Audio/Plug-Ins/LV2 Plus, we could do the same for LRDF data: Unix-like OSes with FHS/Unix-like filesystem layout: /usr/share/ladspa/rdf, /usr/local/share/ladspa/rdf, ~/.ladspa/rdf Windows: %PROGRAMFILES%\LADSPA\rdf, %APPDATA%\LADSPA\rdf Mac OS X: /Library/Audio/Plug-Ins/LADSPA/rdf, ~/Library/Audio/Plug-Ins/LADSPA/rdf What do you think about it? Stefano

15 years, 11 months

2025

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 July 2009