[alsa-devel] [PATCH RFC] ALSA: rme32: fix interrupt ack for me
Takashi Iwai
tiwai at suse.de
Wed Mar 27 12:24:14 CET 2019
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 at suse.de> wrote:
>
> On Sun, 24 Mar 2019 12:19:49 +0100,
> René Rebe wrote:
>
> Hey,
>
> On 02 Mar 2019, at 18:19, René Rebe <rene at exactcode.de> wrote:
>
> Hi Takashi,
>
> On 18 Jul 2018, at 12:56, Takashi Iwai <tiwai at 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.
>
> 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
More information about the Alsa-devel
mailing list