Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7534 discussions

[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

21 years

[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

21 years

[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 :)

21 years

[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

21 years

[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

21 years

[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 --

21 years

[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

21 years, 1 month

[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/

21 years, 1 month

[linux-audio-dev] Firewire Audio Card Support

by Olaf Christ

Hi, as the owner of a firewire audio card (Motu 828mkII) I was disappointed when trying to use it under linux. Asking Motu to provide tech docs and/or linux drivers is useless: "We will possibly release linux drivers in the future, but we never release any kind of technical documentation." Is there any effort to join forces for putting pressure on the manufacturers yet? I am willing to create an address list ordered by audio card manufacturer/model to make the manufacturers realize there is a need for linux support. Any comments? Olaf On Thursday 18 November 2004 14:01, derek holzer wrote: > Of course, the Firewire subsystem for Linux works fine. But AFAIK there > are no drivers existing for any firewire audio cards. Bug the various > manufacurers to release more technical info and they might eventually > show up. > > d. > > Victor LaLoggia wrote: > > Hello Frank; > > > > Thank you for your response, and I do not mean to be contrary, but what > > about the work the folks at http://www.linux1394.org/ are doing? > > > > I see that their subsystem has been included Linux kernel sources since > > version 2.3.40. Does the subsystem not work? > > > > Thanks, > > vic > > > > -----Original Message----- > > From: Frank Barknecht <fbar(a)footils.org> > > Sent: Nov 15, 2004 12:14 PM > > To: linux-audio-user(a)music.columbia.edu > > Subject: Re: [linux-audio-user] Using Linux Laptop for Live Performance > > > > Hallo, > > > > Victor LaLoggia hat gesagt: // Victor LaLoggia wrote: > >> I am just beginning my research into the available software and > >> hardware, and would greatly appreciate any information. Especially > >> on hardware - what would be the best usb/ firewire interface for > >> live performance? > > > > No Firewire audio yet on Linux. The best in your case is PCMCIA, which > > has the lowest latency. VX-Pocket or RME cards are good choices. Also > > try, if your internal soundcard is enough. > > > > Ciao

21 years, 1 month

[linux-audio-dev] problem latencytest: modprobe rtc: no such device

by Maarten de Boer

Hello, I decided to give kernel 2.6.10 a try, so I installed it in combination with Con Kolivas system system responsiveness patch. But when I try to run the latencytest (0.5.5), I run into the following problem: $ modprobe latency-test WARNING: Error inserting rtc (/lib/modules/2.6.10-ck2-ck2-pentium4/kernel/drivers/char/rtc.ko): No such device FATAL: Error inserting latency_test (/lib/modules/2.6.10-ck2-ck2-pentium4/misc/latency-test.ko): Unknown symbol in module, or unknown parameter (see dmesg) $ dmesg latency_test: Unknown symbol rtc_register latency_test: Unknown symbol rtc_unregister latency_test: Unknown symbol rtc_control Any suggestion? Maarten

21 years, 1 month

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

2003

2002

Linux-audio-dev