Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7534 discussions

[linux-audio-dev] Digital Room Correction (DRC) 2.3.1

by Denis Sbragion

Hello, DRC 2.3.1 has been released. Changes: Some minor corrections to the program have been performed and the documentation has been restructured. A new option to automatically count the number of lines in the target function and microphone compensation files has been added. A new optimized sample configuration file has been added. For details see: http://freshmeat.net/projects/drc/ Regards, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it

22 years, 1 month

[linux-audio-dev] [ANN] AlsaModularSynth-1.7.1

by Matthias Nagorni

Hello, together with the latest release of MCP/REV/VCO-Plugins by Fons Adriaensen, AlsaModularSynth-1.7.1 can be considered as a major step forward in realistic virtual analogue modular synthesis. There are some new sound examples (.ogg) on alsamodular.sourceforge.net that give an impression of this. For a detailed list of what is new, check out the "News" section on the project page. Have fun ! Matthias -- Dr. Matthias Nagorni SuSE Linux AG Maxfeldstr. 5 phone: +49 911 74053375 D - 90409 Nuernberg fax : +49 911 74053483

22 years, 1 month

[linux-audio-dev] Beatboxing rsynth-2.0

by will＠malefactor.org

I modified rsynth-2.0 to make it able to beatbox. It's very cool, especially since rsynth is so small and easy to set up. You can get the (very small) patch at http://malefactor.org/rsynth-bbox.tar.gz An MP3 demo is up at http://malefactor.org/bbox.mp3

22 years, 1 month

[linux-audio-dev] resend: more about sync (was: rosegarden/ardour, ardour/adat, etc.)

by Aaron Trumm

