Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7513 discussions

[linux-audio-dev] Parameter feedback in Rosegarden (and elsewhere)

by Jens M Andreasen

Hi! I have noticed that the midi-mixing-console in Rosegarden is not listening to external events (like knobs on your fancy midi-controller) I also recall that getting the Mx44 to display current parameters from selected patch without going into a loop (midi-update-> widget-update-> midi-update-> ...) was a challenge. Most probably I just tried to do it wrongly :) Should we perhaps do a (shortish) readme on how to get widgets to stay in sync with an associted midi-input-stream? mvh // Jens M Andreasen

19 years, 11 months

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

by Dmitry S. Baikov

> all depends on the definition of "reasonable price". :) I meant light laptop. Better less magic 2.2 kg, where most of light but powerful enough laptops are. Possibly with external CD. And with price around $1500 in Russia. Acer TravelMate 3002 looks good, has fast cpu, but shared video mem. Sony VGN-S480 is cool (nv6200) but $2100. At least it exists. The thing is, I can't afford 2 laptops - a powerful one and a light one. > i can do 26x26, 64 frames/interrupt on my RME digiface cardbus with an > nvidia video > controller. HP Pavilion zd7000 "desktop replacement" > Great! Are you using nvidia binary drivers? Dmitry.

19 years, 11 months

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

by Dmitry S. Baikov

Hello! Another set of questions for experienced Linux Audio Users. Mainly it's related to laptop performace. It seems the choice of video system for modern laptop consists of two main alternatives: 1) dedicated high performance controller (nvidia/ati) with closed source drivers 2) shared memory controller (intel) with open source drivers People on Windows forums (no choice for Apples) prefer dedicated controller (with own video memory) because shared memory video degrades performance and increase latencies (they say, and in windows). I suppose, under Linux the things are different, because minimal possible latency is directly related to interrupt processing: closed source drivers have arbitrary interrupt paths, surely are written to maximise video performance and thus, should play a bad role in latency. Moreover they cannot be fixed. Open source ones at least can be fixed. Or I am completely wrong and shared video memory makes it bad on a hardware side (locking pci bus, for example)? So, the question is: what to choose, integrated intel solution or ati/nvidia one (in this case, nvidia is preferred, because of driver quality). Thank you. Dmitry. P.S. As a target system, imagine laptop with RME Cardbus.

19 years, 11 months

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

by Garett Shulman

It comes with alsa-utils. Terrence wrote: > I don't seem to have aconnect. Where would I find that? > >Thanks, >Terrence > >

19 years, 11 months

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