Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

5 participants
7461 discussions

Re: [linux-audio-dev] latency performance of 2.4 and 2.5...

by Joern Nettingsmeier

Peter L Jones wrote: > > On Friday 11 Oct 2002 13:48, Joern Nettingsmeier wrote: > [snip] > > i have run benno senoner's latencytest on both kernels. you can see the > > results at > > > > http://spunk.dnsalias.org/latencytest . > > > > Jörn, could you post the latencytest URL, please. > > Thanks, > > -- Peter http://www.gardena.net/benno/linux/latencytest-0.42-png.tar.gz -- Jörn Nettingsmeier Kurfürstenstr 49, 45138 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)

22 years, 2 months

[linux-audio-dev] Meterbridge 0.0.5

by Steve Harris

http://plugin.org.uk/meterbridge/ New features: Jellyfish meter (aka. stereo phase meter) Can choose number of columns Signal freezes if you click left mouse button on the window Some segfaults fixed Outstanding problems: Uses contraversial rewiring connection to inputs Needle graphics still a bit crap Inefficient - Steve

22 years, 2 months

RE: [linux-audio-dev] Needing advice on implementing MIDI in my app (RTMix)

by John Lazzaro

> 2) Can I use DMIDI in combination with TCP/IP (I saw you mentioned UDP > on your site)? If you're sending over IP, you should also look at MWPP, an RTP packetization for MIDI under development in the IETF. See: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-mwpp.txt ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------

22 years, 2 months

RE: [linux-audio-dev] Needing advice on implementing MIDI in my app (RTMix)

by Ivica Bukvic

Thanks for a quick reply. One more question: 1) Is there good documentation to be found, or even better, source code? 2) Can I use DMIDI in combination with TCP/IP (I saw you mentioned UDP on your site)? 3) Does application have to be DMIDI-aware in order to be able to send/receive MIDI via DMIDI server or does DMIDI server simply act transparently between sender and receiver (if they are presumably on the same machine)? Again, thanks for your help! Sincerely, Ivica Ico Bukvic > -----Original Message----- > From: Phil Kerr [mailto:philkerr@elec.gla.ac.uk] > Sent: Thursday, October 10, 2002 9:49 PM > To: Ivica Bukvic > Subject: Re: [linux-audio-dev] Needing advice on implementing MIDI in my > app (RTMix) > > Hi Ivica, > > DMIDI may be of some use to you. You can have one DMIDI server and your > MIDI > applications can broadcast DMIDI data. You use the server to isolate you > from > hardware and MIDI API's > > http://www.dmidi.org > > Cheers > > Phil >

22 years, 2 months

[linux-audio-dev] go try 2.5 - it's not that bad...

by Joern Nettingsmeier

hi guys ! i have just built and booted into 2.5.41, and it turned out to be easier than i thought. everything works as before, and the kernel has now been running stable for over a day. i would encourage other audio users to give it a try as well, it's painless. using a current distro (suse80), i didn't even have to update userspace tools (at least nothing has bitten me yet). be sure to have a backup, of course. i have only scsi disks, so i can't say how the IDE stuff turned out, but i hear it is sane again. best, jörn benchmarks coming.... -- Jörn Nettingsmeier Kurfürstenstr 49, 45138 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)

22 years, 2 months

[linux-audio-dev] Needing advice on implementing MIDI in my app (RTMix)

by Ivica Bukvic

