Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7440 discussions

[linux-audio-dev] LinuxTag 2004 Audio booth: Helpers wanted!

by Frank NEUMANN

Hi all, the conference is just over, and here comes the next annual event: The LinuxTag, Europe's largest expo about our beloved operating system, takes place in (guess!) Karlsruhe from June 23rd-26th, 2004. Just like in the last..uhm..3 years, we are going to put up a "Linux Audio" booth there, demonstrating some of the current software, helping people with issues and generally "spreading the good word". If you are interested in helping with this, please contact me by mail (or here on the list, though I sometimes don't read it for days) and let me know about your availabilities, specific points of interest, possible hardware you are going to bring etc. We'll be granted a free booth of roughly 5x3m which we'll fill in with some MIDI gear, active speakers, PCs/Notebooks etc. It was always fun the last years (including the famous KaLug party on Saturday at the university campus), and it would be cool to see of last year's helpers again (I know Jörn has already agreed he'll come again). For more info, please read http://www.linuxtag.org . So, any takers? Thanks for reading, Frank

20 years, 4 months

[linux-audio-dev] API for Input / Output plugins

by J_Zar

Hi all, the reason of this mail is searching for opinions about an API for input / output plugins. Besides I see around the LADSPA API for sound processing but nothing similar for input / output. From some months I'm playing around with audio I/O libraries: I met too much libraries but no one really complete satisfacting my needs( thinking to latency and other advanced issues having on djing programs as an example). Not talking about driver complete support: PortAudio does not support ALSA, libao does not support Win,MacOsX and so on... Playing with plugins about some program I had another problem: I played with Alsaplayer ( very nice and powerful program! ) trying to reuse its plugins. I found although, that using them means including ( with hardcode ) lot of the Alsaplayer code. I played with Xmms too: this time the work is easier and there are all sort of plugins but mostly are thinked for merely playback withouth latency control... ;-( However, what about writing an advanced API for I/O plugins, completely detached from other programs ( as Xmms ), potentially multiplatform, to suit the needs of the big part of audio programs? I mean, a plugin written for a certain API ( i.e. ALSA, OSS, Jack, OsX etc... ) will be usable for all other applications with all advantages of a plugin architecture and standard code... Input plugins are important too: I see lot of apps rewriting continuosly Ogg, Mp3 or Wav support in any kind of flavour, but not always reusable code. About writing it once for all? I wanna know: there are people interested in this? My discussion is out of any order, not clever, low level? There is disadvatages on this idea? Suggestions? If there is a reason: Plugin API For Input Output ( PAFAIO ) sounds well??? Hoping in some answers.... Cheers, -- J_Zar Gianluca Romanin ---------------- see you at OpenJay.Org

20 years, 4 months

[linux-audio-dev] ANN: New MidiShare/ALSA driver for Linux

by Dr.Graef＠t-online.de

Hi, msAlsaSeq, an ALSA driver for the Linux version of Grame's MidiShare (http://www.grame.fr/MidiShare/), is now available in MidiShare cvs (http://www.grame.fr/MidiShare/SCPP/dev.html). You can find it in the development branch (-r dev) in the src/linux/drivers/alsa directory. The driver lets you connect to ALSA devices and other ALSA sequencer clients from MidiShare applications. It can be used instead of the msRawMidi, msRawSerial and msInetDriver clients if you're running ALSA instead of plain ol' OSS (which you should ;-). It also allows you to map ALSA client ports to corresponding MidiShare ports. A manpage is included. Please direct comments and bug reports to the midishare-dev list or Dr.Graef(a)t-online.de. Enjoy! Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikwissenschaft.uni-mainz.de/~ag

20 years, 4 months

[linux-audio-dev] aeolus surround

by Jesse Chappell

When you set the channel count >2 do the output channels have a specific spatial positioning defined? Or would it make more sense to output B-format and run it through one of the Ambisonics plugins to get a specific speaker layout? jlc

20 years, 4 months

