Re: [PATCH RFC 16/26] ALSA: rme32: Convert to copy_silence ops

["René Rebe" <rene@exactcode.de>]

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.

Have a nice weekend,
	René

-- 
 ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin, https://exactcode.com
 https://exactscan.com | https://ocrkit.com | https://t2sde.org | https://rene.rebe.de