Linux-audio-dev January 2005

linux-audio-dev@lists.linuxaudio.org

89 participants
86 discussions

[linux-audio-dev] [ANNOUNCE] Xsynth-DSSI 0.9.0

by Sean Bolton

Announcing the latest release of Xsynth-DSSI, version 0.9.0. New features since the last general release include: * Anti-aliased, hard-sync-capable, minBLEP-based oscillators, including a new variable-slope triangle mode. (LADSPA versions of these oscillators are in the works.) * Velocity sensitive envelopes. * An additional filter mode: Fons Adriaensen's MVCLPF-3. * Much improved (but still plain-looking ;-) GUI, now using GTK+ 2.x. * Polyphonic … [View More]

20 years, 2 months

[linux-audio-dev] interesting read

by Lee Revell

So I decided to try reverse engineering a Windows driver yesterday, and came across this om Microsoft's site. It's a preliminary audio driver writer's guide for the Longhorn low latency audio system, they call it WaveRT. Anyway if it works like they claim, it implies the middle layer is quite powerful. It's a fascinating read. The really interesting stuff is in the Word document. http://www.microsoft.com/whdc/device/audio/wavertport.mspx http://download.microsoft.com/download/5/b/5/5b5bec17-ea71-4653-9539-204a67… Lee

20 years, 2 months

[linux-audio-dev] announce-list policy

by Kai Vehmanen

Hello everybody, when linux-audio-announce was created, it was agreed that announcements should be crossposted to all three lists. The reasoning was that this way people wouldn't have to subcsribe to LAA if they were already on LAD+LAU. Now when you look at LAA archives, some people post only to LAA, some (like me) to all three lists, and some to either LAA+LAD or LAA+LAU. My suggestion is that we drop this policy altogether: announcements should be sent to LAA and optionally to LAD and/or … [View More]

20 years, 2 months

[linux-audio-dev] Re: [linux-audio-user] KX Audio capabilities for Linux EMU10k1 [was Plans/Roadmaps for 2005?]

by Lee Revell

On Sat, 2005-01-08 at 10:17 +1100, Shayne O'Connor wrote: > Lee Revell wrote: > > >On Fri, 2005-01-07 at 15:40 +0100, Florian Schmidt wrote: > > > > > >>i'm writing this email, because i'm interested in what plans the > >>different linux audio developers have for the year 2005 Any new > >>revolutionary applications planned? Major changes to some of the > >>existing apps? So let us know. What are your roadmaps for 2005? What are > … [View More]>>you guys up to? > >> > >> > > > >I plan to get my patch adding multichannel support to the emu10k1 ALSA > >driver merged, then work on a real hwdep mixer app (probably by > >extending ld10k1/qlo10k1). As many of you know I'm a big fan of these > >cards, they are extremely cheap and (with good driver support) perfect > >for an entry level DAW, like a portastudio or something. Anyone who has > >used the kX drivers on Windows knows how much potential this device has, > >and unfortunately the Linux support is still a joke compared to the kX > >driver can do. But, that is all about to change, as the two crucial > >features (the DSP patch loader and "kX ASIO", aka the full duplex > >multichannel/low latency PCM device) now exist on Linux. > > > > oh my god, are you serious? i was using the kx drivers when i was on > windows, and i gotta say they were the best thing since sliced bread!!! > it turned my soundblaster live platinum into a BEAST of a music machine > (well, compared to what it was) ... > Heh, I still use them, all the time. I have to admit when it's time to make music I still use Windows. This is actually what got me interested in Linux audio, as soon as I realized how far ahead the kX project was, I quit my day job (was sick of it anyway) to work on this project. Now it's 6 months later, I'm a lot poorer, but it works dammit! > when i switched to linux, one of my biggest dissapointments was the > dismal support for the emu10k1 .... especially lack of multi-channel - > by multi-channel support, do you mean that you are able to use the rear > output channel independently of the front channel (at the moment my > front and rear channels are basically inextricably linked)? Yup. If you have the livedrive you can use all those jacks as independent ports. My Audigy2 ZS has something like 6 channels of analog in and 8 out, enough to record a band. And there's nothing like zero latency hardware DSP... I have to admit I still use Windows with the kX drivers when it's time to make music. It will be a great day when I can do the same with Linux. > that is > exactly what i've been trying to get happening for a while now, which i > need for dj mixing work (so's i can have an independent "preview" > channel for cueing music) .... > > the dsp configuration in kx audio was the killer ... are you saying > there is support NOW for use of this kind of feature in linux ...where > can i get the patch? > I actually got a lot more responses than I was expecting. I have been posting about this to the alsa lists for months, and no one but me and Peter Zubaj seemed to care. I think they didn't take me seriously at first, even when I posted the kX stuff, Linux users are conditioned to think these cards are junk. Windows people know better ;-) I will post the patch somethime this weekend. It would be great to have more people test it before I submit it to alsa-devel. In the meantime while I have been focused on multichannel Peter Zubaj has been working on the DSP part. Check it out: http://ld10k1.sf.net Screenshot of the DSP manager: http://ld10k1.sourceforge.net/screenshots/qlo10k1_20040706.png > this sounds very exciting to me! Thanks, hope it works for you. Lee [View Less]

