Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7513 discussions

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, 11 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, 11 months

[linux-audio-dev] xrun record?

by shiva shankar

Hi Paul , Did u got the solution for the problem that xrun, (overrun) problem. Thank you Shiva

22 years, 11 months

[linux-audio-dev] (ADV) Your Website

by cust_service＠net-submissions.net

Hello, My name is Jane and I am the marketing director of Netsubmissions.net. We are a website submission company that can submit your site to the top search engines such as Google and Lycos utilizing our proprietary custom software. Our packages start as low as $8.99 and we're offering great articles about online marketing with most of the packages. Please check us out at http://www.net-submissions.net The process takes less than 2 minutes. Check our web site - we will help you obtain more sales. If you have any questions that are not answered at http://www.net-submissions.net please use the contact form or email me. Once again, I would like to thank you for your time, and if this email was an inconvenience to you, I would like to apologize. If you would like to be removed from our mailing list, please type ¡°remove¡± on the subject and we will make sure to not send you any more emails. Thank You, Jane L. Marketing Director Cust_service(a)net-submissions.net Http://www.net-submissions.n

22 years, 11 months

[linux-audio-dev] Final Scratch, custom kernel?

by robbins jacob

has anyone looked at the distribution of linux that FinalScratch comes with? I read on their website that you basically install their distribution of linux and use it, along with their program for selecting audio files, to play their electronic turntables. I'm just wondering if there was anything in particular they tweaked for realtime response or if they used the same low-latency patches as the rest of us? In case you've never seen it in action, final scratch is a record sized disc that you place on a turntable that reports it exact position to some sort of computer interface. The position signal is then used to control playback of audio files (pcm or mp3) on the computer. You load a file into the program and mark a certain point as the current point on the record and then the playback and cueing of the file can be done entirely on a regular turntable as if you were playing a record. Given that this is just a piece of hardware, I'm wondering what would stop you from hooking up the hardware to a regular version of linux..... besides using a proprietary interface i mean. --jacob robbins::::::: _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx

22 years, 11 months

RE: [linux-audio-dev] Final Scratch, custom kernel?

by Cornell III, Howard M

What am I missing here? I don't mean to tell the direction from the time, but to tell the position from the time. The sawteeth all look the same, right? Don't we need to tell position somehow? -----Original Message----- From: Steve Harris [mailto:S.W.Harris@ecs.soton.ac.uk] Sent: Tuesday, October 08, 2002 8:59 AM To: 'linux-audio-dev(a)music.columbia.edu' Subject: Re: [linux-audio-dev] Final Scratch, custom kernel? On Tue, Oct 08, 2002 at 07:17:43 -0600, Cornell III, Howard M wrote: > But encode the time so that it can be read forward or backward. You dont have to, because you know what direction its being read in from the saw. An obvious problem is if you jump, then hold the disk and let it turn slowly, it might take a fair turn before the position can be read... 45rpm = 1 1/3 sec per rev assume 2400 baud timcode, 16 bits of timecode info (inc. stop bits etc) = 13.3ms for 2 whole timecode blocks therefore (max) 1/100th of a revolution to pick up the timecode position = 1" at the edge of a 12" record. min would be 1/2" hmm... that doesn't sound too bad to me, and you may be able to get better than 16bits @ 2400 baud. - Steve

22 years, 11 months

Re: [linux-audio-dev] meterbridge 0.0.4

by Tom

> It doesn't need an extension to the API, you just have to be able to make > input -> input connections. I belive that makes more sense in an abstract > sense (eqivalent to wiring it that way in hardware) and internaly (reduced > complexity). This will work if the powers that be agree to allow input -> input connections. If not, there is another way. In a hardware mixer, many-to-one connections always require a bus, which is nothing more than a unity gain summing node. Since jack performs unity gain summing for a many-to-one connection, then the buffer that the sum is written to could be redefined as a bus. Then any client could read from the output port of this bus. I am not necessarily in favor of this, nor am I against it. I don't know enough about coding to have an opinion either way. What I do know is that this approach preserves the output -> input semantics. Tom

22 years, 11 months

RE: [linux-audio-dev] Final Scratch, custom kernel?

by Cornell III, Howard M

