Consortium

consortium@lists.linuxaudio.org

462 discussions

[Consortium] Re: free linux driver development

by ico＠vt.edu

Many thanks for the prompt reply! > That sounds great, but what can our group do to help you out? Well, I am of the opinion that you have managed to generate quite a significant momentum. For this reason, I see our assistance simply as an extension of your program. Consequently, I also see your initiative as a vehicle by which we will be able to expose our mission. I hope that this will help us establish Linuxaudio.org as the focal entity for all audio matters in Linux. > Is ALSA work slowing down because of this? Are new drivers not getting > written that have specs available? If the latter, then we can help out, > just let me know. I would not say that it is slowing down any more than it already has a couple years ago. This may be also due to the API freeze which took place when the 1.x series hit the streets. That being said, I should probably refrain from speaking on behalf of Takashi and/or Jaroslav. For this reason I've taken the liberty of including them in this mailing, so that they can also share with us their perspective. Therefore, please regard my ALSA comments as mostly personal observation, rather than a fact and/or consensus of the Linux audio community. For what it's worth, I personally feel that ALSA needs to continue to grow and provide things that are pretty much already standard in the proprietary OSS drivers, namely out-of-box hw sharing via dmix and snoop which "just works" and beyond. > Sure, that would be fine. But what really does a "bilateral > relationship" entail? We are a loosly knit 70+ developer team, with not > even a web site or email list (although I am still working on that...) Please pardon my "academinc" language. This simply means that I hope to establish a synergistic relationship where we can use your momentum and PR to expose our entity and mission, while in return we would also serve as contributors to your project by providing audio driver development & support to the best of our members' ability. We actually have a Linux Audio Conference coming up in a few days in Berlin. I will be unfortunately unable to attend so my presentation will have to take place via Internet. Once that is all over with, if you don't mind we should probably do a conference call (Skype/Ekiga/phone?) to figure out details and/or best course of action. Until then, should you happen to have any questions and/or concerns, please do not hesitate to contact me. I sincerely look forward to discussing this matter further. Best wishes, Ico

18 years, 9 months

[Consortium] free linux driver development

by Ivica Ico Bukvic

Dear Mr. Kroah-Hartman, I am contacting you on behalf of the Linuxaudio.org consortium as the currently elected director. Although this email is somewhat belated, I am rolling here with a motto "better late than never." My name is Ivica Ico Bukvic and my interest is in discussing a potential bilateral relationship between your initiative and the Linuxaudio.org consortium. Namely, we would like to offer matching service for the audio drivers by pairing our member developers with potential OEM participants. I am convinced that our membership base has likely greatest understanding of the audio architecture in Linux kernel, including ALSA, OSS, and FreeBob (Firewire audio) drivers. I hope you'll agree the fact that all three projects are currently members of the consortium reflects the trust and support of the Linux audio community's in the consortium's mission. I am also convinced that this step is especially important since ALSA development team (employees of Novell/Suse) has been increasingly encumbered by secondary tasks and as such they have to split their limited resources between the ALSA API and driver development. For this reason, I would like to discuss with you establishment of such a bilateral relationship for the purpose of the overall betterment of audio hardware support on Linux in an effort to help ALSA and other projects persist and perhaps more importantly thrive. I thank you for your time and I look forward to hearing from you. In the meantime, should you happen to have any additional questions and/or concerns, please do not hesitate to contact me. For additional info on Linuxaudio.org, please visit www.linuxaudio.org. Sincerely, Ivica Ico Bukvic, D.M.A. Linuxaudio.org Director Virginia Tech Department of Music - 0240 Blacksburg, VA 24061 (540) 231-1137 (540) 231-5034 (fax) ico(a)linuxaudio.org http://www.music.vt.edu/people/faculty/bukvic

18 years, 9 months

[Consortium] [ANN] FreeBoB bugfix release - libfreebob-1.0.3

by Pieter Palmers