20 years, 2 months

[linux-audio-dev] Modular Synth OSC API

by Dave Robillard

Hi all, As many of you know (hi #lad) I'm working on an OSC controlled modular synth called Om. I'm just finishing up subpatching and polyphony now, so things have hit the stage where the OSC "API" is important, and needs to be thought about and stabilized. What exists right now is just randomly added commands to get functionality working, so I won't even mention it here. Best to start from basics. I think I'll tacke it one issue at a time, and make a final RFC kinda proposal for people to … [View More]

20 years, 2 months

[linux-audio-dev] Re: [PATCH] [request for inclusion] Realtime LSM

by Jack O'Quin

[Adding linux-audio-dev to the CC list] Matt Mackall <mpm(a)selenic.com> writes: > On Wed, Jan 05, 2005 at 04:18:15AM +0000, Alan Cox wrote: >> gid hacks are not a good long term plan. >> >> Can we use capabilities, if not - why not and how do we fix it so >> we can do the job right. Do we need some more capability bits that >> are implicitly inherited and not touched by setuidness ? > > Why can't this be done with a simple SUID helper to promote … [View More]given > tasks to RT with sched_setschedule, doing essentially all the checks > this LSM is doing? The answer to your simple question is a long, sad story. :-( There is clearly no practical way to write large audio applications (many with elaborate graphical interfaces) securly enough to run them as root. So, we have used capabilities with linux-2.4 systems for several years. It was never a satisfactory solution, but was all we could do at the time. There is a small setuid program called `jackstart' that exec()s the JACK server (`jackd') with appropriate privileges so it can pass realtime privileges to its applications. Each client needs to create a realtime thread and mlock() its storage to do its part of the realtime audio cycle. Note that sched_setschedule() provides no way to handle the mlock() requirement, which cannot be done from another process. Clients may come and go at any time, so dropping the privilege after initialization is not an option. Unfortunately, all this heavyweight mechanism only helps with JACK and its many clients. Lots of other audio or video oriented applications also have realtime needs. The biggest problem was CAP_SETPCAP, which for good reasons[1] is disabled in distributed kernels. This forced every user to patch and build a custom kernel. Worse, it opened all our systems up to the problems reported by this sendmail security advisory. [1] http://www.securiteam.com/unixfocus/5KQ040A1RI.html While stumbling along with this very unsatisfactory state of affairs, many on the Linux Audio Developers mailing list were shocked[2] to hear about an LKML discussion[3] suggesting a significant lack of developer committment to addressing these issues... > Quoting Albert Cahalan[3]: "The authors of our code seem to have > given up and moved on. Nobody cleaned up the mess. Is it any wonder > the POSIX draft didn't ever make it beyond the draft state?" [2] http://www.music.columbia.edu/pipermail/linux-audio-dev/2003-November/00533… [3] http://www.kerneltraffic.org/kernel-traffic/kt20031101_239.html#3 So, all our work, frustration and user confusion while trying to "do the right thing" seemed doomed to failure. Since the Linux kernel developers continued to show little interest in our needs, we started a discussion about how to meet them ourselves[4]. [4] http://www.music.columbia.edu/pipermail/linux-audio-dev/2003-November/00534… Looking at our security requirements in a practical manner, we quickly concluded that CAP_SETPCAP is the work of the devil. A true filesystem-based privilege vector solution might be adequate, but is clearly beyond the scope of what we audio programmers could hope to accomplish. Even then, it would be difficult to administer. A simple group ID test is far more secure than CAP_SETPCAP, and perfectly adequate for us. When configuring a Digital Audio Workstation, one is not terribly concerned about local Denial of Service attacks or runaway realtime threads. That would be unacceptable for many other systems, but not ours. Yet, we want to avoid system integrity holes in network daemons like sendmail[1]. In other words: we can tolerate the bad guys crashing the system, but we don't want them turning it into an open spam relay or corrupting the filesystem. So, we needed to provide a simple way for an unskilled system admin (aka "musician") to configure a personal workstation to run realtime applications without opening egregious security holes. Equally important, it must be easy for other system admins to ensure that these privileges are *not* available on their server systems. It soon became apparent that the then-new LSM framework provided a good solution. Because LSM's can be built outside the kernel source tree, we were no longer forced to wait for some kernel developer to take an interest. The realtime-lsm is the solution we evolved. It has been actively used by thousands of Linux audio users for over a year now[5]. The first supported SourceForge release was in April of 2004[6]. It is now used by many popular audio-oriented distributions, including Planet CCRMA[7] from Stanford University and the Debian Music Distribution[8] from the AGNULA project. [5] http://www.music.columbia.edu/pipermail/linux-audio-dev/2003-December/00574… [6] http://eca.cx/laa/2004/04/0028.html [7] http://ccrma.stanford.edu/planetccrma/software/ [8] http://www.agnula.org/ I understand that kernel developers are busy and have other problems they consider more important than ours. But, you ought to at least understand that this is really important to us. We needed a clean solution two or three years ago. Now we finally have one. Distributing it with the kernel sources would be a great convenience for our users and would significantly simplify maintenance. It would also (IMHO) close a significant security and usability deficiency in the standard kernel. Any of the NSA and DoD experts will tell you: a security solution that is difficult to administer is not secure. It is no surprise that kernel developers should consider our solution technically inferior to their own ideas on the subject. I would have been delighted to have some kernel developer step in and provide a clean, well-thought out solution several years ago. This is a kernel deficiency, not an audio problem. I don't want to work on kernels. But, I am feeling quite discouraged that so many kernel developers still seem to consider this problem unimportant. I sense a distinct unwillingness to move forward on this issue. I really hope I am wrong about that. -- joq [View Less]

20 years, 2 months

[linux-audio-dev] Some input/feedback required

by Fons Adriaensen

Hello LAD, Best wishes for 2005 to all ! During the Xmas period I've been working on a small app called 'oscxyam'. It basically a 2-D control pad with OSC output. I wrote it to control sclang and scsynth, but it could be used to send continuous control parameters to any OSC controlled application. There are 4 'maps', each containing up to 12 'dots'. Moving a dot sends out a configurable OSC control message, normally containing the (transformed) X,Y coordinates of the dot. Transformations … [View More]

20 years, 2 months

[linux-audio-dev] Disappointing LA community ?

by Dubphil

Hello all, This post is not a flame, it is just a questionning about how works and thinks the Linux Audio Community... Later on LAU and LAD there was a big and nervous thread that was schematicaly talking about the lack of manufacturers wanted to collaborate with the Linux developpers in order to get their products working on our favorite OS. Recently I have succeeded in convicing a Manufacturer (Wave Idea) to consider the importance of giving Linux support to his products. I was really … [View More]

20 years, 2 months

[linux-audio-dev] Noise reduction with FFT

by Spencer Russell

I've got this really noisy audio file I'm trying to clean up, and I was thinking, it would be really cool if I could run a clip of the file that was just the noise(it's a recording of a discussion for a TV broadcast, so when no one's talking, it should be silent) and have the program output an average frequency content, in some sort of format that another program could take it as input and create a filter that would filter out those frequencies. It seems like brutefir would be able to do the … [View More]

20 years, 2 months

[linux-audio-dev] arts development discontinued...

by Joern Nettingsmeier

hi everyone! i just read dave's latest musings and stumbled upon stefan westerfeld's notice that he is no longer maintaining arts. many of you have probably already read about it. however, if you want to see a really graceful and stylish way of abandoning a project and changing one's mind, here are stefan's remarks: http://www.arts-project.org/doc/arts-maintenance.html even though arts will probably become obsolete in the near future, i think it should be pointed out that just like … [View More]

20 years, 2 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 January 2005