From mboxrd@z Thu Jan 1 00:00:00 1970 References: From: Philippe Gerum Subject: Re: Taking first steps with EVL In-reply-to: Date: Fri, 16 Jul 2021 09:56:50 +0200 Message-ID: <87o8b27ku5.fsf@xenomai.org> MIME-Version: 1.0 Content-Type: text/plain List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Byron Jacquot Cc: xenomai@xenomai.org Byron Jacquot via Xenomai writes: > Hello Everyone, > > I'm evaluating some of the newer options for doing real-time audio > processing. I've been playing with the Xenomai-based ElkOS - some online > discussion led me to EVL. > > I'm working with a Rasbperry Pi 4B - I started with a Raspbian Lite card, > and have been building EVL kernels from the v5.12-evl-rebase branch. > > I've got a grasp on the basics - I cloned & built the kernel, then ran `evl > test`, discovered missing configuration parameters, added them, and now the > tests all pass. I've poked at Hectic and Latmus, too. > > I also noticed a boot-time message about pipeline capable Pi4 IRQ chips, > and found the following discussion of a patch to fix it, so added that and > eliminated the message. > https://evlproject.org/pipermail/evl/2021-February/000300.html > Mmh, it looks like this patch which is present in v5.10.y-dovetail fell through the cracks when rebasing on top of v5.11. I just merged it back to the Dovetail tip at v5.13. Thanks for the hint. > I'm pulling the basics of application and driver development together > also. I'm getting to know EVL thread spawning, diagnosing inappropriate > system calls, etc. I've got a stub of a character device driver with the > OOB calls attached, and my application successfully attached and using > those calls, partitioning the RT and non-RT access. Much of this was > informed by looking at both sides (user/driver) of Hectic and Latmus. So > far, so good! > > Now I'm looking to get audio in & out of the system - it looks like there > are two possible paths I could follow, and wanted to see if anyone here > might be able to offer steering and guidance. > > The first path would be to port the RTDM driver from ElkOS - unwind the > RTDM parts, and replace them with EVL ones. I'm reasonably familiar with > that driver. Is my understanding correct, that the heart of it is really > setting up the DMA IRQ with the OOB flag, and the OOB DMA is functional on > the bcm2835/Pi4? > Correct. I've been using this DMA backend in out-of-band mode to run the oob-spi tidbit (libevl/tidbits), illustrating how to run low jitter transfers over SPI with EVL on the RPI series (zero/2b/3b/4b) [1]. > The other path would be the ALSA patches described below, plus porting work > based on it for the BCM2711 I2S port & my converters. My application > doesn't need ALSA, but if it's a useful stepping stone, it's not precluded, > either. > https://xenomai.org/pipermail/xenomai/2020-September/043502.html > > Does one of these seem like a shorter path to proof of concept than the > other? > In a nutshell, option #1 (porting your driver from RTDM to the EVL kernel API) might be the most straightforward route, since both APIs share many semantics and your code is known to work already. Option #2 would require to adapt the i2s and codec drivers backing the PCM operations, like the couple of top commits at [2] do. You would also need a user space interface to talk to the oob-capable Alsa stack. For this, either direct [oob_]ioctl() would do, or I could share some code marginally extending tinyalsa [3] to enable pcm_readi()/pcm_writei() for the oob audio path. That route would require to give more thought to the problem (not necessarily more code though), but would make the full range of Alsa features available to control your hardware (e.g. configuration, muxing etc), in addition to having oob capabilities as well. If you application will never need Alsa features, and your existing driver is doing the job today, then #1 may be a no-brainer. If you want to benefit from the richness of the Alsa API in addition to high-frequency, low jitter audio transfers at some point, then #2 is better. [1] https://evlproject.org/core/oob-drivers/spi/ [2] https://source.denx.de/Xenomai/xenomai4/linux-evl/-/commits/wip/audio/ [3] https://github.com/tinyalsa/tinyalsa -- Philippe.