[alsa-devel] RME MADIface 192 kHz problem
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,
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
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 :)
How about posting the patches? :)
Takashi
Takashi,
What is needed to get this card running at 192 kHz?
A working driver :)
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
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 :)
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
Takashi,
What is needed to get this card running at 192 kHz?
A working driver :)
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
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 :)
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
participants (3)
-
Florian Faber -
Fredrik Lingvall -
Takashi Iwai