Re: [linux-audio-dev] API for Input / Output plugins

by Jorge García

Hi, and what do you think about gstreamer? I have been two months reading LAD's list and nobody had commented nothing about those libs. Either in ZKM's conference. I have done some tests with gstreamer and I really like it. Maybe the doc is not very updated and completed, but there are a lot of public plugins to learn and there is alsa, oss, jack and LADSPA support. Bye, Jorge

20 years, 4 months

Re: [linux-audio-dev] kernel 2.6.6 just out

by eviltwin69＠cableone.net

Good question. I had already read that and was curious myself. Also, how about 2.6.6-mm1? I want to upgrade to Fedora Core 2 and a new kernel so I can quit pissing off Paul D. and the guys with my 2.96 gcc ;-) Jan On Mon, 10 May 2004 16:50 , Robert Jonsson <robert.jonsson(a)dataductus.se> sent: >Hi, > >As a service to all readers, here's an excerpt of the Changelog concerning >latency: ;) > >akpm(a)osdl.org> > [PATCH] Add mpage_writepages() scheduling point > > From: Jens Axboe axboe(a)suse.de> > > Takashi did some nice latency testing of the current kernel (with -mm > writeback changes), and the biggest offender in general core is > mpage_writepages(). > >akpm(a)osdl.org> > [PATCH] ia32: 4Kb stacks (and irqstacks) patch > > From: Arjan van de Ven arjanv(a)redhat.com> > > Below is a patch to enable 4Kb stacks for x86. The goal of this is to > > 1) Reduce footprint per thread so that systems can run many more threads > (for the java people) > > 2) Reduce the pressure on the VM for order > 0 allocations. We see real life > workloads (granted with 2.4 but the fundamental fragmentation issue isn't > solved in 2.6 and isn't solvable in theory) where this can be a problem. > In addition order > 0 allocations can make the VM "stutter" and give more > latency due to having to do much much more work trying to defragment > >akpm(a)osdl.org> > [PATCH] reiserfs: scheduling latency improvements > >akpm(a)osdl.org> > [PATCH] unmap_vmas latency improvement > > unmap_vmas() will cause scheduling latency when tearing down really big vmas > on !CONFIG_PREEMPT. That's a bit unkind to the non-preempt case, so let's do > a cond_resched() after zapping 1024 pages. > > >So... humbly asking, is it time yet to make the switch? :-) >

20 years, 4 months

[linux-audio-dev] high resolution time patch for 2.6.5 kernel

by Maarten de Boer

a collegue pointed me to this post about a high resolution time patch for the 2.6.5 kernel. i'm not 100% if it has been mentioned here before, nor of how much interest it is, but just in case. http://lwn.net/Articles/81400/ maarten

20 years, 4 months

Re: [Agnula-Developers] Re: [linux-audio-dev] Request to audio

by Takashi Iwai

