Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

Start a nNew thread

[linux-audio-dev] Re: Merhaba..

by Hande

22 years, 7 months

RE: [linux-audio-dev] How to delay video?

by Sreelal Chandrasenan

Hardware video delay price is around $2500-$3500. Cost is based video delay time. These are having about one second delay. -----Original Message----- From: Anders Torger [mailto:torger@ludd.luth.se] Sent: Friday, March 07, 2003 11:22 AM To: linux-audio-dev(a)music.columbia.edu Subject: Re: [linux-audio-dev] How to delay video? On Friday 07 March 2003 10.04, Nick Bailey wrote: > Just at thought, but the best place to insert the delay would surely > be the MPEG data stream. Unfortunately, I don't know of any DVD > players which have MPEG out on the back, presumably because of the > Movie maffia being afraid you can take stills of their beautiful art > and make it into a lowly mouse mat or something. Since MPEG is ?about > 2Mb/sec (just guessing), it should be quite easy to buffer a few > seconds of it. > > Incidentally, RGB would be better than the S-Video: the chrominance > in S-Video is still band-limited and QAM, but separate from the > luminance (hence the S) so that they don't interfere with eachother. Ok, I see there are some hardware solutions in separate boxes, which probably works quite well, but price is quite high, it seems to be at least 5000 US dollars to get a video delay box. /Anders

22 years, 7 months

[linux-audio-dev] [ANN] RTMix software interactive multimedia interface version 0.7 released (3/10/03)

by Ivica Bukvic

Hello fellow musicians, composers, multimedia sculptors, and developers! It is my pleasure to announce to you the newest release of RTMix version 0.7. New improvements include: *Internal error widget has been removed. *External Error Log now became a general purpose Console. *Added visuals for monitoring of data flow at the bottom of the external Console. *Sped-up the start-up time by 300-400% (literally :-) *Fixed bug where global transport events did not execute on a local client causing many scripts to fail. *Reordered Tabs on the main widget. *Made External resizable widgets resizable only when performance was not in session (in order to minimize cpu-utilization by RTMix during the performance settings). *Fixed Metronome weird resizing bug. Now when the meter is changed, the widget resizes appropriately. *Fixed color coding errors for the notification interface. *Re-arranged the settings saving routines. *Added new parameters to the config file. *Added networking authentication code and made it configurable in the settings tab. *Added filter for events in order to disable potentially malicious sys-calls to be executed. *Fixed gazillion (literally :-) bugs in the parsing engine. *Standardized error and logging output messages. *Color-coded Console messages. *Added "go-to-error" feature. *Implemented MIDI protocol as a separate thread. Users can now use MIDI for real-time events, as well as MIDI routing. *Provided new tabs in the settings menu that enable user to specify the appropriate MIDI port. *Implemented OSC (Open Sound Control) for inter-app communication. *Implemented generic OSC network communication. *Implemented OSC routing for the purpose of sharing the MIDI port. *Enabled variables to be included in notification interface messages. *Enabled multiple instance of variables and MIDI parameters to be included in functions, assigns, and events (sys calls and others). *Fixed metronome's inconsistent resizing. *Fixed bug where BPM's on the metronomes 2-4 were corrupt. *Jump events now interpret events they jump to in a proper fashion. *Added full-fledged HTML documentation (Yay!) *Included more tutorials and provided better annotations for the older ones. *Made apply button disabled in the settings menu, unless something was changed. *Made MIDI monitoring and MIDI logging buttons disabled by default, unless the real-time monitoring is enabled. *Added color-coding and more verbose descriptions of the real-time events in the table. *Enabled differentiation between keyboard presses and releases and their mappings to the real-time events. *Added line-number tool for the editor. *Fixed behavior of the probability parameters. *Annotated more parser's warnings. *Implemented protection against infinite recursion scripts. *Other stuff that I cannot think of at this moment. --------------------------------------------------------------- RTMix is downloadable here: http://meowing.ccm.uc.edu/~ico/rtmix-latest.tar.gz (approx. file size is 4.8MB). For more info, see the included HTML docs, or visit the author's webpage at http://meowing.ccm.uc.edu/~ico/ RTMix currently runs only on Linux, although the transparency of code should make it easily portable to other Unix platforms supporting Qt toolkit. --------------------------------------------------------------- If you are not familiar with RTMix, here's a quick overview: What is RTMix? RTMix is an open-source (GPL-licensed) software application designed to provide stable, user-friendly, standardized, and efficient performance interface that enables performer(s) to interact with both the computer and each other in the least obtrusive fashion. What this means is that RTMix offers an array of visual stimuli that can be utilized on-stage in order to coordinate various performing forces utilizing diverse media. What do I need it for? How many times have you witnessed an interactive work that requires coordination between the composer and performer, composer usually being off-stage and posing as an aircraft navigator sending out all kinds of signals with waving hands and other distracting (perhaps even comical) physical gestures? Have you ever questioned computer's off-stage presence when it has an important role in generating the resulting sonic landscape (or even a multimedia setting)? Did you ever wish to have an elegant on-stage interface that is easy to use and furthermore provides the least amount of distraction for the performer(s) -- an interface that offers standardization, transportability, and most importantly low cpu-footprint, therefore enabling user to utilize majority of processor cycles for the stuff that matters the most -- the content-generation, processing and reproduction? Have you ever wished to have your work more "transportable", to have it more accessible and more easily performable in settings where you were not physically available to provide technical support to the not-so-computer-literate performer? Did you ever write a chamber acoustic work that required considerate amount of coordination but you did not want to use a conductor? How about a work for a large performing groups? Do you use powerful Music-N languages for real-time work but do not have an elegant interface for real-time performance settings? Are you a PD/Max/MSP/jMax object-oriented multimedia composer, but do not want to deal with designing the user-interface for your contraptions, nor with the lack of standardization such interfaces impose on end-users (i.e. performers other than the composer themselves)? Did you ever feel like using only one multimedia tool at a time was limiting your creativity (i.e. Csound, RTcmix, Supercollider, Pd, Max/MSP, etc.) and that you always wanted to have multiple audio applications to coexist in your work? If you have answered any of these questions positively, then RTMix just might be the answer to your needs :-). Ivica Ico Bukvic, multimedia sculptor http://meowing.ccm.uc.edu/~ico P.S. Apologies for cross-posting! Some mailing lists ate up my original post :-(