Dear FireWire enabled Linux audio users, libfreebob 1.0.3 is available as from today. It is downloadable at our SourceForge page: http://downloads.sourceforge.net/freebob/libfreebob-1.0.3.tar.gz This is a maintenance release for the freebob 1.0 branch, and contains no new features. It fixes two bugs: - a buffer reset bug that prevented jackd freewheeling from working. - a bug that caused MIDI output to fail on all but the last channel of a device. Greets, Pieter

18 years, 9 months

[Consortium] ANN: munger1~ minor update

by Ivica Ico Bukvic

http://ico.bukvic.net/Max/munger1~_1.0.1.tar.gz (includes changelog and install how-to documentation fixes) Best wishes, Ivica Ico Bukvic, D.M.A. Composition, Music Technology, CCTAD, and CHCI Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-1137 (540) 231-5034 (fax) ico(a)vt.edu http://www.music.vt.edu/people/faculty/bukvic/

18 years, 9 months

[Consortium] ANN: munger1~ port (from the Percolate library) with new stuff

by Ivica Ico Bukvic

Greetings all, For the impatient, download at: http://ico.bukvic.net/Max/munger1~_1.0.0.tar.gz (270KB, includes source, Linux-Pd-i386, Mac-Max-i386, and Win32-Max-i386 binaries, and 3 cases of beer) OVERVIEW ======== munger1~ (March 12, 2007 1.0.0 release) a realtime multichannel granulator a.k.a. the swiss-army-knife of realtime granular synthesis a flext (cross-platform PD & Max/MSP) port of the munger~ object from the PeRColate library (0.9 beta5) http://www.music.columbia.edu/PeRColate/ Original PeRColate library by: Dan Trueman http://www.music.princeton.edu/~dan/ R. Luke DuBois's http://www.lukedubois.com/ Flext port and additions by: Ivica Ico Bukvic http://ico.bukvic.net Ji-Sun Kim hideaway(a)vt.edu http://www.music.vt.edu http://www.cctad.vt.edu Released under GPL license (whichever is the latest version--as of this release, version 2) For more info on the GPL license please visit: http://www.gnu.org/copyleft/gpl.html ACKNOWLEDGEMENTS ================ Many thanks to Dan Trueman for open-sourcing this great object! SOURCE INSTALL ============== If you simply intend to use prebuilt binaries, please skip to the INSTALL section. Otherwise take a big breath and read on... 1) You need stk library which can be downloaded from: http://ccrma.stanford.edu/software/stk/ 2) You need to also install latest flext library (this is a library that allows for creation of externals for both Max/MSP and PD using the same source). Version 0.4.x can obtained from the following link: http://grrrr.org/ext/flext/ Latest CVS version (0.5.1) is found in the Pure-Data CVS (this one is recommended): http://sourceforge.net/cvs/?group_id=55736 3) If you are using latest CVS version (0.5.1) Before compiling the source you will need to add the following to the top of the flext/source/flstk.h file right below the #define __FLSTK_H: #ifdef PI #undef PI #endif This step will probably become quickly obsolete once Thomas updates CVS. Until then, this is needed to be able to compile flext against stk. 4) To compile flext, read flext instructions (it boils down to running build.sh with appropriate parameters and then editing two simple config files, i.e. "build pd gcc build" or "build max gcc" or "build max msvc" etc.) Your will need to edit buildsys/config-<platform-compiler-pdormax>.txt to adjust paths to various folders. Then you will need to edit config.txt file. You do not need to include SndObj for this external but you do need stk option to be properly set. On Windows+MSVC, STK flag at the time of this release does not work, so you will have to use included testmunger1 MSVC project file and adjust path settings to compile munger1~. 5) Once stk and flext are compiled, go into munger1~ folder and type: <path to flext folder>/build.sh <platform> <compiler> <build/clean/install> NB: on Mac <build/clean/install> is not needed. On Windows, please use MSVC and open the testmunger1 project file in the root of the folder. 6) Once compiled, your binary will be created in a <maxorpd-platform> subfolder (i.e. pd-linux, or max-darwin), followed by another subfolder which reflects whether a threaded or singlethread flext was used. Inside you will find your external. INSTALL ======= You can either use the prebuilt externals (found in the bin/ folder) or ones built using the "SOURCE INSTALL" instructions above. Binaries are provided for Intel-based Macs, Win32, and Intel-based Linux OS. The included prebuilt binaries DO NOT REQUIRE you to install flext or stk as these are statically linked. 1) Copy the external in your externals folder (i.e. /usr/lib/pd/extra or C:\Program Files\Cycling '74\MaxMSP 4.6\Cycling '74\externals\, or "Applications/MaxMSP 4.6/Cycling '74/externals) 2) Copy appropriate help file (found in the help/ folder) into the help folder (i.e. /usr/lib/pd/doc/5.reference or C:\Program Files\Cycling '74\MaxMSP 4.6\max-help, or "Applications/MaxMSP 4.6/max-help) NB: Pd help file has a ".pd" extension, while Max/MSP help file has a ".help" extension. 3) Start your app (PD or Max) and create object called munger1~. Right-click (ctrl-click on Macs) and select "help" and this should open the help file with additional documentation. Questions? See OVERVIEW for contact and Q&A info. Enjoy! FAQ === The following is Ico's FAQ, so it may or may not reflect other project participants' opinions, including original author(s) of munger~, flext, etc. Q: Why porting to flext? A: Flext library (by Thomas Grill) is a layer which allows creation of externals for both Max/MSP and PD without any alterations to the code (obviously once it is adapted to use flext). While there have been a number of Max/MSP <-> PD external ports in the past, many of them have become outdated because such attempts required either maintaining one code full of ugly #ifdefs, or worse--maintaining two sources. Either way, what usually turned out to be the case is that original authors did not have the time, interest, or simply the software/hardware to deal with the newly generated overhead and/or test the code, while volunteers who made the original porting efforts eventually moved on to other projects. The result was/is outdated and/or broken externals. Flext circumvents this problem by allowing one clean code to compile on both platforms while also supplying in many cases cleaner (more legible) API and (as a whipped cream on top) object-oriented environment (C++). Q: Why bother with PD <-> Max/MSP cross-platform compatibility... ...when I use only <insert-your-favorite-application-here>? ...<insert-your-favorite-application-here> is better? A: Choice is what makes us human (this is also what makes Arts so vibrant and exciting). And while everyone's welcome to express their own preferences, we also have to realize that in this case these same preferences are also the main cause of a virtual divide which manifests itself at everyone's detriment. Wouldn't it be nicer if we could share externals transparently, or even better, open PD patches in Max and vice-versa? This would help in both the cross-pollination of ideas as well as creative efforts. This project has also taught me that creating flext-ready externals is as easy if not easier (due to the aforesaid API's legibility) than native objects (whether that be PD or Max/MSP). Finally, if all else fails, such externals are bound to reach wider audience, and are much easier to maintain if cross-platform compatibility is to be pursued. Q: If flext is so cool, why don't we see more porting efforts? A: Good question. The fact is that flext is much more widely known among PD users than it is among the Max/MSP community, so this seemingly one-way road may have contributed to the current situation. One could only hope that projects like this may help reverse this unfortunate trend. Q: So, is all really that peachy in the flext-land? A: Well, our lives teach us that nothing is truly free in this world. Flext is no exception. Its "fees," however are not tied to our checkbooks. Rather, they manifest themselves in a slightly greater CPU overhead in signal flow due to message translation. Thus, one could consider flext a "middle-person" between the <app-of-your-choice> and the external. This, however, in today's world is so negligible that during the testing phase I was unable to measure any noticeable CPU-overhead difference. Another consideration is that flext might not be complete (see KNOWN ISSUES for an example). That being said, in its current state it did the trick for a relatively complex external such as munger~ or even FFTEASE collection which had been ported several years ago. All this leads me to believe that it is more than ready for the day-to-day use. Q: I already have Dan and Luke's awesome PeRColate lib. Why should I download this one? A: This is a cross-platform port of the latest version with several new features. Thus, it allows for those platforms which have not had the beta6 available (Linux, Windows) to finally dig into all the goodies it brings. Plus you also get the cool stuff such as verbose modes, discrete panning, more thorough documentation, up to 500 grains per sample (instead of 50), up to 24-channel output (instead of 2 or 16, depending which one you used), etc. KNOWN ISSUES ============ munger1~ has been tested extensively on Linux+PD, OSX+Max/MSP and Win32+Max/MSP setups, suggesting that it should work on other setups as well. Your mileage may vary, though. Currently there is only one known issue in the wild which requires changes to flext in order to be fixed. Namely, if you use munger1~ object in conjunction with an external buffer in PD (known as an array) and if you dubiously decide to delete that particular buffer in the middle of your performance while munger1~ is still associated with it, this will [unsurprisingly] crash PD. Max/MSP currently has a check implemented against that via flext layer so Max/MSP will simply stop outputting anything until buffer is reset. The flext author is aware of this and PD fix should appear in the flext CVS hopefully soon. That being said, the lingering question is why would you want to do this in the first place... FYI, even though munger1~ allows up to 500 simultaneous grains per sample and has been compiled with all available optimizations (SSE, Altivec is supposedly available via flext but has not been tested), on MBP (Core Duo 1.83GHz) I was unable to get more than 160 simultaneous grains per sample (or ~32,000 grains/second) without dropouts, even though CPUs were not getting maxed out, so something else might be the cause of this limitation (flext?). Win32 machine (3-year old AMD64 3000+) fared marginally better at around 165 simultaneous grains per sample (or ~33,000 grains/second) before its CPU was maxed out. Linux on the same AMD64 3000+ hardware fared the best. It topped off at 47,999 grains per second at 48KHz sampling rate which for some reason the sampling rate appears to be the upper limit (i.e. if you run PD or Max/MSP at lower sampling rates, your upper limit will be restricted to the sampling rate), even though the code allows for multiple initiations of grains per cycle. This, however, is also the way original munger~ works. An interesting bit is that while on Linux/PD combo 48K grains are already reached when we get 64 simultaneous grains, on Win32/Mac even 160 simultaneous grains yield only ~32-33K grains. Could this be a flext bug? Best wishes, Ivica Ico Bukvic, D.M.A. Composition, Music Technology, CCTAD, CHCI Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-1137 (540) 231-5034 (fax) ico(a)vt.edu http://www.music.vt.edu/people/faculty/bukvic/

