Re: RME AES32 & MADI

[Takashi Iwai <tiwai@suse.de>]

At Mon, 5 Feb 2007 10:27:28 +0100,
Winfried Ritsch wrote:
> 
> Hello,
> 
> Am Freitag, 2. Februar 2007 19:39 schrieb Takashi Iwai:
> > At Wed, 31 Jan 2007 13:11:48 +0100,
> >
> > Remy Bruno wrote:
> > > Hello,
> > >
> > > I have been working on the AES32 and will soon provide a patch to get it
> > > (hopefully) fully operational (hdspm code).
> > >
> > > Moreover, I also worked on the MADI card, but the original hdspm driver
> > > didn't work for me (ie the code before my modifications to support
> > > AES32). I had to deal with the following points:
> > >   - it needed the DDS feature (clock divisor), as for the AES32 and
> > > hdsp9632 cards (this may be a new behavior for recent cards)
> > >   - the channel map needed to always be channel_map_madi_ss (and never
> > >     channel_map_madi_ds, even at 96k), as for AES32. Otherwise, the
> > > routing was not correct.
> > >   - not enough DMA memory was beeing allocated (only for
> > >     "params_channels(params)" channels whereas it should be allocated for
> > > all the channels, otherwise it didn't work at 96kHz) (alsa-lib was
> > > complaining, so I don't think an old MADI card would work either)
> > >   - I had to play with the channel and rate rules
> > >     (snd_hdspm_hw_rule_channels_rate and so on) to get it working. Not
> > >     completely clear to me how it works but it didn't work as it was
> > >
> > > So here come my questions:
> > >   - Was the MADI driver completely fonctionnal before now? In other
> > > words, maybe an older revision of the card was working as the code
> > > suggested (ie differently than the revision I have, which is 204), can
> > > anyone confirm this?
> >
> > The early version has surely worked, IIRC.
> > But, Winfried should know better....
> >
> Yes we are still working with MADI-Cards, on early version one version Rev 1.1 
> and a newer card. The only thing is, that there are some troubles with  the 
> correct Statusinformation, which are not functional limiting the card. 
> 
> We did not test DS mode extensively, but i can think of I tested it once MADI  
> to MADI and it worked. 

OK, good to hear.

> > >   - As a corollary: should I keep the compatibility with the old code? IE
> > > keep using channel_map_madi_ds, etc. for revisions < 204?
> >
> > Well, the only question is whether it breaks the older models.
> >
> If you post a patch or code so I can test it on old cards, it should be OK if 
> you change this.

Great.  Remo, could you repost the latest patch for review?


> BTW:
> Also I never finished to make a memory map interface for the mixer and meters, 
> since it needs 16384 Bytes Mixer and the same for meters of values to copy, 
> which is more ctl-interface can transfer at one time. Should we work on that, 
> or everybody uses individual access to fader and meters for the software ?

I'm in favor of implementing mmap mode.  As long as it's read-only and
volatile, the mmap mode is the best solution.  However, the mmap of
io-mapped pages doesn't work on all architectures properly.  So, the
access via control API would be still needed as a fallback and for
backward compatibility.


Takashi

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642