Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7501 discussions

[linux-audio-dev] Re: Plans/Roadmaps for 2005?

by Juhana Sadeharju

>From: Florian Schmidt > >what plans the different linux audio developers have for the year 2005? Great question! My list: -Freq/pitch spectrum display of highest quality -Pitch detection algorithm -Formant detection alg. -Pitch drawing (in Audacity, over waveform and freq spectrum displays) -Pitch curve editor (a spline curve approximating the pitch) -Cepstrum display to Audacity (a requested feature) -Audio comparison alg. (melody matching at audio signal level only, not MIDI) -Antti's Moog filter (see music-dsp list) -Parameter interpolation to my Theremin app (see gmpi and music-dsp on zipper noise) -Replace the sampled allophones with a formant tonegenerator in my Allo speech synth -Drum synth -Write GUI widgets for graphically manipulating filter parameters (see Waves, Izotope) These all are quite small projects, but we all could work together. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software

20 years, 5 months

[linux-audio-dev] [ANNOUNCE] hexter DSSI plugin 0.5.8

by Sean Bolton

A minor update of hexter, the Yamaha DX7 modeling DSSI plugin, is now available at: http://sourceforge.net/project/showfiles.php? group_id=104230&package_id=134428 Changes include: * Now uses GTK+ 2.x by default. GTK+ 1.2 and a minimal text- based UI are also available. * Added an output gain control, and corrected the MIDI controller 7 volume handling. * Several small bug fixes. More information about hexter and DSSI can be found at: http://dssi.sourceforge.net/hexter.html hexter is written by Sean Bolton, and copyright (c)2005 under the GNU General Public License, version 2 or later.

20 years, 5 months

[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 glide, tuning, and pitch bend range controls. * Updated patch set, and better documentation. Xsynth-DSSI 0.9.0 is available at: http://sourceforge.net/project/showfiles.php? group_id=104230&package_id=124101 About Xsynth-DSSI ================= Xsynth-DSSI is a classic-analog (VCOs-VCF-VCA) style software synthesizer which operates as a plugin for the Disposable Soft Synth Interface (DSSI). DSSI is a plugin API for software instruments (soft synths) with user interfaces, permitting them to be hosted in-process by Linux audio applications. More information on DSSI can be found at: http://dssi.sourceforge.net/ Xsynth-DSSI is written by Sean Bolton, and copyright (c)2004 under the GNU General Public License, version 2 or later. Xsynth-DSSI retains the basic synthesis model of Steve Brooke's Xsynth 1.0.2, while adding the following features: - operation as a DSSI plugin, - polyphonic operation, - band-limited oscillators, - a new, more stable filter mode, and - velocity-sensitive envelopes.

20 years, 5 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, 5 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 LAU. At least I've always had the nasty feeling that I'm spamming LAD+LAU with my Ecasound release announcements. Of course, when announcing conferences, major new versions (JACK-1.0.0 maybe? :)), etc, I see no harm in cross-posting to all the three lists. So in other words, if you really want to see _all_ the announcements, you should subcsribe to LAA. Any comments? If no objections, at least I will from now on send non-major release announcements only to LAA. -- http://www.eca.cx Audio software for Linux!

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

20 years, 5 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 comment on. The reason it's important is that I intend for Om to be useful from scripting languages for algorithmic composition / soundmangling / experimentation / etc - not just one 'official' client. So the API needs to be clean and clear as possible, since real people are going to be dealing with it directly. So. First issue, "command" versus "object" namespace. Right now the API is like so (roughly): /patch/connect patch1 osc1 out lpfilt in /patch/set_control foopatch osc1 freq 440.0 etc. The reason for this is simple: liblo didn't have pattern matching support when I wrote it. I think it would be clearer to have paths for the node/patch names rather than as parameters, ie /patches/patch1/nodes/osc/set_control freq 440.0 Another minor thing would be to possibly distinguish commands from object by the use of a # symbol, as in http://www.opensoundcontrol.org/papers/query_system/ making: /patches/patch1/nodes/osc/#set_control freq 440.0 /patches/patch1/#add_node foo bar baz I don't think anyone would really disagree this is cleaner than the command-based version but I have one concern: performance. I don't know if the pattern matching in liblo would have a significant enough overhead to introduce any latency. These commands are used to control everything in realtime, so latency absolutely must be as low as possible. (Steve?) Comments? (There will be more issues to come, assuming anyone cares) -DR-

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

20 years, 5 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 include linear, exponential and polar. For example, to set SC3's control busses 4 and 5 you would use: /c_set ,ifif 4 X 5 Y You'll find a link to a screenshot on the usual place: <http://users.skynet.be/solaris/linuxaudio> There are currently three ways to move a dot (linked to mouse buttons 1,2,3 but that could change): 1. A message is sent for each X11 motion event. 2. A message is sent only when the dot is released. 3. No messages are sent, when the dot is released it starts flashing. A click on the "Trig" buttong then sends the update messages for all such dots at the same time. Now before I release this, I'd appreciate some inputs on other potential 'modes', and how these should be controlled, and also suggestions for additional features. For example the message could include the mouse button used, or shift states etc. There are endless possibilities, but I want to include only those that potential users find useful, rather than just nice but confusing. -- Fons

20 years, 5 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 convince myself that this initiative will be encouraged by the Linux Audio community. That's why I have posted an help request to make Wave Idea products fully Linux compliant. I felt very disappointed when I saw my request stands quiet. Perhaps there is something basic I don't understand about the Linux Audio Community as I have register to the list only few months ago. Tell me what is wrong with my post and how I could improve communication with all LA fellows Kind Regards PS: perhaps because I'm french and my english is poor :)

20 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