18 years, 10 months

[Consortium] 64 Studio 1.2.0 'Lover's Rock' released

by Daniel James

Hello all, 64 Studio is a GNU/Linux distribution tailor-made for digital content creation, including audio, video, graphics and publishing tools. A remix of Debian testing, it comes in both AMD64/Intel64 and 32-bit flavours, to run on nearly all PC hardware. Our latest development release is based on a snapshot of Debian from the 14th February, so we decided to name it after the song 'Lover's Rock' by The Clash. The iso image can be downloaded here: http://apt.64studio.com/64studio/ Release notes are here: http://apt.64studio.com/64studio/ChangeLog-1.2.0 The 2.6.19-rt kernel package included in this release may cause a kernel oops with certain USB audio hardware. Users of 64 Studio on production systems may therefore prefer to stick with the stable 1.0 release for the time being. Cheers! Daniel James

18 years, 10 months

[Consortium] [ANN] Aldrin 0.11 (Terra)

by Leonard Ritter

Aldrin is an open source modular music sequencer/tracker for the GNU/Linux operating system. We're proud to announce the release of Aldrin 0.11 (Terra). This release is the third release of the "planet" release cycle. Aldrin has been transitioned entirely from wxWidgets to GTK+. Here is a short overview of the most relevant features introduced in this version: * The overall layout of the application has been reworked. Play controls and time bar have been merged into a transport bar. The Master slider is now on the right. Most toolbar buttons have been changed to tabs. * MIDI learn allows you to associate a parameter with a MIDI controller more intuitively by simply moving the controller you would like to bind to. * Various wording changes. * Numerous bugs fixed. Enjoy this new version and visit us on #aldrin on freenode.net, or subscribe to the Aldrin mailing list. http://www.leonard-ritter.com/announcement_aldrin_0_11_terra -- Leonard Ritter -- Freelance Art & Logic -- http://www.leonard-ritter.com

