Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7513 discussions

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

21 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

21 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

21 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

21 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

21 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

21 years, 9 months

[linux-audio-dev] CD fast forward behaviour

by Paul Davis

does anyone know what a h/w CD player actually does when in fast forward mode? does it skip sectors? how many? etc. thanks.

21 years, 9 months

[linux-audio-dev] Re: [linux-audio-user] Re: Firewire, what's the story?

by Robert Jonsson

Hi, tisdagen den 09 december 2003 12.22 skrev Steve Harris: > On Tue, Dec 09, 2003 at 09:25:42AM +0100, Clemens Ladisch wrote: > > > > I seem to recall that it does, but that the packet size is smaller, > > > > making the latency problem easier to deal with. > > > > > > Isoch - 1394 has a timer operating on the bus. This timer happens > > > (roughly) every 125uS. > > > > USB isochronous transfers happen once per millisecond. > > OK, so its the difference between 44 or 45 samples per packet at 44.1kHz > (USB) and 5 or 6 (1394). > > So, a plausible jack period of 64 samples will be 11 or 12 1395 packets, > but always 125uS of jitter of course, (10 or 11 packets at 48k). > > I dont really have any idea how bad that is, its 8% of the availble time > slot for processing the 64 samples. > > You could lessen the effect of the jitter by having triple-buffering in > software, as in a 3x64 PCI soundcard - I dont know wether thats better > than just going to 128 samples or not. > > FWIW, for my needs I rarely go below 256 samples/period anyway, even > though my setup is capable of it, but I understand there are people who > really need very low latency. > > At 256 samples/period the jitter is only 2.1% of the time slice, which is > unlilkly to matter - cache temperature and so on has a far greater effect > than that. Though it is interesting debating the technical merits of firewire, for me, atleast, it would be far more interesting to get it actually working. I'm _very_ interested in utilizing these hardwares. I googled a little last night, some people we all know popped up here and there (Hi Steve, Mark and Bob). There was a LAD message from 2001, someone who had been in contact with Yamaha and it seemed they(Yamaha) where working towards making mLan a part of the A&M standard (I think I got that right...not sure)... now... I'm not entirely sure what this means. It seemed as the A&M standards also cost a lot of money? Do we have enough information to implement mLan support? As I understand it, Bob Ham had/is working on implementing 61883 support for Jack, which seems like it's needed for mLan, a layer below it perhaps? How far has this come, is there something one can test somehow, what hardware do one need? Regards, Robert ps. I'm cc:ing LAD as I'd like to move the discussion there. Remove LAU if you respond to this. ds.

21 years, 9 months

[linux-audio-dev] Re: [linux-audio-user] Timidity

by holborn

On Martes, 09 de Diciembre de 2003 10:57, Gerrit Niestijl wrote: > Hi, > > When i use timidity in alsa seq mode with a sequencer like muse or > seq24, the timing is not very good. If i use fluidsynth the > timing is much better. I would like to use timidity though, because > of its support for the Midi Tuning Standard. > > Are others seeing this too? Are there any options or > other ways to improve the timing for timidity? try to start timidity with: -B2,8 Josep

21 years, 9 months

[linux-audio-dev] New Linux Audio Column in Linux Journal

by Joern Nettingsmeier

hello linux audio enthusiasts! reading lwn.net this morning i found that the linux journal has a new linux audio column in their online edition, written by dave phillips. the current issue is at http://www.linuxjournal.com//article.php?sid=7283 . the content of this first issue will not be news to you, since it's basically a plug for the world's finest linux audio mailing lists, which you already seem to know about :) still, it's an interesting read, and it has had an effect already: about 30 new subscriptions (in addition to the usual continous growth) since wednesday... (see http://www.linuxdj.com/audio/lad/subscribe.php3 .) to all new readers: welcome aboard! best, jörn -- To someone whose only tool is a hammer, each problem looks like a nail. - Edsger W. Dijkstra, EWD838 Jörn Nettingsmeier Kurfürstenstr 49, 45138 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxaudiodev.org (Linux Audio Developers)

21 years, 9 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