Linux-audio-dev September 2005

linux-audio-dev@lists.linuxaudio.org

57 participants
56 discussions

[linux-audio-dev] The Erik travelling roadshow

by Erik de Castro Lopo

Hi all, I'm just about to go on holidays with my family. While I'm away I will have a little time here and there to meet up with some friendly linux audio types. I'm be in the following places on the following dates: London UK 2-16 Oct Newcastle UK 16-19 Oct Copenhagen DK 19-26 Oct Anyone who would like to meet up for coffee or a beer or something should email me at erikd AT my usual domain name. I'm up for a chat or being dragged along to a Linux user group type function. Cheers, Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?" -- Tom Cargill

19 years, 3 months

Re: [linux-audio-dev] libcui - design-question

by Kjetil Svalastog Matheussen

Tim Goetze: >>>breathe deeply. think of snakes. say "python". >> >>Are you serious? Do you know python? I hope not... >> >>I don`t want to start a flame-war over programming languages, >>but I know both scheme and python very well, and would >>never consider python as an extension language again. > >Would you care to back up this judgment by a few facts? No, I don't. I don't want to start a flame-war... I just say I know both languages very well. Its hard to explain (but not impossible though) why scheme is a better language. If you had known lisp well, you had probably known what I ment. >One has to consider that a scripting extension for an application like >ardour, with an intended audience of little to no programming >knowledge, will have to be as painless and intuitive to learn and use >as possible and still provide power and freedom of expression to the >savvy. In my opinion, scheme is such a language. It takes some time to learn if you are not used to s-expressions though. --

19 years, 3 months

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

by capnlinux＠handsonarabians.com

There was a question about what kind of accuracy would be required. Well, the more the better. Without electronic assistance this was done by letting the clock run for a day and measuring it against a known good time source, adjusting the pendulum, repeat. Running the clock for longer periods between measurements obviously makes the adjustment more accurate. With electronic assistance the same rules apply. Running the clock longer between measurements makes the adjustment more accurate. Let's do some math. Assuming we use one pendulum cycle to measure the period and say that this clock is geared for a one second pendulum cycle. If we can measure that one second with an accuracy of 100ths of a second, then our average error will be half that or 0.005 sec / sec or 0.3 sec / min or 0.3 min / hr or 7.2 min / day or 216 minutes over 30 days If this is a 31 day clock, over 3 hours off is not very good per winding. If I can get millisecond accuracy, then I'm down to 21.6 minutes over 30 days which is still not very good. Now if I increase my sample size to 10 pendulum cycles and still maintain millisecond accuracy, I can set the clock within 2.16 minutes lost/gained in 30 days. That would be a good start. It would only take me 10 seconds to decide to adjust the clock slower or faster and I would eventually be correct to within .072 minutes per day when I finished adjusting to the accuracy level of this instrument. Further adjustments using longer sample times would then be able to increase the accuracy to the desired level or at least to whatever level of accuracy the clock works are capable of. Returning to one of my original questions. Does anyone have any suggestions for useful libraries or example source code to study as a start for this project? ----- End forwarded message -----

19 years, 3 months

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

by Dmitry Baikov

Hello! I'm in the process of choosing mobile audio interface for both live sets and studio recording. I need minimal possible latency and 8x8 analog I/O. The two from Edirol - FA-101 ($680) and UA-101($600) look promising, but I'd like to hear about personal experience. UA-101 is an USB 2.0 interface. AFAIU it imposes 1ms buffers, and 3 buffers setup in jackd. So, it should give 3ms minimal latency (but at 48 & 96 kHz only). Is it possible in practice? And for what number of channels? Also, is FW much better than USB2 and why? As for FW solution, FreeBob project's site states FA-101 works, but I'd like to know about minimal possible latency. And does it have any restrictions on buffers/frequency setup? As for RME Multiface ($700) + Cardbus ($390) (for notebook) + PCI ($300) (for desktop), it's much more expensive solution, and AFAIK it's hard to find notebook with appropriate PCMCIA controller to get 64-sample (minimal) buffers to work reliable. If there are better options, I'd like to hear about them also. Thank you. Best regards, Dmitry. P.S. Prices are for Russia, where I live.

19 years, 3 months

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

by Dmitry S. Baikov

Many good opinions on RME... Another question about Multiface. Does it make sense to go cheap and buy CardBus->PCI controller and use RME CardBus on both desktop and laptop instead of additional RME PCI controller? Will this work? Yes, it's an additional bridge, but laptops have it anyway and it does not hurt performace... Still no FA-101 facts... Is anyone using it? Or only FreeBob developers are brave enough? :) Okay, any FireWire solution exerience will help. Please! Thank you. Dmitry.

19 years, 3 months

[linux-audio-dev] Re: [linux-audio-user] latency: video card contribution

by Dmitry S. Baikov

> Shared memory is not the highest performance alternative in any > operating system. When the video memory is part of system memory then > the processor the video controller fight for memory bandwidth. This > slows both down. > >> >> So, the question is: what to choose, integrated intel solution or >> ati/nvidia one (in this case, nvidia is preferred, because of driver >> quality). >> > > Choose a good controller with a bit of dedicated video memory. For > purely audio apps you don't need all that much, but if you're going to > run video apps or do multimedia stuff then you'll want more. > It's hard to find light laptop with dedicated controller at a reasonable price :) Is it possible to do 8in/8out and 64-sample buffers with RME Multiface CardBus on a laptop with shared video memory? And the only one(and expensive one) I found is with nvidia controller (Sony Vaio VGN-S480). Not sure about nv TurboCache - is it a shared memory solution? Seems i want too much to be in one unit.

19 years, 3 months

[linux-audio-dev] Re: [linux-audio-user] latency: video card contribution

by Dmitry S. Baikov

> I just sold mine on Ebay this morning. (At least I think it wasn't > shared memory. Hardly remember anymore. Anyway, it's gone...) It's not that easy to get anything to Russia :) > >> Is it possible to do 8in/8out and 64-sample buffers with RME Multiface >> CardBus on a laptop with shared video memory? > > Depends on the laptop but possibly. Why so stringent about 64/2? Do > you _really_ require sub-3mS? > Processing live inputs better be done with lowest latency. Since 64/2 is only a part of total latency, increasing this value is noticable. Especially when playing guitar. > > Possibly, but even shared memory probably won't kill you if you're > just running Ardour, etc. > I hope it will not kill me for running some live processing stuff - SooperLooper, Jack-rack, etc.

19 years, 3 months

[linux-audio-dev] Re: [linux-audio-user] Alsa issues

by Garett Shulman

Hey Terrance, The fact that you don't see anything in /proc/asound suggests to me that there are no alsa modules loaded in your kernel. What output do you get from lsmod? Maybe you could also attach the kernel config that was used to build your currently running kernel. If you are using the kernel that came with your distro this should be /boot/config... If you built your own kernel this should be /usr/src/linux/.config. Here is the alsa card matrix for cirrus logic (I believe that this is the manufacturer of Crystal Soundfusion chips). There are a few different cards here. You may be able to find your particular varity by checking out the output from lspci or by checking the manufacturer of your laptops web site. I suspect that your screen reader is using oss and that the alsaconf utility modified /dev/dsp and this is why it's not working now. I think that the first thing to do is confirm that alsa is not loaded by checking out lsmod. The second thing to do is setup alsa drivers if they are not setup. The driver, lib, & util can be downloaded from alsa-project.org. If you can't determine the exact model of chip you can just compile all of the chips listed on the below link. There are installation instructions on that page if you follow the chipset links. Also, If you have the oss drivers for that chip loaded they will need to be unloaded with rmmod. Let me know if any of this is confusing. Also, if anyone else on the list thinks I am leading Terrence down the wrong path please speak up. -Garett http://www.alsa-project.org/alsa-doc/index.php?vendor=vendor-Cirrus_Logic Terrence van Ettinger wrote: >Hi, Garrett, > The screen reader boots up just fine, without any errors. The >sound card is a Crystal Soundfusion; I'm not sure what the version is or >anything. Doing ls /proc/asound? only tells me there's no such >file or directory, and there isn't an /etc/asound.conf file. > >Thanks, >Terrence >the sound card, I don't know what variety it is, unfo > >

19 years, 3 months

[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, 3 months

[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, 3 months

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 September 2005