On Wed, 27 Mar 2019 12:20:30 +0100, René Rebe wrote: > > Hi, > > thanks for the reply: > > On 27 Mar 2019, at 12:14, Takashi Iwai <tiwai@xxxxxxx> wrote: > > On Sun, 24 Mar 2019 12:19:49 +0100, > René Rebe wrote: > > Hey, > > On 02 Mar 2019, at 18:19, René Rebe <rene@xxxxxxxxxxxx> wrote: > > Hi Takashi, > > On 18 Jul 2018, at 12:56, Takashi Iwai <tiwai@xxxxxxx> 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. > > OK, that sounds reasonable. Actually writing 0 for ACK is somewhat > weird, I guess the driver code took the behavior from rme96.c. > > Possibly the behavior depends on boards, but as long as you can see it > working with the change, it's fine to apply the change now, of course. > > Would you submit a proper patch, or rather let me do that in my side? > > We can wait until next week, maybe I find time this weekend to further poke > around to get capture working. > I will resend a well formatted patch in either case ;-) OK, have fun :) For the capture, you might need to try both full-duplex and half-duplex modes. They behave completely differently. I'd start from checking with the direct mmap in half-duplex mode (default). thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
