Linux-audio-dev November 2004

linux-audio-dev@lists.linuxaudio.org

95 participants
87 discussions

by Tim Goetze

The CAPS Audio Plugin Suite reincarnates as caps 0.2.0. * By popular demand, a 'true stereo' version of the Plate reverb plugin makes its appearance in this edition, so the numerous original Plate fans can get their favourite thing to play nice with hosts having trouble dealing with mono-in, stereo-out effects. * Both versions of the Plate reverb sport revised 'bandwidth' and 'damping' knobs. The 'log' hint set on the damping control caused the unit to be virtually useless on hosts having trouble handling the hint combined with the range of the parameter. The revised code eliminates this hint and maps the now linear parameter directly to the respective filter cutoff, at an extra cost of about 200 processor cycles per audio cycle. * The Preamp plugins as well as the Amp units in this edition feature Renormal Technology (!tm), so ab-normal CPU usage due to de-normals in hosts choosing to route perfectly silent audio through these plugins should be a thing of the past. * The all-new AmpIV plugin features complete tube amplifier circuit emulation including a 4-band tone control set. Get your copy before they are all gone: http://quitte.de/dsp/caps.html http://quitte.de/dsp/caps.html#Download Please forward as you see fit. Cheers, Tim

19 years, 9 months

[linux-audio-dev] Re: Been to the movies lately, FreeBob?

by Daniel Wagner

> > For the record: Pieter Palmers has written (in a tremendous effort) a > > large part of AV/C descriptors parser. This part is still not > > completed and needs some clean up, though a great job! Meanwhile, I > > have been working on the basic framework (design and implementation). > > Ok, would this make a good addition to libavc1394? Pieter Palmers and Girish Wadhwani are planing/wokring to incorporate the generic parts of the parser into libavc1394. > Yeah, I read about these proprietary protocols from links off your blog, > but I can't help but believe they are probably just some variant of the > IEC 61883 AMDTP protocol and can be likely figured out -- at least for > the core functionality. However, I do not have a device to know for > sure. Probably special register addresses and value formats are used for > proprietary controls - not so easy to figure out. For the time being, we will concentrate on the devices which are standard complient. The M-Audio device will be considered later. daniel

19 years, 9 months

[linux-audio-dev] can-t access LAC 2004 recordings

by Julien Claassen

Hi! When I try to enter the upload directory (or subdirs), I get a 403. I used the link on the website and tried it directly by accessing: http://linuxaudiodev.org/contrib/zkm_meeting_2004/ or http://linuxaudiodev.org/contrib/zkm_meeting_2004/recordings Any idea, why this is happening? 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, 9 months

[linux-audio-dev] Been to the movies lately, FreeBob?

by Jan Weil

Greetings, today Dan Dennedy (dan-AT-dennedy.org), lead developer of Kino, happened to stumble on the Linux Audio Blog. He left a few comments especially relevant to the ongoing 1394 discussion: <http://linuxaudioblog.jawebada.de/software/alsa/firewire-alsa-driver-at-sf-…> <http://linuxaudioblog.jawebada.de/kernel/firewire-eventually-to-be-supporte…> <http://linuxaudioblog.jawebada.de/music/gilberto-gil-jumping-on-the-linux-b…> Dan on the web: <http://www.dennedy.org/> Kino: <http://kino.schirmacher.de> P.S. Daniel, I hope you don't mind me CCing you. I think this is mainly addressed to the FreeBob team. -- Jan Weil http://linuxaudioblog.jawebada.de

19 years, 9 months

Re: Behringer [was Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more]

by Frank Barknecht

Hallo, Mark Knecht hat gesagt: // Mark Knecht wrote: > On Sun, 28 Nov 2004 22:09:17 +0100, Frank Barknecht <fbar(a)footils.org> wrote: > <SNIP> > > > > Nobody can steal free software, because they already own it. (As long > > as they follow the rules as stated in the GPL etc.) > > This is so patently untrue I cannot imagine how you got here. > > GPL == GP License > > Nothing under GPL is 'owned' by me. It is 'licensed'. I didn't create > it so I don't have any rights other than those granted me. If you own > something you can do anything you want with it simply because you own > it. If it is licensed you must follow the terms of the license > specifcally because the real owner only grants you the rights in the > license. Well, that's what I wrote: As long as you follow the license, you can do everything you want with it. The free software licenses are designed in a way, that you can do everything, that does not try to take away the right to do everything with the software from other users. Even the original "owner", the autor of the software, cannot take away these rights once he released a piece of code under a libre license. In this way he is as much an "owner" as you are. (He is more "owner" in the case that he wants to double license his code under a non-free licens, but then this piece of code is not free software anymore. He still cannot take back the code he already had set free.) I am not strictly talking "law" here. But e.g. the FSF is working on freeing software from owners (Why Software Should Not Have Owners, [1]) by giving authors the same rights as users (and thus making them "owners", too, in a way) [1] http://www.fsf.org/philosophy/why-free.html Ciao -- Frank Barknecht _ ______footils.org__

