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
