Linux-audio-dev May 2003

linux-audio-dev@lists.linuxaudio.org

71 participants
56 discussions

[linux-audio-dev] Alsa /dev/sequencer stuff

by Ivica Bukvic

Hi all, I was wondering the following: In my app (RTMix) I will be soon implementing multiple midi-input device opens, so that the app can be controlled from as many of the midi controllers simultaneously as possible. One way of devising this was to design a separate thread for every open device (using raw midi /dev/midi etc., although I will be re-implementing that to use ALSA devices directly). However, this might not be the most elegant way of doing this, so what I was wondering is how does the /dev/sequencer correspond to this issue? I mean, does it work the same way like addressing the raw midi ports, are the message formats the same, and most importantly does one SINGULAR /dev/sequencer encompass all of the midi ports that are currently available? I would greatly appreciate any help on this issue, as well as some code examples. Thank you! Sincerely, Ivica Ico Bukvic, composer & multimedia sculptor http://meowing.ccm.uc.edu/~ico

21 years, 6 months

[linux-audio-dev] rtp-midi update ...

by John Lazzaro

[ My apologies if you see this more than once ... --jl ] Hi everyone, I've spent the last few months editing a document that attempts to resolve the "open issues" that were outstanding in the "RTP payload format for MIDI" we've been working on in the AVT working group in the IETF. I believe the I-D that I submitted today: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-rtp-midi.txt addresses them all (famous last words :-). So, if you have an interest in sending MIDI over IP networks using RTP (the IETF telephony and content-streaming protocol), but you've been waiting for a mature document before committing to reading through 100 pages of MUSTs and SHOULDs, now is a good time to download the I-D and send along comments and bugs. This document, updated to reflect new comments, will form the basis of the "Last Call" document I submit to the IETF in about a month or so. Thanks again, ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------

21 years, 6 months

Re: [linux-audio-dev] Re: final scratch + native instruments

by Patrick Shirkey

Martin Buechler said >Alas, don't know what OS it was, but if something remains unclear, I >might jump in my pants and go ask them. or you could just let them know about terminatorX and GDam... Nice to know they have open sourced their code though. I hope that means they have made enough money out of the product over the past year that they can afford to make it free and not that they are drawing straws to make enough money to survive. Perhaps they could have been more friendly to us rounds here and we could've promoed them a bit more to our business partners.... -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== Being on stage with the band in front of crowds shouting, "Get off! No! We want normal music!", I think that was more like acting than anything I've ever done. Goldie, 8 Nov, 2002 The Scotsman

21 years, 6 months

Re: [linux-audio-dev] change my email

by CK

I read: > so I'd like to unsubscribe then. how do I do it? stupid question maybe. http://www.linuxdj.com/audio/lad/subscribelad.php3#subscription HTH x -- chris(a)lo-res.org Postmodernism is german romanticism with better http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)

21 years, 6 months

Re: [linux-audio-dev] change my email

by wisehart＠runbox.com

> is it possible to change my e-mailadress lobotomi(a)suomi24.fi to leppi666(a)suomi24.fi. > donŽt wanna get out off the list. You could unsubscribe, and re-subcribe w/the new address. I think I've done that in this list.

21 years, 6 months

[linux-audio-dev] change my email

by lobotomi＠suomi24.fi

is it possible to change my e-mailadress lobotomi(a)suomi24.fi to leppi666(a)suomi24.fi. don´t wanna get out off the list. thanks. ,Tomi _____________________________________________________________ Kuukausimaksuton nettiyhteys: http://www.suomi24.fi/liittyma/ Yli 12000 logoa ja soittoääntä: http://sms.suomi24.fi/

21 years, 6 months

[linux-audio-dev] (no subject)

by laced milk

_________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail

21 years, 6 months

[linux-audio-dev] Planning and Scheduling CD

by Tessa Marquis

New Standard Institute has developed "Maintenance Planning and Scheduling", a computer based training. This product is available as an instant download or on a CD and has been nominated "Product of the Year Finalist" by Plant Engineering magazine. Click on the link below for details. http://www.newstandardinstitute.com/mps2.cfm?uniqueid=F0876 The material is extracted from New Standard's seminar on the subject, enhanced with animation, interactive examples, pop-up definitions, enlargeable graphics, narration and an internal search function. We continue to provide our seminars in major North American cities such as Nashville, Toronto, New Orleans, and Orlando. For personal assistance, contact: Tessa Marquis tmarquis(a)newstandardinstitute.com or by telephone at 203 783 1582

21 years, 6 months

[linux-audio-dev] pthreads and signals

by Paul Davis

is there anyone here who has any idea how to handle segv's in a linuxthreads-using application? i know that many of you are aware that i've used threads a lot in my apps, and grappled with lots of tricky signal related issues. however, i continue to see something really deeply ugly in linuxthreads: segfaults seem not to be handled in the same way as other signals. when a thread in ardour causes a segfault, that thread is killed (actually, it becomes a zombie, waiting for its parent to exit) and thats the end of the signal handling. for all other signals, my code causes them are delivered to a single thread that is waiting on all waitable signals except SIGCHLD, and we get control there in a useful way. its very distressing: a segfault will cause ardour to cease normal operation, but nothing knows it has happened. if its in (say) the disk butler thread, the GUI will continue working normally, but nothing will actually do the right thing. has anybody come up with code in which segfaults within threads are handled? i have a few ideas on an approach that might work, but i'm asking first :) nb. this is true in JACK as well.

21 years, 6 months

[linux-audio-dev] FFTW 3.0 performance testing?

by Anders Torger

Has anyone made any FFTW 3.0 performance testing? I'm especially interested to know how it compares on a Pentium 4 (or similar) to the FFT found in Intel's proprietary performance libraries. /Anders Torger

21 years, 6 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 May 2003