19 years, 9 months

Re: why open source drivers [was Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more]

by Marek Peteraj

On Mon, 2004-11-29 at 01:32, Mark Knecht wrote: > On Mon, 29 Nov 2004 03:19:14 +0100, Marek Peteraj <marpet(a)naex.sk> wrote: > > > > > ???? RME never 'supported' the card under Linux. The 'supported' the > > > developers by providing technical info. I did not purchase the card > > > because of RME telling me it would be OK to use the card under Linux. > > > They never stated such things. > > > > Unfortunately they did. To quote a part of their response: > > "> [linux-audio-dev] RME is no more > > > > Complete BS. We have and will support Linux/Alsa as before. The only > > excluded product is the Fireface." > > > > Marek > > Well, I don't know exactly what you're calling BS No no you don't understand, i was quoting RME. I had a discussion with them on their forum. Marek

19 years, 9 months

Re: why open source drivers [was Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more]

by Marek Peteraj

On Mon, 2004-11-29 at 00:58, Mark Knecht wrote: > On Mon, 29 Nov 2004 02:25:09 +0100, Marek Peteraj <marpet(a)naex.sk> wrote: > > On Sun, 2004-11-28 at 21:31, Mark Knecht wrote: > > > > > One nice example. Korg 1212 i/o, worked under win98, doesn't under winXP > > because korg does not provide support for it. There is an alsa driver > > for it now(and specs), so basically the life of that card is extended to > > eternity. > > > > There are more such damn good reasons for open source drivers. People > > just don't shout too loud. :) > > Fair enough. There are companies here in Silicon Valley that take over > 'end of life' chip designs and manufacturer them for a while to help > customers, but there isn't much money in it most of the time, just as > there is probably no financial reason for Korg to support that card. I > didn't like it when DigiDesign said they weren't going to continue to > support the 001 forever and I was forced into buying an 002 or going > away from Windows. Unortunately there was no other platform that > maintained my music investment as well so I stuck with Digi. > > That's the nature of technology. It gets outdated. Not too many > companies making buggy whips anymore either... > > >> However how did Marek end up being an RME customer when > > > there was (as far as I know) never any support for this device under > > > Linux, nor anyone even really saying there would be? > > > > Actually not quite, it seemed as if there would be support, Thomas > > wanted to do the driver. I just invested too much trust in RME. My > > fault. > > And I am very sorry about that. You don't have to be. > It is a disappointment I'm sure. > You're a long ways away. If it was more practical I'd probably buy the > unit from you. I have uses. I'm sure others will too. You'll sell it > and get good money. Chalk the loss up to learning and > remember..."Trust, but verify". Agreed. It was a lesson to learn. Thanks for your 'heads up' :) > > > > > > In my case I Was > > > told that supporting the HDSP 9652 would be a non-issue based on the > > > DigiFace working. It turned out to be true, but then again it took > > > about a year to become really useful to me, and even today doesn't > > > work as well as it does under Windows. How did he end up with this > > > device and in this position? > > > > > > I somehow don't think this is RME's fault... > > > > If RME did the drivers for your HDSP 9652 then you could directly > > contact them and ask them for support. I'm sure Thomas would help you > > aswell if he had the card, and that's the problem. In such case claiming > > that they do support alsa is just plain unfair. > > ???? RME never 'supported' the card under Linux. The 'supported' the > developers by providing technical info. I did not purchase the card > because of RME telling me it would be OK to use the card under Linux. > They never stated such things. Unfortunately they did. To quote a part of their response: "> [linux-audio-dev] RME is no more Complete BS. We have and will support Linux/Alsa as before. The only excluded product is the Fireface." Marek

19 years, 9 months

Re: why open source drivers [was Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more]

by Marek Peteraj

