RME MADIface 192 kHz problem

RME MADIface 192 kHz problem

[Fredrik Lingvall]

 Hi all,

I have a problem running the RME MADIface card at 192 kHz. At that
speed the number of channels for the card is reduced to 16. I can set
the sampling rate to 192 kHz using:

# amixer -c 1 cset numid=2 9
numid=2,iface=MIXER,name='Sample Clock Source'
  ; type=ENUMERATED,access=rw------,values=1,items=10
  ; Item #0 'AutoSync'
  ; Item #1 'Internal 32.0 kHz'
  ; Item #2 'Internal 44.1 kHz'
  ; Item #3 'Internal 48.0 kHz'
  ; Item #4 'Internal 64.0 kHz'
  ; Item #5 'Internal 88.2 kHz'
  ; Item #6 'Internal 96.0 kHz'
  ; Item #7 'Internal 128.0 kHz'
  ; Item #8 'Internal 176.4 kHz'
  ; Item #9 'Internal 192.0 kHz'
  : values=9

but when I try to read data at 192 kHz I always get a :

Invalid argument

from

the snd_pcm_hw_params_set_channels(...)

and

snd_pcm_hw_params(...)

functions when I try to set the number of channels. The

snd_pcm_hw_params_get_channels_max(...)
snd_pcm_hw_params_get_channels_min(...)

functions also seems to return the wrong number of max and min number
of channels.

And, jackd will not start using 192 kHz. See the thread here:
http://www.rme-audio.de/forum/viewtopic.php?id=9169

What is needed to get this card running at 192 kHz?

Regards,

/Fredrik


-- 
Fredrik Lingvall, PhD                                                              
E-mail: fl@ifi.uio.no, fredrik.lingvall@gmail.com
Web:    http://folk.uio.no/fl/

Re: RME MADIface 192 kHz problem

[Florian Faber]

Fredrik,

> I have a problem running the RME MADIface card at 192 kHz. At that
> speed the number of channels for the card is reduced to 16. I can set
> the sampling rate to 192 kHz using:

The MADIface does not run properly with the stock hdspm driver. Most of
the controls are wrong and the FPGA is using a wrong base frequency.

> What is needed to get this card running at 192 kHz?

A working driver :)

http://wiki.linuxproaudio.org/index.php/Driver:hdspe

There you can also find a version of hdspmixer that works with 64 channels:

http://wiki.linuxproaudio.org/index.php/App:hdspmixer_64


Flo
-- 
Machines can do the work, so people have time to think.
public key DA43FEF4          x-hkp://wwwkeys.eu.pgp.net

Re: RME MADIface 192 kHz problem

[Takashi Iwai]

At Thu, 21 Oct 2010 16:10:58 +0200,
Florian Faber wrote:
> 
> Fredrik,
> 
> > I have a problem running the RME MADIface card at 192 kHz. At that
> > speed the number of channels for the card is reduced to 16. I can set
> > the sampling rate to 192 kHz using:
> 
> The MADIface does not run properly with the stock hdspm driver. Most of
> the controls are wrong and the FPGA is using a wrong base frequency.
> 
> > 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? :)


Takashi

Re: RME MADIface 192 kHz problem

[Florian Faber]

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'd rather replace it with the version above. 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 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.


Flo
-- 
Machines can do the work, so people have time to think.
public key DA43FEF4          x-hkp://wwwkeys.eu.pgp.net

Re: RME MADIface 192 kHz problem

[Takashi Iwai]

At Fri, 22 Oct 2010 07:09:26 +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.

> 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.

> 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.


thanks,

Takashi

Re: RME MADIface 192 kHz problem

[Florian Faber]

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.

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).

>> 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.


Flo
-- 
Machines can do the work, so people have time to think.
public key DA43FEF4          x-hkp://wwwkeys.eu.pgp.net

Re: 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