22 years, 7 months

[linux-audio-dev] MWPP status for SF IETF meeting ...

by John Lazzaro

Hi everyone, The pages fly off the calendar, and its time for another IETF meeting -- MWPP is getting pretty close to Last Call, I posted a few outstanding timing issues to: http://www1.ietf.org/mail-archive/working-groups/avt/current/msg02221.html that might be of interest to some LAD folks ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------

22 years, 7 months

[linux-audio-dev] For Sale Digital Audio Adapter

by Santoso Toto

for sale Audioscience ASI4312 new surplus never installd 2 unit and ASI4133 1 unit price us$ 250per unit if you interest please contact to us E-mail:yuripid@yahoo.com,Than's __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/

22 years, 7 months

[linux-audio-dev] Re: [Alsa-devel] Audigy1 MIDI input, wavetable support?

by Josh Green

On Fri, 2003-03-07 at 07:44, Mark J Roberts wrote: > I am trying to load a soundfont into my Audigy1's wavetable and play > it with a MIDI keyboard. I am using kernel 2.5.64. > > MIDI output verifiably works. However, MIDI input does not. The > cable and keyboard are not the problem--I've tried them with an > es1371, and I easily got MIDI input working. > > My procedure with the Audigy1: > > cat /dev/snd/midiC0D0 > watch /proc/interrupts > watch /proc/asound/Audigy/midi0 > > No interrupts occur and no bytes are read. I have also tried using > aconnect to connect the inputs. Does anyone else see this behavior? > > I've got one more question. What program should I use to configure > the wavetable and load the soundfonts? I found a couple versions of > "awesfx", neither of which was compatible with my ALSA. > > I know that ALSA contains support for the wavetable of the EMU8k and EMU10k series of cards (AWE 32/64 and Live! respectively). I'm not absolutely sure whether the wavetable on the Audigy is also supported, but chances are it is. The SoundFont loading API is OSS based, but ALSA uses it so awesfx (sfxload utility, etc) should work (provided the API is actually there for the Audigy). I'm convinced that software synthesis is the way to go. It allows for easier routing of the synthesized data (via Jack for example) and supports any sound card. This is the approach I have gone with with Swami (http://swami.sourceforge.net) the successor to the Smurf SoundFont Editor which was based on the OSS awesfx API. Swami uses FluidSynth (http://www.fluid-synth.org - was previously called iiwusynth) to do software synthesis of SoundFont files. Using software synthesis gives us these additional features over current Linux supported hardware solutions: - Modulator support, allowing for real time modulation of effects with MIDI controllers (or with GUI controls from Swami) - Customizable Reverb/Chorus (EMU10k doesn't have support for these effects in Linux) - Routing of audio via Jack, opening up a whole world of audio processing, effects, etc. The downside is of course the CPU usage, so in the future I will likely be re-adding support to Swami for the hardware wavetable OSS API. If you want to check these projects out, you can either wait a few days for FluidSynth 1.0 to be released which a release of Swami will follow shortly after, or you can get Swami CVS and FluidSynth CVS. Cheers. Josh Green

22 years, 7 months

Re: [linux-audio-dev] MIDI sync and ALSA sequencer

by John Lazzaro

> Arthur Peters <amp(a)singingwizard.org> > > MIDI Clock mainly but MIDI Tick would be cool too MIDI Tick is a rogue use of an undefined System Realtime command; see: http://www.midi.org/about-midi/table1.shtml and notice that the "System Real-Time Messages" has "undefined opcode" where the MIDI Tick opcode should be. The MMA liaison to MWPP (Jim Wright) spotted this a few weeks ago, the next rev of the MWPP document will excise MIDI Tick completely. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------

22 years, 7 months

[linux-audio-dev] MIDI sync and ALSA sequencer

by Arthur Peters

Could someone point me to some documentation on how to send and receive MIDI sync? (MIDI Clock mainly but MIDI Tick would be cool too) I found a document at http://www.alsa-project.org/~iwai/alsa-sync.html but the last date in the what's new list is in 2000 and most of function are missing from the API, so I figure it's very out of date. Thank you. -Arthur -- Arthur Peters <amp(a)singingwizard.org>

22 years, 7 months

[linux-audio-dev] VSIPL

by Sebastien Metrot

I learned about www.vsipl.org . I thought making a LGPL version of this lib (with Altivec/SSE versions) could be a very interesting project, and a valuable tool for most of us. What do you think? Sebastien

22 years, 7 months

[linux-audio-dev] midiman firewire interface (!?)

by rm

anyone know anything about http://namm.harmony-central.com/WNAMM03/Content/MAudio/PR/FireWire-410.html ? seems interesting and if i recall, maudio/mman has been somewhat supportive in the past. rob ---- Robert Melby Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a Internet: async(a)cc.gatech.edu

22 years, 7 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