Hey,
On 02 Mar 2019, at 18:19, René Rebe rene@exactcode.de wrote:
Hi Takashi,
On 18 Jul 2018, at 12:56, Takashi Iwai tiwai@suse.de wrote:
to have another digital audio i/o card for our studio / office, I got a pair of RME32 the other week from ebay. (mostly as reference to implement ADAT for the RAD1 Sgi/Octane ALSA driver, …)
Unfortunately they do not work with Linux. They are recognised and all the usual devices and /proc/… entries show up, however, the hardware pointer does not move during playback or capture no matter what clock source I choose. I tried attaching coax s/pdif as well as an 8-channel Behringer Ultragain ADAT source w/ clock.
Does the /proc/asound/card*/rme32 entry show the right setup? RME32 seems to have only few registers, and it behaves differently for read and write. Maybe you should try to watch the register 0x20000. The hwptr is the LSB 33 bits.
thank you again for your reply, and I finally took a deep breath to "shortly" take a closer look at this again. So with current linux-kernel :HEAD nothing has changed, and I get one IRQ when the playback starts.
As I do not have the spec I did a quick hack and commented out the IRQ acknowledge around rme32.c line 829:
writel(0, rme32->iobase + RME32_IO_CONFIRM_ACTION_IRQ);surprisingly this “works” in that I have more than the first frame coming out of the optical fibre, aka quite constant running pcm stream.
"Quite constant” because I think I sometimes (rarely) here some samples getting lost, probably because the IRQ keeps firing as it was not acknowledged. However, I’m surprised this works 99%ish anyway.
Of course the questions is now to actually properly fix this, as acknowledging this IRQ somehow makes the card stop entirely, I guess, somehow? At least that is how it looks like. Maybe you have an idea? Maybe some ALSA stream helper refactoring broke something a decade ago?
I should probably also mention that this works with aplay, while with sox’s “play” this hack is somehow producing constant under-run’s:
In:85.6% 00:03:18.02 [00:00:33.35] Out:8.73M [!=====|=====!] Hd:0.0 Clip:0 play WARN alsa: under-run play WARN alsa: under-run play WARN alsa: under-run
which might be an indication of some stream pointer helper glue not being wired up correctly anymore (I tested some seriously old version the last time, like 2.6.29’ish, so this might be broken since over a decade or so already)?
Thanks again for any tips, as otherwise I might spend many more hours trying to understand the FPGA and ALSA API.
So as the card sort of works in Windows,
https://www.youtube.com/watch?v=dxMH3MMyKZ4
I spent some more time finding a workaround.
https://www.youtube.com/watch?v=78-JxDzbHX8
Writing something else then 0 to the interrupt acknowledge register keeps the stream running. Writing 0xffffffff causes the stream to corrupt. So I thought maybe this FPGA bitstream copies this value into the command register, and writing that register copy at least playback work for me now. Capture does still not work, but that is probably a story to be continued another month:
--- linux-4.20/sound/pci/rme32.c.vanilla 2019-03-03 15:09:34.485653177 +0000 +++ linux-4.20/sound/pci/rme32.c 2019-03-03 15:09:51.077653422 +0000 @@ -863,7 +863,7 @@ if (rme32->playback_substream) { snd_pcm_period_elapsed(rme32->playback_substream); } - writel(0, rme32->iobase + RME32_IO_CONFIRM_ACTION_IRQ); + writel(rme32->wcreg, rme32->iobase + RME32_IO_CONFIRM_ACTION_IRQ); }
return IRQ_HANDLED;
In case this stupid Mail.app causes white space damages: https://svn.exactcode.de/t2/trunk/package/base/linux/rme32-hothack.patch
PS: as per the above 3h video I read the disassembly and confirmed the value is written into the RME32_IO_CONFIRM_ACTION_IRQ MMMIO location.
René