But encode the time so that it can be read forward or backward. -----Original Message----- From: Steve Harris [mailto:S.W.Harris@ecs.soton.ac.uk] Sent: Tuesday, October 08, 2002 2:52 AM To: linux-audio-dev(a)music.columbia.edu Cc: Paul Winkler Subject: Re: [linux-audio-dev] Final Scratch, custom kernel? On Mon, Oct 07, 2002 at 02:33:54 -0700, Paul Winkler wrote: > Encoding stereo to an LP is no problem - the needle vibrates along > two axes. There's a limit to how much stereo separation you can > get (I forget, it might be like 40-45 dB) but that shouldn't be > too hard to account for. OK, but as long as there are no other restrictions on the channels it should be no problem, something like a saw on one side (to detect speed and corresponding carrier wave speed), and an AM modulated timecode signal on the other. Use the say to calculate the carrier wave for the 2nd channel, then decode the timecode. - Steve

22 years, 11 months

[linux-audio-dev] Tk Ecasound 0.6.0 Released!

by Luis Pablo Gasparotto

Tk Ecasound 0.6.0 was released! Dowload it: http://www.sourceforge.net/projects/tkeca Changes: - Options button works . Allows to edit ecasoundrc file - Entry for selecting current directory - Bug fixes on "Save as" button, open file where there was an existing project, play with choosing a different device (<> /dev/dspN) - Autodetect external audio editor and ladspa directory - Visual changes in effect windows Regards, Luis Pablo Cobertura especial de la Copa Mundial de la FIFA Corea-Jap�n 2002, s�lo en Yahoo! Deportes: http://ar.sports.yahoo.com/fifaworldcup/

22 years, 11 months

Re: [linux-audio-dev] Final Scratch, custom kernel?

by robbins jacob

Interestingly enough, the FinalScratch system does not allow cueing to different positions in the record by lifting the needle up off the record. I saw Richie Hawtin playing on one in DC and I didn't realize what it was at first. I was really perplexed because it seemed like everytime I looked up he was just at the beginning of a record: the tonearm was always very far out towards the edge of the record. Then I figured out that he was using final scratch because he was picking the tracks from a laptop nearby running a program that was basically two lists of tracks. I didn't even think the position signal was running through the audio, I thought they had a separate system magnetically measuring the record position. But it must be something like the saw tooth signal described in this discussion. I wouldn't worry too much about using the cueing of the needle on the record to move through the track. It's more useful on a real record because different sections of a track actually are visible to the naked eye on black vinyl, which jogs your memory into remembering the layout of the track. The final scratch record must have a single loop out at the edge of the record. Such a loop is called a locked-groove when put on a real record: certain styles of dance music have a convenient bpm that allows putting a complete 4 bar pattern into one seamless loop towards the end of the record (the middle). I've only encountered this in techno tracks. There can be a complete track which ends by moving into the lock groove which plays endlessly until the dj stops the record. The beat must perfectly fit one rotation of the record in the lockgroove or else the rhythm will be broken. The same constriction applies to making a lock groove of a control signal. I am convinced final scratch records have a few locked grooves of a control signal at the edge of the record. Adding positional cueing would be a nice feature but consider some of the following circumstances: -you have to put a lock groove at the end of the spiral groove anyway or else you limit the length of track that you can control to some arbitrary amount of time. -if you try to get around this by making a 30 minute track you'll find that the groove is cut smaller so that the record will wear faster and will skip much easier when you scratch it. This is why dance singles have one 6-10 minute track cut on the entire side of a 12" record; record wear is a factor for a dj playing a track many times and bigger grooves hold up longer to repeated playing. They will also sound better longer which is not really an issue here. records tend to wear by pushing towards the outside of the groove from centripedal acceleration. -if you make a 10 minute position-coded section leading into a lock groove you will have to have the standard width of the 10 minute section map to the length of the entire track being played. This means that moving the needle to the middle amounts to saying "move 50% of the way through the track" (which is pretty useful). But it's probably going to end up being easier to cue through the software. Hell it will be easier to do everything through the software. The only advantage I see a turntable controller having is for scratching effects and for dj's who don't want to carry a lot of records. And maybe for beatmatching audio files but programs are leaning towards doing that ahead of time (GDAM). As such I wouldn't worry too much about the positional thing, in favor of getting very tight velocity response for scratching and beatmatching. 8 ms will kill you in beatmatching and final scratch has to have closer than 8 ms "grip" on the audio file being controlled. ~4 ms off is audible phasing. I think it's very interesting to investigate it but it might be easier to just cut a lock-groove control signal and not bother about encoding digital signals on a record. ---jacob robbins;;;;;;;;; _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com

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