Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

[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, 10 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, 10 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, 10 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, 10 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, 10 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 latter part, but is there a way to automatically generate the filter definition from the frequency content of a file? Is this a feasable method of noise reduction? If it seems like it could work, but there isn't a program to do it, I would be interested in writing it, if anyone has any input. Thanks! -spencer

20 years, 10 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 the often-bashed open sound system it has been a crucial step in bringing linux audio to the mainstream, and the community owes much to stefan in that respect (not to mention his many contributions to ladspa and other projects). at a time when there was hardly anything else than esound, stefan tackled the job of giving desktop users what they want: multiple source playback and an elegant user interface. even though arts turned out not to be feasible for high-end applications (a fact that stefan now acknowledges, contrary to his former "mission" ;), it has certainly increased the momentum behind linux audio a great deal. kudos, stefan. best, jörn

20 years, 10 months

[linux-audio-dev] [ANN] Ceres V0.42 and Mammut V0.18

by Kjetil Svalastog Matheussen

http://www.notam02.no/arkiv/src/ CERES ***** "Ceres is a simple program for displaying sonograms and for sound effects in the frequency domain." Except that its not that simple anymore... 0.41 -> 0.42 ------------- -Actually apply the fix for the (horrible) bug that caused ceres to crash on newer linux distributions. (Sorry!) MAMMUT ****** Mammut will FFT your sound in one single gigantic analysis (no windows). These spectral data, where the development in time is incorporated in mysterious ways, may then be transformed by different algorithms prior to resynthesis. An interesting aspect of Mammut is its completely non-intuitive sound transformation approach. 0.17 -> 0.18 ------------ -Fixed a (horrible) bug that caused mammut to crash on newer linux distributions. -Simplified the install process a lot. pygtk1, libglade and sndlib is now included in the distribution and is/can be installed automatically if needed. -Added undo for load&multiply --

20 years, 10 months

[linux-audio-dev] ardour 0.9beta23 released

by Paul Davis

Well, its time for another release of Ardour. This release is another milestone: it marks the end of all bugs that were slated to be solved before the 1.0 release. The plan from here is to wait for about a few days to allow testing of this release and minor (cosmetic) bug fixing to continue, and then ardour 0.99 will be released. After that, release engineering (install process, new user experience) will be all that stands between us and release 1.0rc1, which will hopefully be the last release before 1.0. Please note: there is no claim that Ardour is bug free. The bug list for 1.0 was drawn up with the goal of making sure that the vast majority of new (and existing) users of Ardour will have a rewarding, powerful and largely problem-free experience recording, mixing and producing music. There are still substantive (as well as trivial) issues that require solutions, but the development team is anxious to move on to the GTK2 port so that we can make Ardour look as shiny (shinier?) as Rosegarden :) This is an important release for people who work in locales that do not use the period (".") as a decimal separator (i.e. decimals written as "1,5" rather than "1.5"). It is the first version that we believe is now truly locale-safe against data corruption caused by LC_NUMERIC's affect on stored data formats. Enjoy, there's more to come :) --p * fix a truly appalling coding error in all uses of LocaleGuard - people who run ardour with LC_NUMERIC set to something other than en_US.UTF-8 will probably have continued to suffer from locale-based problems because of this problem. * fix nesting of LocaleGuard objects to provide yet more fixes to LC_NUMERIC problems * add new flag for custom canvas items that do not require an automated redraw when arguments are set. * rework canvas "simple rect" item to optimize redraws as resizes occur, and use FAST_PAINT_BOX to speed up drawing slightly. it is possible (likely?) that this will help some system performance issues when recording multiple tracks at once. * rationalize how the "s" (split) operation works. - if the mouse pointer is inside a regionview, that region is split - if the region was part of the selection, then a) all regions covering the mouse pointer time position are also split b) the selection is cleared after the split - if the region was not part of the selection, then the selection is left unchanged after the split * if auto-connect inputs is in use, only connect the first N inputs where N is the number of physical inputs found by JACK * fix grotesque error in use of STL reverse iterators that messed up any use of AutomationList::truncate_end(), causing horrible corruption of the control points. * fix long-standing problems with region gain line visibility (as-is, plus after-trimming) * reimplement Route::_reset_plugin_counts() to use a slightly simpler algorithm and allow zero-input plugins ("instruments") as the first in the chain * fix problem with metering when using zero-input plugins * fix problems with failed remove of redirects * make region editor clocks insensitive at the right times * store relative names in session file for connections, allowing re-establishing internal connections when connected to JACK using a different client name * fix major thinko bug with Curve::spline_eval() that caused a complete failure if the Curve had 0, 1 or 2 control points. * Karsten's fixes for crossfades, plus a modified version of his TimeAxisViewItem "selected" fix. * automation track "controls context menu" now includes "clear" and auto-state submenus, so that full control even using a small track height is possible. * require inserts/plugins to either be mono-input or match the active streams at that point in the route. this means you cannot insert a 2in plugin on a mono track without a 1in/2out splitter preceding it. we will change this in a future (post-2.0) version of ardour so that the splitter is added automatically in a hidden way. * fix naming of sends/inserts to avoid duplications. * removed redundant expansion arrow from TimeAxisView * when a region overlaps another region but is wholly within the other, create hidden, immutable 64-frame xfades at both boundaries. (works, but some more work needed on corner cases and thoroughly testing normal overlap xfades) * fix off-by-1 errors in drawing canvas rect objects (affects rubber band selection, range selection and more) * corrected off-by-1 error in position of fade out polygon within regionviews * expanded height of per-track selection rects to full track height * muted regions never write silence, whether they are opaque or not. * added "Mute" and "Unmute" to region ops menu * fix bug in Editor::cursor_to_selection_{start,end} that prevented the function from working in range mode * delete AudioEngine at exit (and thus call jack_client_close()) * make "active" check menu item on mixer strip "name" context menu be in correct state at startup * popup error message if clone or copy of redirects fails * prepend "!" to the displayed name of a muted region * newly created regionviews follow the current "show waveforms" setting * relevant internal-overlap xfades are invalidated by layering changes * all (relevant) xfades are invalidated by muting changes * another almost-complete reimplementation of plugin count handling - no visible changes intended - we now compute counts before changing the counts - if the configuration is impossible, things are left unchanged - if the configuration is possible, we set the counts - all failed reset_plugin_count() calls should leave the redirect lists in their original state * reimplement region layer changes to avoid visible "illegal" state with two regions in the same layer * fix bug with soloing that would cause solo states of tracks|busses in the incorrect state if busses|tracks were also soloed while a track|bus was un-soloed. * make "active" check menu item in track controls context menu be in correct state at startup * use nick mainsbridge's brilliantly simple "later regions are on higher layers" idea * remove all explicit control over layering from ardour/gtk * fix nasty thread/race condition bug when building peakfiles for imported/embedded audio. two threads could be reading from the same file at the same time, and under some circumstances could stomp on each others activities. * fix potential (suspected) race condition associated with peakfile request submission and handling. may affect some reported "hangs" when importing/embedding audio. * actually use two-stage regionview creation (rects first, waveforms later) by refactoring SndFileSource's use of its primary mutex. makes regionviews * fix attempt to access an illegal column of the file selector in the library/file browser. * add pthread id to "posix signal received" message * require use of --new/-N flag to create new sessions from the command line * remove "exiting foo thread" and "stopping bar thread" messages * from shutdown, don't kill the GUI thread if its not running * add EnvelopeChanged Change to AudioRegion, playlist saves state when this or *any* region change occurs. this fixes a class of bugs where undo after a region was removed fails to fully restore the region's state. * remove debug output from Gtkmmext::NewSaveDialog

20 years, 10 months

[linux-audio-dev] LAC200_4_: Proceedings finally available!

by Frank Neumann

Hi all, this comes somewhat late, but we are still happy to finally have the proceedings of the last Linux Audio Conference (April 2004) online. Short after the conference, we asked the speakers to send papers about their talks so we could put together these proceedings. Well, collecting those papers _after_ a conference was probably not such a good idea :-), but we still got a fine small collection of 6 papers which we have then put together into one PDF, together with a list of the all people who helped in making the conference possible (sorry to anyone we might have forgotten). Get it while it's still warm: http://on1.zkm.de/zkm/stories/storyReader$4477 A lot of thanks go out to those who wrote and submitted these papers! Greetings, The LAC organization team: Götz Dipper Matthias Nagorni Frank Neumann PS: On a sidenote, the OGG files of the presentations which were unavailable for several weeks are now back online again: http://www.linuxdj.com/audio/lad/contrib/zkm_meeting_2004/

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