Subject: Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more
From: Pieter Palmers (pieterp_AT_joow.be)
Date: Fri Nov 26 2004 - 12:08:08 EET
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
This archive was generated by hypermail 2b28 : Fri Nov 26 2004 - 12:12:16 EET