Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more
CK wrote: I read: for the record, i sent a mail to rme as well and got exactly the same answer (in german) which i saw before here on this list. I still don't see the point, the GPL _protects_ their IP rights, if I was the evil corporation trying to rip off rme I could aswell rip the thing apart and reverse engineer the code and the protocol, might still be cheaper than doing the rd work. I think their point is another one: There are few companies that used firewire with all it's potential. RME is thinking they are the only ones, that uses all the potential in firewire. If the make a ALSA solution, their competitors have the same basis (that they think of is the best one) ... And since firewire is a very generic protocol they may be right :-(( Is this true, that a firewire driver for one card can be used with equal power for another card? Uwe -- voiceINTERconnect www.voiceinterconnect.de ... smart speech applications from germany
Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more
I read: Is this true, that a firewire driver for one card can be used with equal power for another card? what I was referring to is rather the idea to sell the same hardware with minor modification at very different prices and putting the limitations in the binary only driver (miro dc10 and dc30 as a prime example) regards, x -- [EMAIL PROTECTED] Postmodernism is german romanticism with better http://pilot.fm/special effects. (Jeff Keuss / via ctheory.com)
Re: [linux-audio-dev] impulse convolution LADSPA plugin
Hi Steve, thanks for the reply. I will definitely look into using DSSI, looks like it could be good once as supported as LADSPA is (I'd never even heard of it before your post, although that's probably just me). Is it intended as an eventual LADSPA replacement? I never really saw the need to divide plugins into 'instruments' and 'effects', and it seems like DSSI can do both. Stefan Turner It would be more practical to do it as a DSSI plugin, LADSPA has no way to indicate that you want to load files during runtime, and no UI. In DSSI you can load the impulse in the UI process, perform the FFT on it and send it ot hte DSP code with configure(). Once there the DSP code can the overlap-add/save on it. - Steve ___ Win a castle for NYE with your mates and Yahoo! Messenger http://uk.messenger.yahoo.com
Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more
139Uwe Koloska wrote: CK wrote: I read: for the record, i sent a mail to rme as well and got exactly the same answer (in german) which i saw before here on this list. I still don't see the point, the GPL _protects_ their IP rights, if I was the evil corporation trying to rip off rme I could aswell rip the thing apart and reverse engineer the code and the protocol, might still be cheaper than doing the rd work. I think their point is another one: There are few companies that used firewire with all it's potential. RME is thinking they are the only ones, that uses all the potential in firewire. If the make a ALSA solution, their competitors have the same basis (that they think of is the best one) ... And since firewire is a very generic protocol they may be right :-(( Is this true, that a firewire driver for one card can be used with equal power for another card? I assume that they have developed their own audio/midi transfer protocol, instead of using the 1394TA specs. Remember that firewire behaves pretty much like Ethernet: the data transfer protocol on the bus is pretty wel defined, both electrically as the packetization of the data. Just like voltage levels on an Ethernet bus, and raw ethernet packets are well defined by the ethernet specs. But that's about the point where the actual FireWire standard (IEEE1394ab) stops. The device manufacturer has a lot of freedom on developping their protocols that operate over the firewire bus. On Ethernet ARP, IP, ICMP, ... all use the same ethernet packets, but are different protocols. There is an organisation that has developped specs for how devices of specific categories should communicate over the FireWire bus, named 1394 Trade Association. They define protocols for addressing devices like VCR's, cameras, HD's, and also audio devices. But the use of these standards is entirely voluntary. If you don't use them, you can still conform to the basic IEEE1394 spec. I assume that RME has developped their own protocols, which they don't want to share. And frankly I can understand their point of view, because I think an awfull lot of time (=money) must have been spent to develop an efficient protocol. I don't think the specs they have for their FireFace would be feasable using the 1394TA specs for audio devices (but I can't say this for sure). To answer to your last question: If the device (completely) conforms to the specifications of the 1394TA, and the driver supports the specs completely, then this would be true. The FreeBob driver might evolve to this kind of driver in time, but the 1394TA specs are huge (more that 1000 pages alltogether, only for audio/midi devices). So the current goal for FreeBob is to support only the DM1000/BeBoB based devices that conform to the specs. This allows us to skip the implementation of those parts of the specs that aren't implemented by the DM1000/BeBoB device. The RME story also goes for the firewire interface of M-Audio. They use a DM1000 based platform, so initially we thought the device could be supported by FreeBob. But apparently they modified the reference firmware, making it (possibly) non-conformant to the 1394TA specs. As such these devices cannot be supported by FreeBob directly. Maybe if we have a working driver, we can convince the M-Audio people to share the nescessary info so that we can support their devices also. Greets, Pieter Palmers FreeBob developer
promoting DSSI, was re: [linux-audio-dev] impulse convolution LADSPA plugin
Stefan Turner wrote: I will definitely look into using DSSI, looks like it could be good once as supported as LADSPA is (I'd never even heard of it before your post, although that's probably just me). Is it intended as an eventual LADSPA replacement? I never really saw the need to divide plugins into 'instruments' and 'effects', and it seems like DSSI can do both. If I may chime in here... I urge all Linux audio developers to read the DSSI spec, it's well-written and directly addresses some of LADSPA's shortcomings. After working with VSTi plugins for a while I've begun to see the need for something similar in a native Linux architecture, and I think DSSI is an excellent way for us to get that. If you don't already know about it, you can learn more about DSSI here: http://dssi.sourceforge.net/ Again, if you're a developer, check it out. Some good minds are behind its design, and Linux audio software truly needs DSSI (or something like). Best, dp
Re: [linux-audio-dev] Open firewire audio interface: A back-of-an-envelope prototype plan
somehow a nice idea, i only see one problem: firewire and usb audio devices are mainly used with laptops, whih normaly have only one ethernet port. if you have a desktop, you could also use a pci audio card. what about usb 2.0 audio cards? has firewire any advantage? big disadvantage with firewire for x86 laptops: they mostly have 4 pin firewire port, so always need external power for the firewire audio device. Bob Knight wrote: I want an open ethernet audio device. I do not want or need to deal with pci, firewire, usb. Use one of many controllers out there with a good embedded linux port and build in ethernet. Use a TDM or GPIO type interface for the analog side of the world. TDMoE would work just fine for audio. One thing that linux does well these days is ethernet. I need a minimum of 32 channels for live recording. The idea would be to just suck in the ethernet frames and write them to disk. Then mix them down back in the studio after the show. I am a noop (programmer) with a EE back ground and would glad to help anyone build something like this.
Re: [linux-audio-dev] Open firewire audio interface: A back-of-an-envelope prototype plan
smoerk wrote: somehow a nice idea, i only see one problem: firewire and usb audio devices are mainly used with laptops, whih normaly have only one ethernet port. if you have a desktop, you could also use a pci audio card. A multi port wire speed switch would probably set you back about $20. In a remote recording environment, you probably would not be doing anything else on the lan. The pc is going to be hella busy dumping frames onto disks. what about usb 2.0 audio cards? has firewire any advantage? big disadvantage with firewire for x86 laptops: they mostly have 4 pin firewire port, so always need external power for the firewire audio device. Bob Knight wrote: I want an open ethernet audio device. I do not want or need to deal with pci, firewire, usb. Use one of many controllers out there with a good embedded linux port and build in ethernet. Use a TDM or GPIO type interface for the analog side of the world. TDMoE would work just fine for audio. One thing that linux does well these days is ethernet. I need a minimum of 32 channels for live recording. The idea would be to just suck in the ethernet frames and write them to disk. Then mix them down back in the studio after the show. I am a noop (programmer) with a EE back ground and would glad to help anyone build something like this. -- Bob Knight [-w] the work option [EMAIL PROTECTED] 925-449-9163
Re: promoting DSSI, was re: [linux-audio-dev] impulse convolution LADSPA plugin
On Fri, 2004-11-26 at 09:03 -0500, Dave Phillips wrote: If I may chime in here... I urge all Linux audio developers to read the DSSI spec, it's well-written and directly addresses some of LADSPA's shortcomings. After working with VSTi plugins for a while I've begun to see the need for something similar in a native Linux architecture, and I think DSSI is an excellent way for us to get that. If you don't already know about it, you can learn more about DSSI here: http://dssi.sourceforge.net/ I second that. I love LADSPA and i appreciate its contribution to Linux audio in general, and i'm still using it, but DSSI is better pretty much any way you look at it. Hopefully the authors of LADSPA plugins will start porting their software to DSSI. -- Florin Andrei http://florin.myip.org/
Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more
On Fri, 2004-11-26 at 01:20 +0100, CK wrote: I still don't see the point, the GPL _protects_ their IP rights It only protects the source of the driver. if I was the evil corporation trying to rip off rme I could aswell rip the thing apart and reverse engineer the code and the protocol, might still be cheaper than doing the rd work. You're close. It's most expensive to do your own RD. It's a bit cheaper to reverse engineer the products. It's a lot more cheaper to just grab a GPL'd product and learn from it. That's why companies are wary of releasing GPL drivers. -- Florin Andrei http://florin.myip.org/
Re: [linux-audio-dev] Open firewire audio interface: A back-of-an-envelope prototype plan
Bob Knight wrote: smoerk wrote: somehow a nice idea, i only see one problem: firewire and usb audio devices are mainly used with laptops, whih normaly have only one ethernet port. if you have a desktop, you could also use a pci audio card. A multi port wire speed switch would probably set you back about $20. In a remote recording environment, you probably would not be doing anything else on the lan. The pc is going to be hella busy dumping frames onto disks. i see your point, a MaGIC-like system would be very nice, if you need more than a few meters cable between A/D D/A converters and the computer.
[linux-audio-dev] gibson magic?
btw, is there anyone working on an implementation of gibson's magic for linux? is it even possible?
Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more
On Fri, 2004-11-26 at 19:36, Georg Rudolph wrote: Please, let's not be too harsh. I recently bought the pcmcia based multiface from RME, only because it has linux support, and it works great, on both kernels. Of course, firewire is cooler, but there is this way out. Not for me. :) anyway it seems there a *lot* of linux audio users that bought RME because of alsa support. How about doing a list where everyone can submit his name and type of RME card so that we can see how big and attractive the market currently is? Marek
Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more
I assume that RME has developped their own protocols, which they don't want to share. And frankly I can understand their point of view, because I think an awfull lot of time (=money) must have been spent to develop an efficient protocol. 1. So they haven't invested the a comparable amount of time into Hammerfall series? 2. I can only understand the point of view of open source developers here, since they also invested an awfull lot of time (and money that they didn't get back!) into developing linux audio applications, many of which are state-of-art at least with respect to technology. And they're free as in beer/speech. That said i really don't understand the point of view of those few how actually kindof defend the position of RME (or any other manufacturer in a similar position), no offense intended. The RME story also goes for the firewire interface of M-Audio. They use a DM1000 based platform, so initially we thought the device could be supported by FreeBob. But apparently they modified the reference firmware, making it (possibly) non-conformant to the 1394TA specs. As such these devices cannot be supported by FreeBob directly. Maybe if we have a working driver, we can convince the M-Audio people to share the nescessary info so that we can support their devices also. Which seems like it's the beginning of end for linux pro-audio hw support if we don't fight for it. Right now it concerns just me, but it might concern everyone in the near future. Marek
Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more
On Sat, Nov 27, 2004 at 12:34:17AM +0100, Marek Peteraj wrote: Which seems like it's the beginning of end for linux pro-audio hw support if we don't fight for it. Right now it concerns just me, but it might concern everyone in the near future. How can we fight it? I've been holding off on a firewire interface, but now maybe I just won't get one...
Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more
On Fri, 2004-11-26 at 23:17, Mark Knecht wrote: On Sat, 27 Nov 2004 00:34:17 +0100, Marek Peteraj [EMAIL PROTECTED] wrote: SNIP 2. I can only understand the point of view of open source developers here, since they also invested an awfull lot of time (and money that they didn't get back!) into developing linux audio applications, many of which are state-of-art at least with respect to technology. And they're free as in beer/speech. That was their choice. Right? Sure but the result is the _same_ with respect to what they deliver(state of art technology), which has the same value for me. Not the same with respect to what you get in the end.(a non-functioning device you paid a lot for, just because this and that) That said i really don't understand the point of view of those few how actually kindof defend the position of RME (or any other manufacturer in a similar position), no offense intended. RME's position, and I am only guessing here, is that they would be happy to release info to the Open Source community __IF__ that information didn't help their competitors develop hardware that competed with RME. How? To achieve 1ms less latency? It is natural for people who have spent money to want to protect it's value. We are that way with our own purchases, correct? I (and I think you...) would not be happy if I bought something and then it stopped working, Worse. It actually never worked in my case. or if the company you bought it from stopped supporting it. Worse. They never did in my case. RME is the same way. They invest hundreds of thousands, if not millions of Euro's developing new hardware ideas. Hence the analogy with oss developers. They do that too without being cowards and misers. They create software to support it and make it work. Then all the technical information goes into the public domain and some low cost manufacturer from Taiwan or Russia or somewhere else knocks off a copy and sells it for 1/2 the price. No one buys RME hardware, RME doesn't make money and goes out of business. Did this happen? See how many RME cards are supported. Almost all. Perhaps all except fireface. Did someone from russia or taiwan knock-off a copy? Does RME suffer from us having alsa drivers? Are russian engineers or taiwanese engineers(envy24 btw AFAIK) not smart enough to come up with their own superb design? Is it too hard for smart people to reverse-engineer? In other words - what are you talking about? What's so hard to understand? Pretty much everything. Considering that they have used proprietary protocols in their hammerfall series anyway. Which seems like it's the beginning of end for linux pro-audio hw support if we don't fight for it. Right now it concerns just me, but it might concern everyone in the near future. This I agree with, but the best way to fight for it (speaking as a business man) is to develop a real market for it. We need thousands of buyers. Develop the market and hardware manufacturers will come. Perhaps it's here already. I think there's more of us RME or M-Audio customers than one might think. Marek
Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more
On Fri, 2004-11-26 at 22:48, Tim Hockin wrote: On Sat, Nov 27, 2004 at 12:34:17AM +0100, Marek Peteraj wrote: Which seems like it's the beginning of end for linux pro-audio hw support if we don't fight for it. Right now it concerns just me, but it might concern everyone in the near future. How can we fight it? I've been holding off on a firewire interface, but now maybe I just won't get one... I'm not sure how right now. But i really think there's a lot more of use rme/maudio customers out there than we might actually think. And it's obvious that the numbers will grow. A survey might help us to figure this out.. Marek
Re: [linux-audio-dev] Open firewire audio interface: A back-of-an-envelope prototype plan
Bob Knight wrote: I want an open ethernet audio device. I do not want or need to deal with pci, firewire, usb. Fair enough, and an interesting project, though personally I'm more interested in doing a firewire device. Use one of many controllers out there with a good embedded linux port and build in ethernet. Cirrus do some ARM 9 based SoCs with built-in Ethernet MAC. They run linux given enough flash RAM, but eCos would probably be a better fit RTOS for this application IMO. They've got on-chip AC'97 interface too if someone wants to do a 2-in 2-out design, or to start with one whilst prototyping. Use a TDM or GPIO type interface for the analog side of the world. I was thinking of clocking the data into and out of some D/As and A/Ds, ie solving the problem rather than moving it to the other end of a cable and putting a different connector on it. In case it wasn't clear the Converter Interface Engine on my block diagram is intended to clock data into and out of audio converters. The Dig Audio Interface header takes these signals off the prototyping board to make development cheaper and easier. TDMoE would work just fine for audio. One thing that linux does well these days is ethernet. I need a minimum of 32 channels for live recording. The idea would be to just suck in the ethernet frames and write them to disk. Then mix them down back in the studio after the show. I see now why you ask for something GPIO like: You want to be able to put, say, 4 * 8-channel input modules on it to get exactly the I/O - or just the I in this case - that you require. I am a noop (programmer) with a EE back ground and would glad to help anyone build something like this. OK. I'm employee minority shareholder in a small company doing industrial embedded control h/w and s/w development. I've also worked on multi-channel audio I/O hardware in the past. So I could let myself into work on Sunday and start laying out a board if I wanted to, then I could get it built, then I could get it running. If it was worth the time and money. And if I could spare the time and money. I'm not claiming to know it all though and some help would be required. My FPGA experience is limited and out of date, I've never worked with firewire, I don't do analog circuit design (I can copy them though, and I can do mixed-signal PCB layout) and I've never worked on linux drivers. Part of my motivation here is to get some development experience in some of these areas. I've got relatively little time or money to spare which is why I'm looking for ways to make the initial development phase as quick and as cheap as possible without compromising a finished design. Some cheap early prototypes would also be essential for bringing other people into the s/w and ip development. Hopefully a running prototype would then attract the resources to be developed further. If not then the prototypes would still be pretty neat little FPGA dev prototyping boards in their own right. Nice to own and possibly even sellable for that purpose. But like I said, I'm more interested in doing it over firewire. Cheers Simon
Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more
sorry I'll do this at once: I read: On Fri, 2004-11-26 at 23:17, Mark Knecht wrote: This I agree with, but the best way to fight for it (speaking as a business man) is to develop a real market for it. We need thousands of buyers. Develop the market and hardware manufacturers will come. ouch businessmen ;) so what is a _real_ market ? the one that microsoft controls ? and because microsoft and this 'different' computer[0] company that m$ owns don't do free (as in speech) stuff ... fine Perhaps it's here already. I think there's more of us RME or M-Audio customers than one might think. I can only speak for my uni and a couple of electronic music/media art institutions and labs that bought rme products (and that's getting a couple of not so cheap devices) precisely _because_ there are linux drivers (and linux is not at all uncommon in this scene). regards, x [0] written on debian ppc -- [EMAIL PROTECTED] Postmodernism is german romanticism with better http://pilot.fm/special effects. (Jeff Keuss / via ctheory.com)
