Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7520 discussions

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

16 years, 5 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!

16 years, 5 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.

16 years, 5 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

16 years, 5 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.

16 years, 5 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

16 years, 5 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

16 years, 5 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

16 years, 5 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

16 years, 5 months

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

by Jeff McClintock

> From: Chris Cannam > On Thu, Jun 25, 2009 at 9:13 PM, Jeff McClintock<jef(a)synthedit.com> > wrote: > > Windows has official rules for this. ?Users are no longer allowed to > add > > random files to an application's directory in "/Program > Files/Appname". > > Oh! This is news to me -- interesting news too, given that I > distribute Windows versions of SV without an installer and just expect > the user to copy it to %ProgramFiles% if they want it to go there, and > that it only looks in immediate subdirectories of %ProgramFiles% for > plugins of any sort. > > I don't recall anyone complaining to me that they couldn't install > plugins for it -- maybe this just means nobody is using it?! On Windows XP, many people run as administrator, so they won't notice anything. On Vista and Windows 7, they will get a 'UAC' Warning that they are doing something restricted. > Can you point to any documentation for this? I'd like to know what > other rules I might be falling afoul of. http://msdn.microsoft.com/en-us/library/ms995843.aspx (most of that is about system dlls and versioning). The relevant part for plugins is... " 3.4 Install any non side-by-side shared files to the correct locations The proper location for shared components depends on whether these components are shared across companies or by a single company. Shared components that are private to a single software vendor must be installed in one of two places. Do not store these files in the system directory common files directory\<company name> %ProgramFiles%\<company name>\Shared Files The common files directory can be accessed by passing CSIDL_PROGRAM_FILES_COMMON to the SHGetFolderPath API." > typically > > "C:\Program Files\Common Files\LADSPA Plugins..." > > I don't suppose you happen to know whether any Windows-based LADSPA > hosts are actually using this path? I don't know about LADSPA..but the latest Cubase uses "C:\Program Files\Common Files\Steinberg\VST2" for 3rd party plugins. Personally I think the company name could be omitted because many other individuals and companies need to put plugins in there too. Jeff M

16 years, 5 months

Jump to page:

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