18 years, 10 months

[Consortium] RE: [linux-audio-dev] new releases

by Ivica Ico Bukvic

Great news Fons! I would be nice to have this also posted on the consortium lists especially considering that these are member projects! Please allow me to use this opportunity to remind and encourage everyone, especially consortium membership to please cross-post their important announcements on the consortium list as we do have members on that list that are not a part of the regular la* gamut. Best wishes, Ico > -----Original Message----- > From: linux-audio-dev-bounces(a)music.columbia.edu [mailto:linux-audio-dev- > bounces(a)music.columbia.edu] On Behalf Of Fons Adriaensen > Sent: Saturday, March 03, 2007 11:10 AM > To: Linux Audio Users; Linux Audio Developers > Subject: [linux-audio-dev] new releases > > New releases of JAAA and JAPA and the libraries they depend on > are now available at > > <http://www.kokkinizita.net/linuxaudio/downloads> > > jaaa-0.4.1: bugfixes. > > japa-0.2.0: bugfixes, white and pink noise generators now built-in. > > clalsadrv-1.2.1: bugfixes. This version should now work correctly with > ALSA's default multi-client device. > > clxclient-3.3.2: bugfixes. > > There are also some (essential) bugfixes to the HOA-NF filter > code. > > > -- > FA > > Lascia la spina, cogli la rosa.

