Linux-audio-user November 2009

linux-audio-user@lists.linuxaudio.org

160 participants
143 discussions

[LAU] Linux Audio Conference 2010

by Marc Groenewegen

Dear Linux Audio developer, user, composer, musician, philosopher and anyone else interested, you are invited to the... Linux Audio Conference 2010 The conference about Open Source Software for music and audio May 1-4 2010 Hogeschool voor de Kunsten Utrecht (HKU) Utrecht, The Netherlands Registration is open, and so is the call for abstracts and papers. More information can be found on the website: http://lac.linuxaudio.org/2010 For previous editions, look here: http://lac.linuxaudio.org For concerts, music and workshops a submission system and protocol will be available soon. In the meantime, ideas and announcements can be sent by e-mail ("lac -at- linuxaudio -dot- org ") or written on the wiki: http://wiki.linuxaudio.org/lac2010 We hope to see you all in Utrecht ! Kind regards on behalf of the LAC team, Marc Groenewegen, lecturer music software design @ HKU

16 years

[LAU] usb and jack

by rosea grammostola

Hi, I found this info: "USB and jack The USB interrupt period is 1 msec. To be able to get lower latency with jack when using it with an USB device, you have to use a setting as 48kHz and 3 period. It will makes the buffer time a multiple of 1 msec and you will get a much lower latency as with the default 2 period. Additionaly, loading the snd-usb-audio with the parameter "nrpacks=1" will give you a much lower latency (for this to work take care that CONFIG_USB_BANDWIDTH is not set and CONFIG_USB_DYNAMIC_MINORS is not set in your running kernel)." http://proaudio.tuxfamily.org/wiki/index.php?title=Howto_RT_Kernel#USB_and_… 1) is this info still up-to-date? 2) how do I exactly take care of this: "Additionaly, loading the snd-usb-audio with the parameter "nrpacks=1" will give you a much lower latency (for this to work take care that CONFIG_USB_BANDWIDTH is not set and CONFIG_USB_DYNAMIC_MINORS is not set in your running kernel)" (Debian (based) systems) \r

16 years, 1 month

[LAU] USB audio interface support?

by Ng Oon-Ee