On Sun, 2004-11-28 at 21:31, Mark Knecht wrote: > On Sun, 28 Nov 2004 15:20:33 -0500, Lee Revell <rlrevell(a)joe-job.com> wrote: > > On Sun, 2004-11-28 at 12:06 -0800, Mark Knecht wrote: > > > > > > > > Fine with me. If I shelled out for RME hardware I better be able to > > > > call RME for support, same as on any other OS. You get what you pay > > > > for, right? > > > > > > Sure, but when you buy it and the box says 'Requires Mac OS X or > > > Windows XP' then as a buyer I have to respect that. I cannot expect > > > them to support Linux when it wasn't advertised that it works on > > > Linux. RME has given me GREAT support under Windows and I expect that > > > this will not change. They are a great company. I own two cards and > > > wouldn't hesitate to buy another if I was going to set up another > > > Windows box. > > > > Yeah, I was referring to an Nvidia like scenario, where they don't > > release open drivers, but release closed Linux drivers of comparable > > quality and the same support as the Windows driver. > > Sure, I get it. However I think you and plug in a close source RME > card driver and happily use it if it was available. I think Marek, > Frank and others do not feel this way. I had no second thoughts about > putting an NVidia controller in my dad's Linux box even though I used > ATI up until then. My experience using both is no that different, but > for me it's not political. > > Am I wrong when I think this desire is particularly European in > nature? I'm so Open Market driven, especially when it comes to > technology, that I hardly seem to understand this oter POV. However, I > am interested. One nice example. Korg 1212 i/o, worked under win98, doesn't under winXP because korg does not provide support for it. There is an alsa driver for it now(and specs), so basically the life of that card is extended to eternity. There are more such damn good reasons for open source drivers. People just don't shout too loud. :) > > > > > Of course I would be pretty annoyed if they just drop Linux completely, > > for the same reasons as others in this thread - they have a relationship > > with the community at this point. But I don't think they would be that > > stupid. After all pissing off hundreds of potential customers is just > > as bad an idea as giving valuable IP to the competition. > > > > Darn straight. However how did Marek end up being an RME customer when > there was (as far as I know) never any support for this device under > Linux, nor anyone even really saying there would be? Actually not quite, it seemed as if there would be support, Thomas wanted to do the driver. I just invested too much trust in RME. My fault. > In my case I Was > told that supporting the HDSP 9652 would be a non-issue based on the > DigiFace working. It turned out to be true, but then again it took > about a year to become really useful to me, and even today doesn't > work as well as it does under Windows. How did he end up with this > device and in this position? > > I somehow don't think this is RME's fault... If RME did the drivers for your HDSP 9652 then you could directly contact them and ask them for support. I'm sure Thomas would help you aswell if he had the card, and that's the problem. In such case claiming that they do support alsa is just plain unfair. Marek

19 years, 9 months

[linux-audio-dev] Tastes like chicken!

by John Check

I haven't posted anything in a while, but I'm sure some of you remember I made a few claims over the summer. Fear not, things are moving along. Anyhoo, I had a spark of inspiration and banged out a little sort of folk tune tracked with ardour. Audacity as a front end for LAME. Still getting my ears calibrated to a subpar monitoring system so forgive the buried vox and any tubbyness. 4 tracks. 1 scratch guitar & vocal (the limiting factor) 1 bassline 1 vox overdub 1 keyboard http://65.125.227.61 click the title header for a link l8r J

19 years, 9 months

[linux-audio-dev] Open firewire audio interface: A back-of-an-envelope prototype plan

by Simon Jenkins

Hi all: I've been thinking some more about a prototyping/development board (not a production board) for a free open multi-channel firewire audio interface. The objective would be to keep initial development time and costs down even at the expense of pushing component costs slightly up. Here are my very rough, version 0, not-fully-thought-out thoughts: ~ Use off-the-shelf asics for the firewire link and physical layers ~ Use a small-ish xilinx spartan 3 fpga for the rest of the "signal path" logic ~ Use a microchip dsPIC for everything that's off the "signal path" ~ Leave A/D, DA converters (or dig audio I/O) etc entirely off the board: Just provide headers for adding them on a sub-board later. There's a block diagram here: http://www.sjenkins.pwp.blueyonder.co.uk/fwboard/block01.png Some notes: 1. The smaller spartan 3 fpgas are supported by the free, downloadable ISE WebPACK software. 2. The PCI block in the fpga doesn't need to be that fancy or versatile. It just needs to handle the one TI component fast enough to get data in and out of its FIFOs on time plus the occasional (much less time-critical) interactions between the dsPIC and the link layer. It doesn't need to do this stuff as fast as possible - there's nothing else on the PCI bus to contend the bandwidth - it just needs to do it fast enough. 3. The dsPIC never, ever touches the audio data. The converter interface engine directly handles all transfers between the link-layer fifos and its own buffering. It also directly handles any other time-critical interactions with the link layer. 4. The dsPIC does everything else: It... ~ stores and programs the fpga configuration data ~ performs all non-time-critical interactions with the link layer and, via the link layer, with the driver. ~ initialises the converter interface engine ready for whatever formats of audio I/O may be about to start ~ stores user configuration data ~ handles any LEDS, switches, pots, encoders, LCDs or whatever might go on an interface front panel. ~ does any non-time-critical control of an analog I/O subboard. (eg if analog monitoring were implemented the dsPIC would do the necessary switching). ~ could handle a first-cut implementation of MIDI, although this might better be migrated to the fpga. Comments? Cheers Simon

19 years, 9 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 November 2004