Re: [PATCH RFC] ALSA: rme32: fix interrupt ack for me

[Takashi Iwai <tiwai@suse.de>]

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@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@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.
> 
>     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@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel