RE: [linux-audio-dev] firewire/IEC 61883-6

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: RE: [linux-audio-dev] firewire/IEC 61883-6
From: Mark Knecht (mknecht_AT_controlnet.com)
Date: Thu Apr 03 2003 - 18:00:59 EEST


> On Wed, Apr 02, 2003 at 02:17:03AM -0500, rm wrote:
> > i looked around a bit and it seems like AMDTP/IEC61883-6 is starting
> > to be used and is in the linux 1394 drivers. it appears to include
> > multi-channel audio and midi which would be quite cool. (it also
> > appears not to be mlan).
>
> actually it sort of is mlan.

yep...

>
> from what i've read, mlan seems to deal with finding and connecting
> resources rather than actually pushing packets. so mlan lives on top
> of AMDTP.

yep...completely on top...

>
> and while mlan connectivity would be nice from other perspectives, i
> would just as soon use a non-compatible (open) method as any.

I can understand this desire, but I have to ask what you want to connect? If
it is Linux PCs and little boxy things developed in the future using Linux,
then I think we would be well served by having a separate, new protocol in
Open Source. However, if your desire is to hook together studio instruments
and devices that exist today, then you need to implement mLAN as it is
specified.

We have recently gone through a review of the mLAN Licensing Agreements, and
one of the questions I asked our lawyer was whether a company could legally
direct the development of an Open Source version of an mLAN implementation?
His answer was 'yes'. If there were developers operating under NDA with a
company that had access to an mLAN spec, or developers that had access to
the spec itself directly from Yamaha, then he did not believe that the
current licensing agreement required the actual Linux source code that
implemented mLAN to be confidential. However, the licensing agreements do
call on the developer/company that does this work to properly implement the
spec with no changes, and possibly to submit samples to Yamaha for testing
and verification, and should Yamaha find problems, to correct them, or
remove the 'product' from the marketplace immediately.

So, I think for now that there is no real need to have a separate, new
protocol. However, owing to the nature of Open Source, I am quite concerned
that if there was a problem code source, we would not be able to 'remove it'
from the marketplace. I also note that the general nature of Open source
developers seems to be to do what they want to do, and not necessarily what
they are required to do as per a spec like this. I think that could be a
problem.

Probably the best way to make this happen would be for an individual
developer who is interested in this area to take a license with Yamaha
himself, do the implementation, submit it for testing BEFORE it becomes Open
Source, get it up to par, and then release it. At least that's my best idea
right now.

>
> rob
>
> PS nothing seems terribly novel (irreplaceable) in the patents i've
> seen (viz, 5,825,752).
> PPS if i see the word 'plurality' again i'm going to swear repeatedly.

I agree! It's a horrible word these days...


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Apr 03 2003 - 18:02:29 EEST