Hi all, two quick questions (new to this list, let me know if I'm doing this wrong), 1) What's support like on Linux on the USB Audio Interfaces? Specific list below. I guess this is pretty much a 'does alsa support these devices', at the current moment? Obviously this is the primary requirement compared to 2). 2) I've got a Shure SM57 dynamic mic which needs amp-ing to get a useable signal for my laptop. Instead of just getting a pre-amp I was figuring I may as well get a USB audio interface, enabling me to finally use the MIDI output of my Korg as well as record a presumably good signal direct from my SM57. I've seen various complaints on the Fast Track Pro, for example, that the SM57 volume is just too low for quiet recording (ex. recording accoustic guitar), and its been confirmed as an issue by one of their engineers (http://forums.m-audio.com/showthread.php?t=14610). So the second question is, is this a general issue with the SM57 and budget USB audio interfaces, or would one of the list below be better? I'm looking at the following interfaces:- a) M-Audio Fast Track Pro b) Alesis IO|2 Audio/Midi Interface c) Tascam US-144 USB 2.0 Audio and Midi Interface d) Edirol UA-4FX USB Audio/MIDI Interface Please feel free to recommend alternatives with similar feature set (XLR input, 1/4" input, some sort of MIDI is a preferred bonus). Thank you all.

16 years, 2 months

[LAU] MIDI Playback freezes

by Bob van der Poel

Oh no ... I had this problem a few years ago and thought it'd been fixed (forever!). But, since "upgrading" to ubuntu 9.10 I've had a few freezes again. I've got a 24/96 audiophile card which is sending the midi to an external synth. No Jackd, but pulseaudio is running. Stock kernel 2.6.31-14-generic. Now, when I had the problem before I solved it by NOT running the RT to multi-media kernel. This this that isn't the problem.... When the freeze happens it kills the computer completely. I could probably log in via a terminal or network, but haven't tried that. The video does display, but the keyboard/mouse is gone. The only way out is to hit RESET. Ideas???? Big problem is that it happens very occasionally. Last time was several weeks ago. Hopefully, the next time will be a long time in the future! -- **** Listen to my CD at http://www.mellowood.ca/music/cedars **** Bob van der Poel ** Wynndel, British Columbia, CANADA ** EMAIL: bob(a)mellowood.ca WWW: http://www.mellowood.ca

16 years, 2 months

Re: [LAU] status usb2 for sound

by Ivica Ico Bukvic

> > Also, if you need any assistance testing stuff, please let me know and > we'll > > gladly assist in whichever way we can. > > The "lsusb -v" output t for this devices in all seven combinations of the > sample rate and full/high speed modes would be useful. Clemens, Please see attached. Best wishes, Ico

16 years, 2 months

[LAU] (no subject)

by karl＠aspodata.se

linux-audio-dev(a)lists.linuxaudio.org Subject: Re: [LAU] [LAD] FOSS Ethernet Soundcard In-reply-to: <20091129043620.GD18330(a)aieee.restivo.org> References: <20091123221940.GE25107(a)ltw.loris.tv> <BAY137-W27EAA658D096BD60BADDAAA79E0(a)phx.gbl> <20091124093346.7349F801FCEF(a)turkos.aspodata.se> <20091129043620.GD18330(a)aieee.restivo.org> Comments: In-reply-to Ken Restivo <ken(a)restivo.org> message dated "Sat, 28 Nov 2009 20:36:20 -0800." Mime-Version: 1.0 Content-Type: text/plain ken(a)restivo.org: > On Tue, Nov 24, 2009 at 10:33:45AM +0100, Karl Hammar wrote: ... > > My goals is "just" to extend another project (industrial i/o). > > What would your goals be ? ... > The original thread converged on a goal pretty quickly: > an inexpensive, yes, if possible, but not one of my major goals > multi-channel audio interface ack > which is open hardware and software, amen > and uses Gig Ethernet as its physical connection method. a 200MHz processor (as in my project) cannot possible drive a gigabit ethernet, if someone has a better choise of processor, please speak up > So, if I were going to put the goal simply: > I'd like a Focusrite Saffire (or equivalent) that runs over > Ethernet, please :-) > Price-wise, it'd be nice if it cost the same or less than > equivalent USB 2.0 product. > Latency-wise, comparable with USB 2.0. Can you summarize theese in more technical terms. > In terms of how many I/O, I think that was still being calculated > and experimentation was going to be required. Obviously options for > 4, 8, or 16 I/O would be nice. Ok. To be honest with you all, for me, this is not about to compete with products on the market or to sale and market a product. This is to do something, hopefully; together with (hopefully) other fellow hw and sw hackers. To make it so, I'd like the construction to be sufficiently simply so that a large enought share of hw hackers can make the thing themself. In technical terms, I'll restrict myself to double layer pcb's and non-BGA chips. That does not mean that the design or the specification has to be of low quality. Low price would be nice but is not a goal at this point. Regards, /Karl ----------------------------------------------------------------------- Karl Hammar Aspö Data karl(a)aspodata.se Lilla Aspö 148 Networks S-742 94 Östhammar +46 173 140 57 Computers Sweden +46 70 511 97 84 Consulting -----------------------------------------------------------------------

16 years, 3 months

[LAU] composing for video

by Atte André Jensen

Hi A friend of mine has invited me to compose for some videos he's planning on making. We haven't started yet, but I thought it might be good to be a bit ahead, especially since I haven't done this before and I know next to nothing about video... The noise making apps will be running ontop of jack. Google suggest I should look into xjadeo with the -i switch. Is that it? Anything (formats, codecs, framerates, interlaces other-stuff-I-dont-get) that I should ask for or try to avoid? Any input, including links, tips, thoughts, would be highly appreciated! -- Atte http://atte.dk http://modlys.dk

16 years, 3 months

[LAU] logical AND in Faust

by Bjoern Lindig

Hi, I tried to post this to faust-users-list, but since I changed my email-adress this was refused. Now, after spending a week of "awaiting moderator approval", I decided to post my question here, and I hope that some of the faust-guys might be around. I have a problem understanding this piece of faust-code: index( n ) = &( n - 1 ) ~ + ( 1 ); It is from the faust-soft-computing.pdf. I do understand that it works like a counter and I think it should jump back to 0 when it reaches n - 1. But what exactly is the logical AND operator doing? In the quick reference it is sayed, that primitives behave like their C counterpart. O.k. I don't have any experience in C, but I realy tried to figure this out. To me it seemed, that the "&" operator in C would give back the smaller value of the two compared. So in this case it would give pack the line from 0 to n-1 and then continue with streaming n-1. But that would not make any sense if it is used in a delay-line, to calculate the read/write index, does it? Please correct me if I missunderstood something and thank you for help. Kind regards, Bjoern

16 years, 3 months

[LAU] Music made with linux - Den yndigste rose er funden

by Atte André Jensen

Hi Today is 1st sunday of advent, and to celebrate that I uploaded a piece of (not your average) christmas music in the Modlys player: http://music.modlys.dk/track/den-yndigste-rose-er-funden Direct link to mp3 is here: http://modlys.dk/mp3/den_yndigste_rose_er_funden.mp3 Lyrics are from the danish christmas carol "Den yndigste rose er funden" (The lovelies rose has been found), everything else, including new melody, is by me :-) -- Atte http://atte.dk http://modlys.dk

16 years, 3 months

[LAU] LADI

by Nedko Arnaudov

After recent discussion on IRC I'm loosing faith in whether it is worth to contribute to linux audio session handling/management. Two reasons were given why it does not get testing from users. One is that what I did so far is not mature, has annoying bugs and I'm not wanting to fix them. The other one is that ladish is not giving more than users already have with qjackctl. Also it was mentioned that D-Bus is not what users find acceptable for controlling jack server. Given the almost missing feedback about LADI development from community members that could benefit from it, I'm not sure whether I should continue to contribute. Maybe I should give up on trying to make linux audio usable for my needs. I could also stop using computers and make music only by using my guitar. Because alternatives to Linux Audio (windows/mac) don't suit my needs. Moreover they don't have the potential to suit. This is why I'm contributing to Linux Audio and not making VST plugins or something. This anti-dbus movement is getting too far. If there is no user that accepts my point of view, there is no point of me contributing. Because it may be possible that someone has missed the whole point of my jackdbus and session handling effort, I'll try to explain what I find wrong/unacceptable in JACK (dbus-less) system as we have it now. * JACK server tries to kill clients that are suspected to misbehave and cause xruns or expose other kind of bad behaviour. This can result in qjackctl (or patchage for example) being killed. IMO, killing control apps is wrong. Apps that that don't process audio/midi should be treated differently. * When jackd is autolaunched, log messages are going to stdout/stderr of the app that launched them. This is wrong, unix daemons are supposed to have a log file, even if they are per-user. One of the reasons why log file is a good thing to have is that it allows to analyze problem post factum. This helps a lot if some misbehaviour is rarely reproducable. * Control apps that start the jack server through jackd know only about the parameters that were known at compile time. Somewhat recent example, IIRC, jack2 specific parameters (-S) and firewire options missing after upgrade of jack because qjackctl does not know about them. IMO, control apps should be able to query parameters for jack and display the available options to user. * Control apps that manage jack connections, are subject to realtime constraints. IMO, this complicates control apps development for no good reason. This is valid only for jack1. jack2 already uses non-realtime threads for port notifications. * Implementing control app requires C level program or use of specially crafted bindings. It will be good if control apps could be implemented with few lines of code in a scripting language as Python, Ruby, Perl, etc. * JACK graph (clients, ports and connections) API is badly designed and is prone to race conditions. Fons talked about this problem recently too. * Session handling capabilities are suboptimal. Various programs lurk here. I'll mention the two most popular ones: qjackctl cant save/restore internal state of the programs. It also cant save and then relaunch them automatically. lash cannot manage jack settings and cannot restore connections for applications that are not linked against liblash. There are other problems but those are the most frustrating ones. * Hardware port virtualization is suboptimal. it is provided through the JACK "system" client. The only reliable ports are first ones, they are expected to be the main input/output. If applications wants to connect to phones for example it does not know on what ports they are. projects/session should be movable to other system, one with different hardware setup and [extensive] reconnecting should not be required. * Hardware port names are not human readble. Aliases exist but are not widely used for various reasons. Users should be able to name and group their ports to match their hardware cable setup. * JACK "system" client is used for non-hardware ports (-X seq). * There is no global list of JACK enabled applications. * JACK MIDI is not widely accepted. JACK AUDIO + ALSA seq appears to be acceptable solution. IMO, sample accurate audio+midi is very important. * There is no session handling for netjack LAN setups. * Session handling apps cannot restore apps to more than one X11 screen (do not mix with X11 display). * Patchage-like (flowcanvas based) patchbay interface is best what I've seen. Unfortunately Patchage does not integrate well with other parts of JACK infrastructure. As you can see, I have collected enough problems to fight. Almost all of these fixes need new software modules to be written or existing ones to be rewritten. In past years I've tried to collaborate with people behind JACK, LASH, Patchage and Qjackctl. At the end, I think that this attempt was probably wrong, with the only excepton of jack2 (Stephane Letz) who accepted my jackdbus development into jack2 and we worked toghether on improving it and on the more general "control API" initiative. The jackdbus code, my first contribution, that is supposed to improve this mess was rejected by Paul Davis whom maintains jack1. I've got some patches accepted by Patchage`s author and maintainer, Dave Robillard, but they were rather cosmetic ones. This forced me to maintain a software branch (Dave calls it a fork) called lpatchage. It was supposed to be dashboard for the JACK system. I also actively participated in lash-0.6.x development. The only other developper, Juuso Alasuutari, shared some of my ideas, but at the end we ended with fundamental differences about how session handling should behave and what lash should become. As part of my LADI efforts, two people where very helpful. Marc-Olivier Barre and I managed to create pyjackctl, later renamed to laditools. It is set of minimalistic but very useful control apps for JACK, a2jmidid and LASH/ladish. Krzysztof Foltman helped a lot with probably the most complex app in the laditools suite, ladiconf. I'd like to mention people with whom collaboration, even if attempted by me was non-existing: Rui Nuno Capela and Bob Ham. They clearly declared From start that wont help for various reasons and I appreciate this. Because this saved my precious time of part-time contributor to Linux Audio. In May/June this year, Fons Andriaensen got hit by a forcibly packaged jackdbus (i'd call it mispackaging of jack) and started a flame war against D-Bus evilness. I tried to be constructive until I got message From the packager that dbus was forced, even given that he earlier stated that he explicitly enabled dbus support in that package for one reason or another. In June this year, it become evident that I'm not able to contribute to LASH anymore and that I want something else. I left the LASH project and started a new session manager, ladish (project page is at ladish.org). The first preview was released not long after. It was not yet a real session manager but it was able to save and restore multiple jack configs, a foundation for what I call "studio" in ladish. Since then I've implemented some more stuff and I was hoping that next preview that will be able to relaunch applications and restore connections between their jack ports will be ready by the end of this year. In recent few months, I had less time to contribute to ladish and development slowed. The anti-dbus statements from various people continued almost always without real argumentation behind them. For these that were complains about dbus problems in real setups, I've given suggestions. Almost always I got ignorace and more anti-dbus statements in return. Maybe what I did is really unusable by others, despite it being obviously usable by me. Maybe I suck at trying to help & support people who seem to think that ladi is not that bad. Or maybe D-Bus is indeed evil and eats babies and I fail to understand why, even after I've listen to so many "arguments". Or maybe there are happy people using jackdbus and laditools (or even lash-0.6.x) and looking toward ladish. But I dont see them. If community does not share my frustration with problems of the JACK system I mentioned above and does not accept my vision that D-Bus is just the most suitable (but not perfect) technology for what I'm trying to achieve, then it would be better for everybody if I don't contribute anymore. I can detach from the community and I can even detach from linux and even computers. So now is the time to give your positive feedback and constructive critics. Don't troll and don't start another flame war unless your goal is to alienate me to stage of me detaching from this community. I will not respond to trolish and flamish mails, feel free to contact me with private mails if you prefer so. As I'm cross posting this mail, if you are subscribed to more than one of the mailing lists, please reply only to one of them. In order of preference, lad, lau, jack-devel. This should avoid discussions half-shared between lists. If they happen at all. This mail is not supposed to be offensive to anyone. If someone feels so, I declare that offense is not intentional. I don't deny the right of different opinion on any subject and thus I have no reason to burn witches. -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>

16 years, 3 months

Jump to page:

2026

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-user November 2009