Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

4 participants
7441 discussions

[linux-audio-dev] Setting the Beat of a Clock

by capnlinux＠handsonarabians.com

Both optical sensors and contact mic's are often used for this by the professional calibration tools. I would probably plan on using a contact mic inside the clock case to minimize outside noise interference. It is important to perform final adjustments with the works inside the case and the case carefully leveled in order to get the final accuracy needed, although with large case clocks this isn't always possible without some kind of portable device. One problem with an optical sensor is that it cannot help much with the first step and that is telling the difference between the 'tick' and the 'tock' sound. A clock that is not level or that has the internal linkage to the pendulum off-center will not perform as designed and be very hard to accurately set. Although a simple and inexpensive solution to this is to just use a cheap amplifier available from Radio Shack and use the ear as the calibration tool.

19 years

[linux-audio-dev] Re: [linux-audio-user] External audio interface (edirol FA/UA-101)

by Dmitry Baikov

> thats not a very fair comparison. USB2.0 is the "new USB", FW800 is the > "new FW" :) but FW is also a better protocol, which means its easier to > get close the theoretical maximum than it is with USB. > Fair enough, given USB2.0 and FW400 in most of laptops. And UA-101 is a USB2 device (though, has no driver support yet) Anyway, I'm interested in practical applications, not a theoretical ones. > if you were in the US, i could offer you the best prices on RME gear > (i'm a dealer), but with a european location, thats not likely. > Thank you, Paul. I also know where the linux drivers come from ;) Dmitry.

19 years

[linux-audio-dev] Re: [linux-audio-user] External audio interface (edirol FA/UA-101)

by Paul Davis

On Wed, 2005-09-28 at 17:32 +0400, Dmitry Baikov wrote: > > yes, its much better: vastly higher bandwidth, much faster bus > clock. > > Theoretical(!) numbers are: FW-400 = 400MBits/s, USB2.0 = 480 MBits/s thats not a very fair comparison. USB2.0 is the "new USB", FW800 is the "new FW" :) but FW is also a better protocol, which means its easier to get close the theoretical maximum than it is with USB. > >From reading RME mailing lists, I know there were many problems with > Ricoh controllers (on PCI bursts). And everybody recommends TI. But > most notebooks to choose from have Ricoh controllers. Do you know if i have ENE controllers in my two HP laptops, as do a couple of other people on LAD. there *were* problems with these in the 2.4 kernel series, but they were fixable from user-space *and* are gone in 2.6 (AFAICT). if you were in the US, i could offer you the best prices on RME gear (i'm a dealer), but with a european location, thats not likely. --p

19 years

[linux-audio-dev] Re: [linux-audio-user] External audio interface (edirol FA/UA-101)

by Dmitry Baikov

On 9/28/05, *Paul Davis* <paul(a)linuxaudiosystems.com <mailto:paul@linuxaudiosystems.com>> wrote: > Is it possible in practice? And for what number of channels? Also, is FW > much better than USB2 and why? yes, its much better: vastly higher bandwidth, much faster bus clock. Theoretical(!) numbers are: FW-400 = 400MBits/s, USB2.0 = 480 MBits/s > As for RME Multiface i'm not sure that its that hard anymore. kernel 2.6 seemed to have fixes ... --p As I see, you insist on RME :) Reasonable choice. More expensive, but bullet-proof. From reading RME mailing lists, I know there were many problems with Ricoh controllers (on PCI bursts). And everybody recommends TI. But most notebooks to choose from have Ricoh controllers. Do you know if these problems were solved? According to the list everybody went for Fireface now, so there's no feedback on modern cardbus setups. And even less on linux setups. Questions about FA-101 still remain :) More opinions / experiences are welcome :) Thank you. Dmitry.

19 years

[linux-audio-dev] LinuxSampler bug?

by Julien Claassen

Hi all! I've just recently installed the latest release of linuxsampler (0.3.3?) and I've got a problem. I only use telnet to access LS. If I want to shut the sampler down (really quit the server), it tells me something like: Stopping diskthread... There it just hangs eternally. I have to kill it. It doesn't stop my work and playing, but it is nasty and I suppose not the way it is expected to be. Anyone the same problem, fixes? Kindest regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net - the Linux TextBased Studio guide

19 years

[linux-audio-dev] [ANN] slat 0.4b and a plea for help

by james＠dis-dot-dat.net

Slat Sounds Like A Theremin Slat 0.4b is up now. It no longer requires ClanLib and the images get installed properly with make install. The "b for beta" is there because I've had to leave out the extra cursor - the one that shows the rotating point. I'm pretty new to X/imlib programming, and I've run into problems using imlib_paste_image. More detail is at http://blog.dis-dot-dat.net/2005/09/slat-without-clanlib-kde-without.html There's a commented line that kind of puts the cursor back, but it behaves strangely. Everything works without it, so Slat should be perfectly usable. If anyone has a clue about this, or can spare a few minutes to see if the same thing happens to them with the extra line in place, I'd be grateful. James -- "I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you." (By Vance Petree, Virginia Power)

19 years

[linux-audio-dev] Real time delay tutorials?

by Iain Duncan

Anyone have a good suggestion for a tutorial for making accurate high-resolution high-priority clocks in C? I found some tutorials but they were kinda old, so wondered if they might be out of date as to how far real-time scheduling has come on linux. I want to be able to wake up a pthread very accurately. Thanks Iain

19 years

[linux-audio-dev] Setting the Beat of a Clock

by CapnLinux