Hi all, Currently, I am working on implementing MIDI in my app, and this is what I am currently trying to solve: I just simply want to implement MIDI >not as a sequencer<, but rather as an external controller of various events (since this is what my app RTMix does). Now, the problem is also that I want to use MIDI for intercommunication between my app and other apps running concurrently on the same machine (i.e. Pd), so here is the list of questions I would greatly appreciate any help on: 1) First off, is there a simple GPL library that is easy to implement and that focuses on MIDI? If not, any website with some sample code would be greatly appreciated! 2) I am trying to design something that is not driver specific (i.e. OSS or ALSA), so is there any way to do this (i.e. sending message directly to /dev/midi device or something similar without blocking it to other apps) 3) For checking the presence of the midi interface on a Linux box, is it safest to look for /dev/midi device, or is there a "nicer" way? 4) Is there a way to send MIDI data in such a way that it is perceived by other app on the system (i.e. like sending a midi signal through midi-out which is via cable connected to midi-in on the same machine, except without doing so physically)? If so, how? If not, what are the alternatives (other than above-mentioned physical solution)? 5) Finally, this may be a bit far-fetched question, but here it goes anyhow: does anyone know if Pd and other applications like it are able to receive simple numeric messages via network (TCP/IP) protocol (since this would be an alternative to #4)? Any help on this matter is greatly appreciated! Sincerely, Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster & computer consultant http://meowing.ccm.uc.edu/~ico/ ============================ "To be is to do" - Socrates "To do is to be" - Sartre "Do be do be do" - Sinatra "I am" - God

22 years, 2 months

[linux-audio-dev] seeking history about GuitarPort discussion

by Ike Stoddard

Folks, I am new to LAD, and I have a personal mission in which I hope I'm not alone. I am trying to scope the work involved in interfacing the Line6 GuitarPort to Linux. I've searched the LAD archives, but can't find a thread about it. Would those of you who gotten further along the curve than I, please clue me in: where is this being discussed? I've also emailed Line6's bizdev but have no answer. Is the interface spec available for $$$? Thanks in advance, Ike, stoddard_AT_ghg.net

22 years, 2 months

[linux-audio-dev] Where I am with GWC

by Jeff Welty

I have released GWC 0.17-6 (beta). This release primarily is an integration with libsndfile, and also improvement in denoising using a hanning-overlap-add (well, kinda) windowing method. Find it at: http://gwc.sourceforge.net/ While I believe improvements could be made in the click detection algorithm in regards to reducing the false positives, I am going to forgoe that effort because -- At long last, I am going to take the first steps toward making the algorithms plugin-able, by creating a library interface first. This is largely due to prompting by Conrad Parker. I've looked at the LADSPA thing, and asked a couple of people, and these algorithms are not LADSPA-ize-able. So, a first reasonable step is to just create a library of routines, with a well defined API which other apps can code against, eventually a plugin of some sort could be coded against the library. Over the next month, I hope to have the denoising algorithm converted to a library interface (having a day job really does get in the way :-) I'll post here along the way for help/tips -- and if anyone has some suggestions for me now, speak up! I am still relatively ignorant on linux audio, I need all the help I can get... jw

22 years, 2 months

Re: [linux-audio-dev] meterbridge 0.0.4

by Tom

> will try to create an input -> input connection sometime tommrow and see > what happens. In case this doesn't work, I'll offer more detail on how to do it with busses. The more I think about it, the more I like the idea of preserving output -> input semantics anyway. Currently, when connecting more than one output to Client A's input, jack automatically adds the outputs and writes the result to A's buffer. This is now an input port, so its contents are only available to A. The lazy way to make the result of the add available to a meter, or any other clients, is to refrain from connecting the output ports to A's input and create a dummy jack client that just passes its input to its output. Connect the multiple output ports to the input of the dummy and connect the output of the dummy to the input of A. JACK automatically adds the multiple outputs as before, but this time it writes the result to a buffer that is an output port, so it is readable by all other clients. The dummy client is a perfect audio bus. I call this the lazy way because telling the user to use a client that does nothing, as a way of allowing the user to do something, is absurd. Also, if A's input is already connected to one output and the user wants to add another output to A's input, the user must first disconnect the first connection, then create the dummy, then connect the dummy's output to A's input, then connect all other outputs to the dummy's input. That's a lot of stuff for the user to do, indicating a lazy program. A more ambitious approach is to modify jack to create an input bus automatically whenever an input port is connected to more than one output port. First eliminate the ability for a client's input to be many-to-one. Every input port can now connect to only one output port. This might seem drastic but it's not, and it perfectly models the physical world (in the physical world, connecting two outputs to one input also connects their outputs to each other. Since output impedance is lower than input impedance, the signals flow from output to output with excessively high current and the input sees almost nothing. Using a bus to buffer the outputs is mandatory). This change is hidden from the user, who will still be allowed to connect as many outputs to A's input as he desires. The next change is to redefine how jack makes a many-to-one connection. When the user adds or deletes a connection to A's input port, jack checks to see if the new total number of connections is greater than 1. If so, jack inserts a bus, which is just a buffer, in front of A's input port and writes the sum of the outputs to this bus. The existence of this bus is hidden from the user (busses are always hidden internal mechanisms). Now any client can read from A's input port by reading from the bus output port. The state of the bus buffer with this technique is more stable than the state of A's buffer with the current technique, in that it changes only once per jack cycle while A's buffer currently changes twice per jack cycle. Tom

22 years, 2 months

[linux-audio-dev] Promoting Linux Audio

by Patrick Shirkey

For those of you who haven't yet check out the LAU guide (see below) and quicktoots. There is a new tutorial explaining how to do what you want with JACK, Ardour and MusE. I have been trying to get some of the news sites to report on this latest tutorial. I believe it is a huge step and very important milestone that has been reached. However they don't seem to want to report my words. It would be great if a *few* other people made an attempt then we might be able to catch their attentions. I have tried linuxnews, slashdot, linuxtoday, and a few others. It would also be great if someone who has contacts with the pro magazines would let them know. As it stands I'm going to keep trying but one voice is not so easily heard in this big bad world. -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== "Um...symbol_get and symbol_put... They're kindof like does anyone remember like get_symbol and put_symbol I think we used to have..." - Rusty Russell in his talk on the module subsystem

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