18 years, 10 months

[Consortium] Poll for consortium members and board

by Ivica Ico Bukvic

Hi all, In my recent discussion on the future of linux on the desktop, one of suggestions was to look into the continually developing enlightenment desktop solution which does have amazing efficiency as well as steady development pace. My recent investigation on the status of the project has revealed that the project is in dire need of funding for the purpose of getting a new server. This got squeaky cogs in my head turning and I began wondering what if Linuxaudio.org offered them server space for their needs, especially since this is one thing we can offer at practically no cost to us. I've not yet bothered to mention this to the enlightenment team even in a form of a remote possibility, namely because I am not sure if this is something Linuxaudio.org wants to use its limited resources on... So my question/poll to you is, would this be something that bears relevance to our mission (IMHO it does, albeit indirectly). Any ideas/comments? Ivica Ico Bukvic, D.M.A. Composition, Music Technology, CCTAD, CHCI Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-1137 (540) 231-5034 (fax) ico(a)vt.edu http://www.music.vt.edu/people/faculty/bukvic/

18 years, 10 months

[Consortium] Free Linux Driver Development

by jaromil

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 re all, please have a look at this log entry on Greg's webpage: http://www.kroah.com/log/linux/free_drivers.html i find Greg's approach very simple, incredible it wasn't there before! :) is it what a linuxsound consortium would be up to, concerning audio devices? any thoughts? ciao - -- (_ jaromil _)(_ http://korova.dyne.org _) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFF0eX1e2QxhLU0C14RAu8BAJ9dFlqu2Hpo6AdElD5RMLf+uVQMHACgkxdR b5djINW2L/uRfTOxmRtVZtE= =9Wyk -----END PGP SIGNATURE-----

18 years, 10 months

← Newer
1
...
19
20
21
22
23
24
25
...
47
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Consortium