At Wed, 12 May 2004 12:16:37 +0200, Alessandro Rubini - FSFE wrote: > > > Sorry for the delay; we, as FSFE, as currently involved in the patent > issue and other ones, and time is always too little. > > I write as FSFE member, after checking with other members, although we > don't have an official position about the firmware issue, yet. > > Andrea Glorioso originally wrote: > > My personal position is one of being a bit more pragmatic. A large > > part of the hardware we use actually has firmware embedded into it, > > the only difference being that we don't see it and we don't need to > > upload it > > Takashi Iwai summarized: > > 1. is the firmware binary is a program or a data? > > 2. can we force the h/w vendor to show the source code under GPL (if > > exists) in practice? > > 3. if not, shouldn't we change the license to the non-restrictive one? > > which license would be feasible? > > > > so far, alsa-firmware package is released from the understanding of 1 > > as "data". but if someone insists it as program, yes, it can be a > > problem. > > Andrea again: > > I might be wrong, but my guess is that if a piece of data is > > absolutely necessary for a GNU GPL program to work, then that data > > should be distributed together with the program at the same > > conditions of the GNU GPL (otherwise the GNU GPL itself could be > > very easily bypassed). > > Fernando Pablo Lopez-Lezcano: > > I tend to look at it (very conveniently, of course) as neither. I view > > it as part of the hardware device we're dealing with. Without it the > > device does not work. It is distributed as a separate file (inside the > > driver disk that actually comes with the device) because it is > > convenient for the manufacturer for updates, avoiding a flash rom in the > > device, and so on and so forth. > > > > Most probably very few people will agree with this viewpoint :-) > > Actually, I tend to agree with this view. But it's not easily supported > outside of programmers' circles, so I'd leave it alone. IMO, the only concern about saying "it's a part of hardware" is that you can redistribute the firmware while you cannot do the hardware. this is the basic difference between hardware and software. > In my opinion we should treat firmware as data as far as the driver is > concerned. That's similar to how emacs-lisp is data when loaded into OOo, > and my own software is just data for the routers that bring it to my > clients. [no example matches perfectly, they are exemplifications not > demonstrations] > > Actually, a number of my drivers include plain binary arrays in the > source files, and those arrays are just stored into register sets to > bring the device up in a known and default state. The binary firmware > is no different in the context of the GPL'd code. > > I don't buy the objection that "such binary blurb is software in > another context", since in the context of the GPL driver it is not. > Sure it is a work subject to copyright, but it is a different work; > saying that we need source to that in order to fulfill the GPL doesn't > look sensible to me [sure it would be _great_ to have that source, but > it's another issue altogether]. > > In my opinion, what is relevant as far as the GPL is concerned, is > that the author of such binary blurb allows it to be modified at will > in the form relevant to our free driver (i.e., data). I can change > such data, so the GPL is satisfied (and my hardware won't work any > more). It is the same with register default values: you can change > them if you want your hardware to not work, and you don't ask for > their source. The preferred form of modification for binary data is a > binary editor or a text editor over the hex representation, no problem > here. fully agreed. > This isn't a loophole of the GPL: if someone writes a GPL'd kernel > module that executes its own data, then _that_ module is not compliant > to its own license, since such data is actually code in disguise, and > is integral to the driver according to copyright law (they are one > work, acting as a driver). > > But with firmware, the GPL'd work is the driver, not the internals of > the hardware. So binary or hex is the preferred form of modification > for such data. What's important is being able to duplicate, study and > port the driver to other operating systems, not being able to study > the firmware to port it to other audio cards. yes, the execution of the given data is a key point. imagine that you give an example MIDI file to your application released under GPL. MIDI is a data, but it's also a kind of program, too -- it's the list of pattern sequences to drive the MIDI devices with the programmed timing. then, must the source of this MIDI file be provided as human readable? -- Takashi Iwai <tiwai(a)suse.de> ALSA Developer - www.alsa-project.org

20 years, 4 months

[linux-audio-dev] [ANN] FIL-plugins-0.0.1

by Fons Adriaensen

Hello all, The first release of FIL-plugins is now available at <http://users.skynet.be/solaris/linuxaudio> There's one plugin in this first release, a four-band parametric equaliser. Each section has an active/bypass switch, frequency, bandwidth and gain controls. There is also a global bypass switch and gain control. The 2nd order resonant filters are implemented using a Mitra-Regalia style lattice filter, which has the nice property of being stable even while parameter values are being changed. All switches and controls are internally smoothed, so they can be used 'live' whithout any clicks or zipper noises. This should make this plugin a good candidate for use in systems that allow automation of plugin control ports, such as Ardour, or for stage use. -- Fons

20 years, 4 months

[linux-audio-dev] LJ On-line article re: LAC2004

by Dave Phillips

Greetings: Linux Journal has published a brief review of the Karlsruhe conference: http://linuxjournal.com/article.php?sid=7577&mode=thread&order=0 Please make corrections and comments on the page itself (rather than writing to me). Best, dp

20 years, 4 months

Jump to page:

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