Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7440 discussions

Re: [linux-audio-dev] Just for fun - Hearnet

by CK

I read: > soon we will see network operators starring at contemporary music festivals. actually sonification of traffic is already passe, you probably should have attended some of the festivals ;) regards, x -- chris(a)lo-res.org Postmodernism is german romanticism with better http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)

20 years, 10 months

[linux-audio-dev] Check this out!

by Matt Gerassimoff

http://www.lionstracs.com/ -- Matt Gerassimoff

20 years, 10 months

[linux-audio-dev] Oss & threading -- is it possible

by hexe_2003＠directbox.com

Hello ! I've read somewhere that it is not possible that threads write different data to /dev/dsp. But how does Cheesetracker, for example, make it then? Sascha Retzki __________________________________________________ Verpassen Sie keine eBay-Auktion und bieten Sie bequem und schnell über das Telefon mit http://www.telefonbieten.de Ihre eMails auf dem Handy lesen - ohne Zeitverlust - 24h/Tag eMail, FAX, SMS, VoiceMail mit http://www.directbox.com

20 years, 10 months

[linux-audio-dev] a night stolen to sleep

by Antonio Willy Malara

i was fooling around with gimp when a thing like this appeared on the screen... http://rclug.linux.it/ladspa.png do you like it? i thought that was a cool logo for ladspa plugins, instead of the blurred green/blue text... wil --- "If you have to ask what jazz is, you'll never know." -- Louis Armstrong.

20 years, 10 months

Re: [linux-audio-dev] M-audio transit/ozone/MobilePre experiences?

by Clemens Ladisch

Mannr(a)uwaterloo.ca wrote: > Does the M-audio MobilePre work with Linux? No. > Earlier there was a 'beta' released (by Clemens Ladisch): It doesn't work. I think there is a bug in the USB subsystem in the kernel, but I don't have time to research further now. Currently, these devices don't work with Linux at all. > I am also considering the Tascam US-122 as an alternate, This one isn't fully compatible with the USB Audio specification, either. I'm not sure if the special driver supports all features. HTH Clemens

20 years, 10 months

[linux-audio-dev] [CODE RFC] redefining sched_setscheduler using LD_PRELOAD

by Roger Larsson

Hi, (Jack O'Quin got me thinking about rt_monitor again - thanks!) This is an alternative to capabilities / SCHED_SOFTRR... I use my old rt_monitor * protects the system on RT overload * performs the actual setting of scheduler type * it does not even have to be visible for lusers! My old testprogram RT has been converted to a library fit for preloading. It works like this. As root start # rt_monitor As normal user start latencytest $ ./rts path/to/latencytest none 2 128 10 rts has two options -i do not raise the priority. -v be more verbose. * It does also limit the effective min/max range. Do also try (don't try this as root unless rt_monitor is running) $ ./rts path/to/latencytest none 2 1024 99 * In this case rt_monitor captures the process and renices it. (SCHED_OTHER + nice) BUGS: * better build and installation system * could ignore RT processes already running when rt_monitor starts * rt_monitor functionallity has not been reverified... * it can't lock memory :-( No PIDs in calls. * code that checks uid before using the redefined functions won't work (I have an modified latencytest) * client get stuck if there is no monitor running. /RogerL -- Roger Larsson Skellefteå Sweden

20 years, 10 months

Re: [linux-audio-dev] Fwd: [[NO] PATCH] cfq + io priorities

by Kjetil Svalastog Matheussen

Paul Davis: > >I guess this will be of interest to some of you... > >An even newer version has shown up on linux-kernel. > > its not clear how useful this really is. we know that the disk i/o > system can't keep up with realtime needs by definition - there has to > be a significant buffer between the disk and the RT audio thread. i'd > be suprised if it really helps any actual apps, because they've > already got this buffer in place, and the buffer hides the lack of > dedicated resource allocation on the part of the kernel. > Perhaps it would help programs that does everything inside one process, like snd. --

20 years, 10 months

[linux-audio-dev] Re: Programming resource question

by vanDongen/Gilcher

Excellent plan. Maybe I could contribute, since I was thinking along the same lines as well. My performance system is a pd pattern sequencer triggering csound, also geared to my personal setup, and I have been thinking on moving it to C as well. Parts are already coded in C as a pd external. Gerard On Thursday 13 November 2003 11:39, ian duncan wrote: > Well I'm actually making more of toolkit for do it yourself modular live > sequencing systems. So the idea is that one might use parts of it on PC, > port parts to Pic chips, or run parts coded in something like Csound or PD. > At the moment the whole thing is a gigantic Csound ensemble heavily > tailored around my own personal gear set up, so I haven't had to worry > about any low level stuff yet. But I would like to start modularizing it > and making it available to other people and platforms. It works well in > Csound, but file i/o is kluderific so I'd like to get that kind of stuff > going in C as well. > > Thanks, > Iain > > -- electronic & acoustic musics-- http://www.xs4all.nl/~gml

20 years, 10 months

[linux-audio-dev] Ann. Mammut V0.16

by Kjetil Svalastog Matheussen

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.15 -> 0.16 -Tiny source cleanup. -Upgraded the included sndlib i386-binary to latest version. This one includes jack-support. http://www.notam02.no/arkiv/src/ --

20 years, 10 months

[linux-audio-dev] Fwd: [[NO] PATCH] cfq + io priorities

by Roger Larsson

Hi, I guess this will be of interest to some of you... An even newer version has shown up on linux-kernel. /RogerL From: Jens Axboe -------------------------------- Hi, I've implemented IO nice levels in the CFQ io scheduler. It works as follows. A process has an assigned io nice level, anywhere from 0 to 20. Both of these end values are "special" - 0 means the process is only allowed to do io if the disk is idle, and 20 means the process io is considered realtime. Realtime IO always gets first access to the disk. Values from 1 to 19 assign 5-95% of disk bandwidth to that process. Any io class is allowed to use all of disk bandwidth in absence of higher priority io. Idle and realtime IO settings work as expected, but not much tuning has gone into making sure that the individual levels in-between work 100% as expected. It should be good enough for some testing at least, even if it has some holes. About the patch: stuff like this really needs some resource management abstraction like CKRM. Right now we just look at the tgid of the process. I've added two syscalls for setting and getting io priority. Don't consider this final or anything, it's just easy for testing. Patch has been tested on x86 and ppc, syscalls are also added for x86_64. I'm attaching the simple ionice tool. It's used as follows: # ionice -n20 bash starts a bash shell with realtime io. Beware that io level is inherited on fork, so any program you start from this shell will also run with realtime io. # ionice -n0 dbench 32 run some dbench thrasher, but only when disk is idle. Pretty straight forward :-) For really good results, you probably also want to set cpu nice level. Needless to say, a realtime io process can only submit io when it gets scheduled. Default IO priority for a new process is 10. Patch is against bk-current. -- Roger Larsson Skellefteå Sweden

20 years, 10 months

Jump to page:

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