I would like to build an application to assist in setting the "Beat" of a pendulum type clock. This is a tool used by a clock repair person to set a clock to keep accurate time. It is basically a low frequency oscilloscope with some specialized functionality. A microphone is placed inside the clock case and attached to the mic input of the sound card. I want to have a display of the resulting tick and tock waveforms. There are two primary functions that are needed to accurately set a clock's beat. One is to be able to compare the tick waveform to the tock waveform. A clock that is off balance and hence off beat will have a difference in the sound of the tick and the tock. Tick being the pendulum swinging in one direction vs the tock being the opposite direction swing. The other function is to measure the time between the tick and the next tick or full cycle of the pendulum swing. For instance, a lot of pendulum clocks are set to have a pendulum cycle time of exactly one second. Measuring this to say, hundredths of a second allows for accurate adjustment of the clock. I am looking for pointers to libraries and sample code that might help me get started with this project. Once completed, it would be released as an Open-Source project for use by any clock repairer that wants it. I have not seen any open-source projects of this type and the commercial units that perform this function cost several hundred dollars.

19 years

[linux-audio-dev] (1) Jack -- busted? (2) jack.udp -- busted? (3) jack-osx -- binary-only?

by Stephen Travis Pope

Helo all, (1) I'm new to jack (but a competent programmer). It appears that the cvs repository is missing the top-level configuration file. Following the instructions from the download page, I do a clean cvs checkout on a Linux machine, cd to the jack directory, and execute ./autogen.sh This fails saying /usr/bin/m4: configure.in: No such file or directory configure.ac: 218: required file `config/ltmain.sh' not found Am I missing something? (2) My actual interest is in looking into the jack-udp protocol, and I tried getting this all to work on a Mac a few days ago and actually got much further, but it looks like file recv.c has problems since it doesn't appear to include any definition if the jackudp_t data type that it tries to declare in the first line of code; i.e., I get, /Users/stp/Code/jack/jack.udp/recv.c:14: error: 'jackudp_t' undeclared (first use in this function) Does jack.udp work in general? Is there any documentation of the actual protocol used? Has anyone thought of using TCP instead of UDP? (3) I know that there's a binary distribution of the Mac OSX release, and have it installed; does anyone know where there's a source distribution? stp ...any assistance greatly appreciated... -- Stephen Travis Pope -- http://create.ucsb.edu/~stp Center for Research in Electronic Art Technology, University of California, Santa Barbara Really—I don't know what the meaning or purpose of life is. But it looks exactly as if something were meant by it. — C. G. Jung

19 years

Re: [linux-audio-dev] Re: [Jackit-devel] (1) Jack -- busted? (2) jack.udp -- busted? (3) jack-osx -- binary-only?

by Robert Jonsson

Hi, On Sunday 25 Sep 2005 05:43, Stephen Travis Pope wrote: > Netjack sounds interesting, but the SourceForge site has no code and > no forum postings. > Perhaps this is a case of starting a project by claiming the spot on > SourceForge... The code is there, but it's only in cvs, there are unfortunately no releases made on that site yet (says a little about the lack of maturity). As for the technical merits I see that the discussion has been more about the transport mechanism and this project hasn't really touched on that subject yet. To keep it simple the data is sent via udp with floats directly. For lowlatency, CPU-hungry, work the interesting bit is that there is a master jack-server that drive all slave jack-servers, thus working around the sync issues. A drawback of this is that its only (easily) allowed to connect an actual soundcard to the master jack-server, the others are best suited for various processing tasks (Outboard effects, softsynths). Regards, Robert > > stp > > -- > Stephen Travis Pope -- http://create.ucsb.edu/~stp > Center for Research in Electronic Art Technology, University of > California, Santa Barbara > Really—I don't know what the meaning or purpose of life is. > But it looks exactly as if something were meant by it. — C. > G. Jung > > Begin forwarded message: > > From: Robert Jonsson <rj(a)spamatica.se> > > Date: September 23, 2005 1:23:28 PM PDT > > To: linux-audio-dev(a)music.columbia.edu > > Cc: Stephen Travis Pope <stp(a)create.ucsb.edu>, jackit- > > devel(a)lists.sourceforge.net > > Subject: Re: [linux-audio-dev] Re: [Jackit-devel] (1) Jack -- > > busted? (2) jack.udp -- busted? (3) jack-osx -- binary-only? > > > > > > Hi, > > > > On Friday 23 Sep 2005 21:35, Eric Dantan Rzewnicki wrote: > >> On Fri, Sep 23, 2005 at 12:10:15PM -0700, Stephen Travis Pope wrote: > >>> (2) My actual interest is in looking into the jack-udp protocol, and > >>> I tried getting this all to work on a Mac a few days ago and > >>> actually > >>> got much further, but it looks like file recv.c has problems > >>> since it > >>> doesn't appear to include any definition if the jackudp_t data type > >>> that it tries to declare in the first line of code; i.e., I get, > >>> > >>> /Users/stp/Code/jack/jack.udp/recv.c:14: error: 'jackudp_t' > >>> undeclared (first use in this function) > >>> > >>> Does jack.udp work in general? > >>> Is there any documentation of the actual protocol used? > >>> Has anyone thought of using TCP instead of UDP? > >> > >> Alban Peignier uses Rivendell with jack for radio broadcasts. As I > >> understand it he uses jack.udp to send the audio from the > >> broadcast box > >> to a separate box that does encoding for web streaming. So, there > >> is at > >> least one working use case. > > > > Distributing jack interests me, but sadly I have no time to dive > > deeper at the > > moment. > > Jackudp had a sibling called udpsync (not sure about the source > > heritage) > > which, instead of connecting two jacks through the client-interface > > (which is > > prone to sync problems) drives the "slave" through the backend. It > > does > > work, but is by no means finished. > > Don't know if it's of interest, the latest sources are here anyway: > > http://sourceforge.net/projects/netjack > > > > > > Regards, > > Robert > > > > -- > > http://spamatica.se/musicsite/ -- http://spamatica.se/musicsite/

19 years

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