Hi all. I've been trolling and testing various sync methods and I've noticed some questions popping up. Is it just me or is the linux audio situation a bit incomplete at this point with regard to information on that subject? It may just be that most of the programs are still struggling to develope sync techniques (MTC, MMC, ADAT sync, SMPTE, jack transport, etc. etc.), but also is there a relative lack of info/tutorials/etc? The reason I ask, is because not only for my sake, but for the sake of the community, I'd sure be glad to try and make a dent in that, maybe document some toots, or whatnot. of course, this all has to be in sync (no pun intended ;) ) with the development of the capabilities... I wish I had time to sort of type out something more detailed - I'll get to that sometime here (running short on time right this minute :) ) one basic hole I see at least in my understanding, is what the HECK is jack_transport, how does it fit in, etc.? that's ONE - there are lots of holes for me *laugh* another curious one is ecasound? it's the veteren around here in a lot of ways - does it sync to anything? ok well I'll wait for thoughts and then as soon as I can get a chance, I'll write something longer and sort of put out to y'all what I've found out, and see what holes can be filled - cheers (sorry for any unclarity in this email, unclarity is why I'm starting this thread! :) ) - Aaron www.nquit.com

22 years, 1 month

[linux-audio-dev] cdparanoia fails / audiofile comparer

by Juhana Sadeharju

Hello. Anyone would like to develop cdparanoia further? I ripped a CD two times with the following results: (== PROGRESS == [ !-------| 159332 00 ] == :^D * ==) (== PROGRESS == [ + + + | 159332 00 ] == :^D * ==) The errors are explaned this way: - Jitter correction required + Unreported loss of streaming/other error in read ! Errors are getting through stage 1 but corrected in stage2 Which error is more severe: "+" or "!"? Is "+" corrected properly? The problem is that the channels of other ripping are swapped at the point where "!" is located (but "!" may not have caused it). I don't know which one of the rippings is incorrect (they both could be incorrect). The channels also have one sample offset after the swap. The second ripping has "+" before the "!" point, but both rippings are indentical up to the "!" point. Would that mean that "+" is a harmless error and that thus the second ripping is correct? And that we should rewrite only the algorithm handling the "!" errors? In addition to rewriting "!" handling (or "+" handling if that caused the channel swap), I would like get out a printed list of errors. The error list could then be used in an audio editor for marking the errors with red color (say). Also an audiofile comparer program would be great to have: a program which finds matching regions. Now it was easy to compare the regions up to the "!" point with md5sum program, but it was difficult to compare the end part due misaligning. I compared them visually at a few random points. In such a comparer program each matching sample would match bitwise for this application, but they could match with an error tolerance if the application is to compare an original audio and an edited audio which is affected by dither noise (say). So, such a comparer would reveal what edits were done in an audio editor -- I have needed such a program a few times earlier. Regards, Juhana

22 years, 1 month

[linux-audio-dev] Pixmap slider tutorial?

by Adam King

Hi All, I'm still new to LAD so sorry if this has been asked before - is there anywhere online that has an introductory tutorial to creating custom pixmap sliders? I'm looking for a tutorial similar to the gtk dial tutorial on the gtk.org site. If anyone has a link or info I'd appreciate it. Cheers, Adam

22 years, 1 month

[linux-audio-dev] SB Live IR remote control codes

by Juhana Sadeharju

Hello. Below are control codes for the SB Live IR remote control. The remote could be used in music players, in Audacity, in Ardour, and any other software. We should have a standard format for an info file which tells the regions in audiofiles. Such info file (if exists) would tell where to jump when I press "1" or "next" in the remote. Regards, Juhana == cut == SB Live remote control codes ---------------------------- as given by "amidi -d -p hw:0,0" // Without "speaker" button hold down. F0 00 20 21 60 00 01 0A 41 44 51 2E F7 // 1 Number group F0 00 20 21 60 00 01 0A 41 44 71 0E F7 // 2 F0 00 20 21 60 00 01 09 41 44 09 76 F7 // 3 F0 00 20 21 60 00 01 09 41 44 51 2E F7 // 4 F0 00 20 21 60 00 01 09 41 44 21 5E F7 // 5 F0 00 20 21 60 00 01 09 41 44 1E 61 F7 // 6 F0 00 20 21 60 00 01 0A 41 44 11 6E F7 // 7 F0 00 20 21 60 00 01 0A 41 44 41 3E F7 // 8 F0 00 20 21 60 00 01 0A 41 44 6E 11 F7 // 9 F0 00 20 21 60 00 01 09 41 44 01 7E F7 // 0 F0 00 20 21 60 00 01 0A 41 44 21 5E F7 // stop Transport group F0 00 20 21 60 00 01 0A 41 44 1E 61 F7 // play/pause (>/||) F0 00 20 21 60 00 01 0A 41 44 3E 41 F7 // (|>) + slow F0 00 20 21 60 00 01 0A 41 44 7E 01 F7 // (|<) + previous F0 00 20 21 60 00 01 09 41 44 5E 21 F7 // (>|) + next F0 00 20 21 60 00 01 09 41 44 7E 01 F7 // (||>) + step F0 00 20 21 60 00 01 09 41 44 76 09 F7 // mute Amplifier group F0 00 20 21 60 00 01 0A 41 44 46 39 F7 // vol - F0 00 20 21 60 00 01 09 41 44 46 39 F7 // vol + F0 00 20 21 60 00 01 09 41 44 31 4E F7 // eax Menu group F0 00 20 21 60 00 01 09 41 44 41 3E F7 // options F0 00 20 21 60 00 01 09 41 44 6E 11 F7 // display F0 00 20 21 60 00 01 09 41 44 71 0E F7 // return F0 00 20 21 60 00 01 09 41 44 11 6E F7 // start F0 00 20 21 60 00 01 09 41 44 3E 41 F7 // close + cancel F0 00 20 21 60 00 01 0A 41 44 61 1E F7 // left (<<) Browse group F0 00 20 21 60 00 01 0A 41 44 2E 51 F7 // right (>>) F0 00 20 21 60 00 01 0A 41 44 5E 21 F7 // up F0 00 20 21 60 00 01 0A 41 44 31 4E F7 // down F0 00 20 21 60 00 01 0A 41 44 01 7E F7 // select/ok // With "speaker" button hold down. F0 00 20 21 60 00 01 0A 41 44 50 2F F7 // 1 Number group F0 00 20 21 60 00 01 0A 41 44 70 0F F7 // 2 F0 00 20 21 60 00 01 09 41 44 08 77 F7 // 3 F0 00 20 21 60 00 01 09 41 44 50 2F F7 // 4 F0 00 20 21 60 00 01 09 41 44 20 5F F7 // 5 F0 00 20 21 60 00 01 09 41 44 1F 60 F7 // 6 F0 00 20 21 60 00 01 0A 41 44 10 6F F7 // 7 F0 00 20 21 60 00 01 0A 41 44 40 3F F7 // 8 F0 00 20 21 60 00 01 0A 41 44 6F 10 F7 // 9 F0 00 20 21 60 00 01 09 41 44 00 7F F7 // 0 F0 00 20 21 60 00 01 0A 41 44 20 5F F7 // stop Transport group F0 00 20 21 60 00 01 0A 41 44 1F 60 F7 // play/pause (>/||) F0 00 20 21 60 00 01 0A 41 44 3F 40 F7 // (|>) + slow F0 00 20 21 60 00 01 0A 41 44 7F 00 F7 // (|<) + previous F0 00 20 21 60 00 01 09 41 44 5F 20 F7 // (>|) + next F0 00 20 21 60 00 01 09 41 44 7F 00 F7 // (||>) + step F0 00 20 21 60 00 01 09 41 44 77 08 F7 // mute Amplifier group F0 00 20 21 60 00 01 0A 41 44 47 38 F7 // vol - F0 00 20 21 60 00 01 09 41 44 47 38 F7 // vol + F0 00 20 21 60 00 01 09 41 44 30 4F F7 // eax Menu group F0 00 20 21 60 00 01 09 41 44 40 3F F7 // options F0 00 20 21 60 00 01 09 41 44 6F 10 F7 // display F0 00 20 21 60 00 01 09 41 44 70 0F F7 // return F0 00 20 21 60 00 01 09 41 44 10 6F F7 // start F0 00 20 21 60 00 01 09 41 44 3F 40 F7 // close + cancel F0 00 20 21 60 00 01 0A 41 44 60 1F F7 // left (<<) Browse group F0 00 20 21 60 00 01 0A 41 44 2F 50 F7 // right (>>) F0 00 20 21 60 00 01 0A 41 44 5F 20 F7 // up F0 00 20 21 60 00 01 0A 41 44 30 4F F7 // down F0 00 20 21 60 00 01 0A 41 44 00 7F F7 // select/ok Note: Creative did not give the group names. The buttons (<<) and (>>) in the browse group could be used for 4x backward and forward playing as well. Note: number 0 is alone on the line and next to the transport group. It could be used in the transport control. Note: speaker button makes no code itself but it works like the shift key. Why the button is not named "shift" because it works as "shift" button for all groups. Note: there is no other "shift" button. Note: "slow", "previous", "next", "step" and "cancel" are printed under the buttons. So, "||>" and "step" could have totally different meanings. == end ==

22 years, 1 month

[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

22 years, 1 month

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

22 years, 1 month

[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

22 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