Linux-audio-dev December 2003

linux-audio-dev@lists.linuxaudio.org

67 participants
59 discussions

[linux-audio-dev] deconvolver for IR creation anyone?

by Uwe Koloska

Hello, I am looking for a deconvolver, that is able to produce impulse responses from sinus sweeps (and especially the exponentially sweeping sine wave introduced by Farina). Do you have any suggestions or at least tips to start an implementation by myself? Recently I managed to use the mls tools from nwfiir to produce an IR of my microverb. I had to learn the hard way, that simple soundcards are not able to be used as MLS source because of the non linearities. Even a simple DA-AD loop gives a result wave that mls2imp cannot cope with. But an empty loop with an US-122 (unfortunately not with linux for now) gives something very near to a dirac impulse! The hunt for the linux convolution reverb has started ;-) Uwe -- voiceINTERconnect www.voiceinterconnect.de ... smart speech applications from germany

20 years, 8 months

[linux-audio-dev] [Fwd: Re: [linux-audio-user] Sounds Expo in the UK]

by Patrick Shirkey

Daniel asked for this to be forwarded... -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ========================================

20 years, 9 months

[linux-audio-dev] {draft} setgid problems with GTK for realtime audio (long)

by Jack O'Quin

{This is a draft of a note for the GTK developers, requesting them to soften their position on disallowing setgid. Please post comments and suggestions. It carries more weight coming from a group of us. Also, please tell me where this is should go.} {The note seems overly long. Suggestions for things to leave out? Perhaps I should post some of this on the web as a white paper, and send them a much shorter message pointing to it.} Rationale ========= A number of us in the Linux Audio Developers community[1] are trying to come up with practical ways of dealing with the security exposures inherent in realtime audio. Our problem is that many audio applications require realtime scheduling and memory locking privileges to achieve stable, low-latency performance. While not a direct threat to system integrity, these privileges easily allow anyone with a local login to accidentally or intentionally freeze the machine. In security jargon, this is known as "Denial of Service". For a dedicated Digital Audio Workstation system, the risk is generally acceptable. But, we want to do our best to minimize its effects. Historically, many Linux audio applications required users to login as root when needing realtime privileges. Large audio programs often include complex graphical user interfaces, digital signal processing, and multi-threaded buffer handling. Running all this as root leaves the system wide open to devastating security attacks. This is what we want to avoid. Solutions Considered ==================== Some packages, like the JACK Audio Connection Kit[2], have successfully used Linux kernel capabilities[3] to run realtime audio applications using an ordinary user ID with only the necessary permissions delegated. Unfortunately, the Linux kernel developers do not fully support this, because that mechanism currently has known security holes[4]. Consequently, kernels are shipped with it partly disabled. The 2.4 kernel requires users to make a two-line patch, then recompile and reinstall to enable this feature. As these problems are not likely to be resolved any time soon, we have been investigating other solutions. The 2.6 kernels provide a new Linux Security Module (LSM) mechanism[5]. With that, we can turn on capabilities without forcing all our users to patch their kernels. But, the security exposure in the capabilities mechanism remains. So, we are working on an experimental LSM for 2.6 that grants realtime privileges to applications based on several optional criteria[6]. The most secure option only grants realtime access to programs or users belonging to a specific group ID, such as `realtime' or `audio'. Ideally, our applications would be setgid to that group, so only realtime programs would gain access to these privileges. Problems with GTK ================= Unfortunately, audio applications using GTK cannot take full advantage of this option, because GTK refuses to run setgid. The unintended consequence of that policy is to *increase* our security exposure by forcing us to grant realtime privileges to all the programs of users who need them, when we would prefer to restrict access to just the audio programs, themselves. We have read with interest the rationale[7] given by Owen Taylor of the GTK development team for disallowing the use of setuid and setgid in GTK applications. Owen writes: In the opinion of the GTK+ team, the only correct way to write a setuid program with a graphical user interface is to have a setuid backend that communicates with the non-setuid graphical user interface via a mechanism such as a pipe and that considers the input it receives to be untrusted. This is a fine suggestion, and certainly one viable approach. But, it seems presumptuous to claim that it is the "only correct way". One cannot force the many existing Linux audio applications to be rewritten to follow this advice, and it is unclear that there is any good reason to do so. Since GUI threads generally use non-privileged scheduling, in practice realtime priority is restricted to the I/O and signal processing threads anyway. Requested Change ================ While sympathetic with the concerns and intentions expressed in Owen's document, we are not happy with the actual implementation. We want gtk_init() to stop checking that the group ID equals the effective group ID. If you really feel that some such test is necessary, then please disallow operation only when the effective gid is zero (`root' or `wheel' in most systems). Note that testing for specific user and group privileges does not conform to current POSIX thinking on the subject. The standard has adopted the term "appropriate privileges"[8] for describing the effects of the implementation-defined security mechanism. This was done to encourage adoption of more granular privilege implementations than the traditional monolithic Unix superuser approach. So, no matter what tests you make, on some modern systems you will not be able to detect when GTK is running in a privileged context. System security is evolving in directions that are outside the scope of GTK and cannot adequately be enforced by any user-level library. Despite good intentions, incomplete security checking tends only to make matters worse. Regards, -- Jack O'Quin Austin, Texas [1] mailto:linux-audio-dev@music.columbia.edu [2] http://jackit.sourceforge.net [3] http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq… [4] http://archives.neohapsis.com/archives/sendmail/2000-q2/0002.html [5] http://lsm.immunix.org [6] http://www.joq.us/realtime/README [7] http://www.gtk.org/setuid.html [8] http://www.opengroup.org/onlinepubs/007904975/xrat/xbd_chap03.html

20 years, 9 months

[linux-audio-dev] Linux Audio Developers's Conference #2: Call For Music

by Frank Neumann

Hi all, the following announcement gets sent to all of linux-audio-dev, linux-audio-user and linux-audio-announce mailing lists in order to reach as many interested parties as possible; I'm sorry if you receive this twice or even more often. I would be glad if we get a lot of participation from your side! Frank ----------------------------------------------------------------------- >From April 29th to May 2nd, 2004, the Institute for Music and Acoustics of ZKM Karlsruhe, Germany, will host the 2nd conference of the Linux Audio Developers (LAD). As a new feature there will be presentations of music in addition to technical talks. For this, we are looking for music that has been produced completely or mostly under Linux. We are looking for: * Interesting demos of sound synthesis, sound processing, etc. * "Classical" computer music compositions, to be played in a concert setting * Pieces from areas such as Electronica, Chill-Out, Ambient etc. If you would like to participate, please send your composition(s) to this address: Linux Sound Night ZKM, Institut fuer Musik und Akustik Lorenzstr. 19 D-76135 Karlsruhe Germany Please make use of one of the following media formats: - Audio-CD, DVD or CD-ROM Possible audio file formats: aiff or wav; mono, stereo or multi-channel; 44.1 or 48 kHz; 16 or 24 bit resolution. Please include the following items with your submission (in English): * A short commentary on the compositions * A short Curriculum Vitae * A completed and signed printout of the form available here: http://www.zkm.de/lad Deadline for submissions is February 29th, 2004. A jury will select the compositions that will be performed/played. The jury will award 3 grants to participants to contribute to their travel expenses. Terms and conditions for participation can be found in the form above. Up-to-date information about the conference is available here: http://www.zkm.de/lad -- Frank Neumann (Frank.Neumann(a)st.com), VIONA Development Center STMicroelectronics, Karlstraße 27, 76133 Karlsruhe

20 years, 9 months

[linux-audio-dev] reminder about Ecasound Control Interface

by Kai Vehmanen

Hello, for those new to the API, Ecasound Control Interface (ECI) is a _simple_ API for controlling the Ecasound engine. It certainly is not, and is not meant to be, a general purpose API, but it suits nicely to many small-to-medium-size tasks. General info about ECI can be found at: http://www.eca.cx/eci I'm writing this because the recently released Ecasound-2.3.2 added support for Ruby (contributed by Jan Weil). Prior versions already provided support for C, C++, elisp, Perl, PHP and Python. So quite a few in other words. :) Another thing to remember is that ECI apps can interact with JACK (including full transport support!), use LADSPA plugins for effect processing, and perform native ALSA audio i/o. Second reason I'm writing this now is that I just wrote a small app to monitor JACK transport position (very much like jack_showtime that comes with JACK), and it turned out to be an easy thing to do: --cut-- #!/usr/bin/env python from pyeca import * from time import sleep e = ECA_CONTROL_INTERFACE() e.command("cs-add jackmon") e.command("c-add jacmon") e.command("ai-add jack") e.command("ao-add null") e.command("cs-connect") e.command("start") while e.last_type() != 'e': e.command("get-position") curpos = e.last_float() if e.last_type() == 'e': break sys.stderr.write('JACK system pos %6.2f secs\r' % e.last_float()) sleep(0.2) --cut-- Converting the above to your favorite language is left as an exercise. :) PS If you replace 's/null/jack/' and add the line 'e.command("cop-add -el:djFlanger,0,5,0.5,50")' ... you've turned the script into a small JACK-Rack style app that uses Steve's DjFlanger LADSPA plugin. -- http://www.eca.cx Audio software for Linux!

20 years, 9 months

[linux-audio-dev] Linux Security Module for realtime audio

by Jack O'Quin

I've been experimenting with Torben's LSM for the 2.6 kernel, and the realtime group permissions mechanism we discussed. Naturally, there are some problems. The worst is that GTK-2 will not tolerate the use of setgid... (process:11284): Gtk-WARNING **: This process is currently running setuid or setgid. This is not a supported use of GTK+. You must create a helper program instead. For further details, see: http://www.gtk.org/setuid.html Refusing to initialize GTK+. This seems to totally invalidate the setgid approach we had discussed, at least for audio applications using GTK. QT does not seem to complain about setgid, though most of the reasons for avoiding it with GTK surely apply there as well. So, I modified Torben's LSM to check supplementary groups, and this seems to work fine. From a system admin perspective it's pretty good. I'm a member of group `audio', which was accomplished by adding my user ID (joq) to the appropriate entry in /etc/group... audio:x:29:joq Then, I loaded the LSM like this... $ sudo modprobe jackcapabilities rtgid=29 After that, all my processes have realtime privileges. I can run JACK under my normal user ID... $ jackd --realtime -d alsa I had to make a small change to JACK for this to work, so you'll need CVS sources to try it. Note that `jackstart' was not needed. Then, when I start various JACK applications they automatically acquire realtime privileges, too... $ alsaplayer -o jack & $ ardour & $ jamin & For reasons I cannot explain, this works without requiring the CAP_SYS_RESOURCE capability, a welcome but unexpected bonus. I would appreciate comments, feedback, and bug reports. If you want to try it, don't forget that it has received minimal testing. Neither I nor anyone else can promise that it will not adversely affect your system security or stability. Caveat emptor! -- joq

20 years, 9 months

[linux-audio-dev] bandwidth limited waveform generators?

by Maarten de Boer

hello, i remember that some time ago there was some discussion about bandwidth limited waveform generators. my question is: did anybody compare the various implementations, and does anybody have an idea what would be the fastest? (square, saw) maarten

20 years, 9 months

[linux-audio-dev] Sharing Music

by Hans Fugal

As in, how do I share my own? What licenses or other scheme do you all use for music that you create and would like to be widely distributed, with or without any other restrictions. What considerations do you take into account? disclaimer: I don't have any cool music to release (yet), although I have a few almost-cool works for the extremely curious... -- Hans Fugal | De gustibus non disputandum est. http://hans.fugal.net/ | Debian, vim, mutt, ruby, text, gpg http://gdmxml.fugal.net/ | WindowMaker, gaim, UTF-8, RISC, JS Bach --------------------------------------------------------------------- GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460

20 years, 9 months

[linux-audio-dev] alsa 1.0.0 API changes???

by Maarten de Boer

Hello, I have been unsubscribed from alsa-devel for a while, so maybe i missed the discussion about this, but a quick look at the archives did not reveal anything. I just downloaded alsa 1.0.0rc2, and discovered that the API changed. For example (and this is only an example), take the function snd_pcm_hw_params_set_rate_near. Before, the 3th argument was the samplerate requested, and the return value was the error value (<0) or the samplerate obtained. err = snd_pcm_hw_params_set_rate_near(handle, params, rate, 0); Now, the third argument is a _pointer_, used to pass the requested value _and_ to return the obtained samplerate. Note that the symbol is identical, and that an application compiled against the old version will happily link against the new version (but surely fail when executing!) (or am I missing something here??) I clearly see the advantage of the new, cleaner, approach, but I still remember the past ALSA API changes, and I was under the impression that that would not happen again. I also thought that the 0.9.x releases were a straight line to work towards the 1.0 release. So I am very surprised to see this happen. If this has been discussed / announced somewhere, than I am sorry for having missed it, but in any case, I think it might be good to place a notice on the alsa web page. Maarten

20 years, 9 months

[linux-audio-dev] realtime LSM 0.0.2

by Jack O'Quin

Here is the realtime LSM version 0.0.2, for use with 2.6 kernels. -- New features - mlock parameter enables memory locking privileges - allcaps parameter enables all capabilities, including CAP_SETPCAP - restores cap-bound on exit -- Makefile improvements - use security/commoncap.c from the kernel sources - make dist -- Documentation - README explains options - INSTALL instructions - COPYING file for GPL -- joq

20 years, 9 months

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 December 2003