[alsa-devel] RME MADIface 192 kHz problem

[Takashi Iwai]

At Fri, 22 Oct 2010 11:54:36 +0200,
Florian Faber wrote:
> 
> Takashi,
> 
> >>>>> What is needed to get this card running at 192 kHz?
> >>>> A working driver :)
> >>>>
> >>>> http://wiki.linuxproaudio.org/index.php/Driver:hdspe
> >>> How about posting the patches? :)
> >>
> >> It would be dozens/hundreds of single patches against the hdspm driver.
> > 
> > I don't mind any number of patches if they are written logically and
> > well readable.
> > 
> >> I'd rather replace it with the version above.
> > 
> > If it's more or less compatible with the current driver, it's fine.
> > But, one bulk patch is bad.  Even if you replace the driver code,
> > split in a logical order, at best.
> 
> There are changes everywhere since the old driver inherited a lot of
> code from the hdsp driver which in turn inherited a lot of code from
> previous drivers. The code was never properly suited to support a
> broader range of hardware.

Yep.

> I don't have the time to split up all the changes in all the different
> places and if I had the time, I would rather do a complete rewrite (or
> better: Finish the rewrite I started a while ago).

Well, you don't have to send always a perfect, flawless and
comprehensive version of the driver code.  In general, the
development, especially a clean-up work, should be done gradually in
the upstream tree, instead of your private version.
Otherwise it makes even harder to sync with the change of other parts,
e.g. the core-side API changes.

So, don't hesitate to post the current version although it's not
complete.  It's far much better than keeping the stuff privately over
years.

How to split the patch depends on the size.  It'd be helpful, however,
if it can be split somehow logically.  Sending a patch is something
like a presentation and convincing audience, after all.


> >> And I changed one ioctl
> >> which would break compatibility - although I doubt anybody used the
> >> levelmeter ioctl besides me. The version above is a 'public beta'.
> > If it's a new ioctl, it's OK.  We can drop the old (very likely)
> > unused ioctl eventually.  But using the same ioctl for different
> > behavior is no go.
> 
> Ok, dropping the old one in favour of the new one.
> 
> >> If the support for the AIO/RayDAT finally works - sure. But for that I
> >> still need to tell ALSA somehow that there are n buffers to use, n>2,
> >> with n IRQs per buffer cycle.
> > Well, actually I forget what your questions are.  Please continue it
> > on ML here.
> > 
> > All other sound drivers work fine with more than two periods, so I
> > don't think there is any restriction in the API side.
> 
> Ok, the problem was that the AIO/RayDAT have two modes of operation, a
> 'windows' mode and a 'mac' mode. In the 'windows' mode the full 16k
> sample buffer is utilized and the card produces 16k/period_size IRQs
> while running through the buffer. I'd need a way to tell ALSA this.
> In 'mac' mode it uses a double buffering scheme but only produces one
> IRQ per each double buffer walkthru. I understand that ALSA does not
> support this mode of operation.

I don't see any problem to support both.

The windows mode is a fixed buffer size, and integer periods, likely
with a certain minimal period size or a max number of periods.

The mac mode is much simpler.  Just set 2 to periods_min and
periods_max.  I don't know whether it has a buffer or period size
limitation, though.


Takashi