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

Pieter Palmers pieterp at joow.be
Fri Nov 26 10:08:08 UTC 2004


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 r&d 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 
(IEEE1394a&b) 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



More information about the Linux-audio-dev mailing list