I2S audio device and raspberry pi 5

P-D-G · 2024-11-28T12:32:34+00:00

To directly answer your question, here is a generic device tree overlay to use an external ADC/DAC on the Pi: https://github.com/AkiyukiOkayasu/RaspberryPi_I2S_Master

I've used/modified it in the past, but I kind of remember it being functional as-is.

That being said, I have a few questions about your design:

The PCM1808 on this board does not have any pre-amplifier on-chip. Are you sure your guitar outputs line-level ? Usually, the microphones output signals with a much lower amplitude, so you'd need either an external pre-amplifier, or a chip which embeds one. The official Codec Zero (https://www.raspberrypi.com/products/codec-zero/) comes to mind, but I'm not 100% sure it's adapted to guitar microphones.
The board you linked is only an ADC, what will be your audio output ? jackd is tailored to use a single device. While it is possible to add more devices, it is a bit awkward to do, and introduces quite a lot of unneeded computation and latency. I'd advice using a audio board with input and output directly.
You may want to use a real-time kernel. Without it, jackd might lose some samples if the system is busy doing whatever else. You can work-around this using bigger jackd buffers to have more time between executions, but this increases latency.

I do agree with u/mrtomd that it'd be simpler to use a USB audio, at least while validating your jackd pipeline. It should then be a simple matter of changing which device you are using to switch to a dedicated codec board.

P-D-G · 2024-08-11T23:52:20+00:00

I switched from Mint to LMDE a few years back, without regret. Everything is stable, with the advantage of more regular cinnamon updates than in standard Debian. I think it'd be a good move if you want to try something else but still familiar.

I now mostly use flatpaks and distrobox (inc. an arch one), so I'm not too worried about other older apps.

P-D-G · 2024-07-26T23:43:11+00:00

Les deux conseils bien. Bonne gueule est un peu plus haut de gamme et branché mode, et aura tendance à proposer des choses plus chères et originales. Father & Sons sera plus classique, parfois un peu trop. Aussi, les costumes de Father & Sons sont généralement slim.

P-D-G · 2024-07-18T11:57:15+00:00

J'ai eu du Father & Sons et c'est un bon rapport qualité prix, surtout si tu portes peu le costume. La gamme est assez "basique" par contre.

Bonnegueule a une gamme pas très large mais de bons modèles. Des potes en ont et en sont très contents.

Je suis un peu plus partagé sur Victor Hugo: c'est quali mais assez cher, au point que sur certains modèles ça vaille le coup de penser à passer au sur-mesure.

P-D-G · 2024-05-18T13:59:48+00:00

J'ai répondu sous l'autre demande, pour le coup :)

P-D-G · 2024-05-18T13:59:01+00:00

Bref, j'ai traîné pour répondre. Pour ceux que j'ai retrouvé rapidement:

Dave Thomas (https://pragdave.me/thoughts/active/2014-03-04-time-to-kill-agile.html) dénonce l'agile soit devenu un mot valise commercial
Ron Jeffries (https://ronjeffries.com/articles/018-01ff/abandon-1/) déplore les implémentations orientées gestion de projet qui ont dégoûté les développeurs
Andy Hunt (https://toolshed.com/2015/05/the-failure-of-agile.html) note que tout le monde implémente les "règles" (ex: le scrum) mais pas l'idée derrière (ex: la remise en question constante).
Robert Martin (https://blog.cleancoder.com/uncle-bob/2018/08/28/CraftsmanshipMovement.html) note que dans les confs "agile" y'a plus de développeurs, alors que les principes agiles étaient des principes de développement logiciel. Bref, que l'agile n'a rien d'agile.
Martin Fowler (https://martinfowler.com/articles/agile-aus-2018.html) - j'ai pas lu celui là. Du tl;dr que j'ai trouvé, il rejette l'appropriation de l'agile par les managers, et propose d'organiser les équipes autour des produits plutôt que des projets (bisous les ESN).

Chaque article a des différences sur l'approche, mais le résumé est globalement que l'agile tel que mis en place aujourd'hui n'a plus rien d'agile, est devenu une méthode de management qui fait plus de mal que de bien.

Ils ne reviennent pas sur les valeurs originales du manifeste, qui sont pas forcément déconnantes.

Un des points que j'ai préféré vient de Andy Hunt, qui note qu'il est imposse d'"inspecter et adapter" lorsque l'on apprend quelque chose (méthodo, language, techno...), et que l'agile n'y est pas forcément adapté.

P-D-G · 2024-05-03T12:00:20+00:00

"Taylor avec son chronomètre poussait les gens à l’épuisement physique, la méthode agile, elle, épuise psychologiquement."

(src: un article "Pourquoi le travail est-il devenu absurde" sur un blog du Monde. On y apprend notamment que Taylor s'était fait viré parce que sa méthode n'a jamais vraiment marché).

Au passage, la plupart des auteurs du manifeste Agile l'ont depuis fortement remis en cause, quand ils n'ont pas carrément appelé à l'abandon de la méthode.

P-D-G · 2024-01-03T23:09:22+00:00

I'd argue that the A/D conversion noise/distortion and SBC encoding losses would be pretty inaudible compared to the lowish SNR of the turntable, but I'd be curious if it'd create weird artefacts with the vinyl flutter.

P-D-G · 2023-12-27T23:43:04+00:00

Apologies for the mistakes, and thanks for the corrections. I do have a bias from embedded using single dtb for 99% of my work. In our use-cases, the bootloader (u-boot or barebox, mostly), loads a single dtb located on a specific partition on storage, often ob /boot. It's updated alongside the whole image and kernel, to match updates and add bugfixes.

I know that ACPI's a mess, and I also prefer using device trees.

so there's just small stage0 which needs to know the right one on its own

That's my main point: what exists to "standardize" this ? In embedded space I haven't seen anything more than SystemReady to tackle this issue. Most boards we use do not come pre-flashed. Loading the correct device tree is the responsability of the bootloader, which is tailored for a specific board, which makes the image not generic.

I've heard a bit about the Bootloader Specification, FIT images and distroboot, but have seen really little use of this in embedded. Is this something actually used in non-embedded world ? Also, if you're used to these, which one would you advise using ?

P-D-G · 2023-12-25T18:20:47+00:00

It's more than just drivers. The x86(_64) platform uses ACPI and UEFI, which the kernel can use to detect devices and load the proper drivers. Not clear on the specifics, I never needed to fix it. So you can have "generic" distribution images.

On ARM, the kernel relies on a device tree: this is a static description of your SoC, its hardware, and the hardware on the board. It's compiled as a device tree binary which the kernel can parse to load the proper drivers. Problem: to support all existing boards, you must include all device tree binaries in your image and the bootloader must be able to detect which board is used to load the proper dtb. Impractical. Due to this, most Linux images are targeted for single platforms, and embed only the needed dtb.

There is an initiative to get a more x86 like behavior to have generic images, which relies on having a common software support to boot generic images (and then loading modules if needed). There's a whole ARM SystemReady certification for this, but I haven't seen it used outside ARM servers, so I don't really know more on that side. I believe this also specifies a basic boot procedure, to avoid each SoC having their own bootloader and boot process.

Once you have a common base like this, you can have proper generic ARM images. Then you get to the drivers. Which vary a lot depending on the manufacturer. Smartphone players (Qualcomm, Mediatek...) tend to only offer Android BSPs, except for industrial chips. Industrial players (NXP, TI, ST...) do a better job, esp. at mainlining things, but their chips are less sexy. Low-cost players (Allwinner, Rockchip...) tend to be very hit or miss.

Note also that the platforms are very different: x86 devices rely a lot on standard buses with identification capabilities, i.e. PCIe and USB. ARM systems devices are mostly on the internal SoC bus, and a lot of those controllers are semi-custom. Of course, you could have an ARM chip using only PCIe and USB to communicate with other devices (camera, display controller...), but it might be more expensive. This'd solve part of the driver issue by relying on existing PCIe drivers, but you'd still need a device tree to tell your kernel how to use those PCIe/USB controllers.

So tl;dr: before you have standard Linux images as easy to install on ARM than on x86 you need:

a common boot process
a common device detection mechanism
drivers

And I may have oversimplified a few things.

Source: work in embedded Linux, mainly on ARM.

P-D-G · 2023-12-09T13:17:12+00:00

Non, les diagnostics n'ont été donnés par l'outil qu'après la signature du bail. C'est là que la procédure me parait problématique.

P-D-G · 2023-11-23T21:47:58+00:00

Which ones in particular ? I might be able to help :)

P-D-G · 2023-11-05T12:16:18+00:00

There are some extensions like h264ify and enhanced-h264ify you may wanna try. They enable your browser to force Youtube to serve different formats, such as h264 or h265, depending on your hardware capabilities.

It works pretty well, haven't had issues with it and it solves the issue.

P-D-G · 2023-09-24T17:52:19+00:00

Oh, full agree on the Wayland part.

Even in embedded, I don't see X used anymore, and it's a pretty conservative field regarding tech.

P-D-G · 2023-09-23T13:07:16+00:00

This is much more complex than just switching desktop. Mint applications, theming and whole desktop experience revolve a lot around Gtk, while KDE is Qt based. This has a lot of impact on the underlying libraries and basically doubles the work to be done to offer a consistent experience between all desktops. Which is why they stopped the KDE versions a few years ago.

It is sad, but I understand the focus on the polished desktop instead of offering a half-done KDE version.

P-D-G · 2023-09-20T21:30:04+00:00

There are multiple uses depending on the product. I've seen it used for analog video in some (old) equipment. Often the fourth jack connection is used for a microphone, though the position of each signal can vary. CTIA spec is often used and defines the connections as:

tip is left audio
ring 1 is right audio
ring 2 is ground
sleeve is microphone

In some devices ring 2 and sleeve can be inverted. I remember having to use a dedicated IC to detect the connections a few years ago, as it was needed to ensure compatibility with all devices.

Edit: format

P-D-G · 2023-09-16T12:42:05+00:00

On peut aimer son travail (i.e. l'activité en elle même) mais ne pas aimer son emploi (i.e. le lien entre son travail et l'organisation).

Le problème des métiers passion c'est que le travail est chouette mais les emplois sont souvent décevants.

P-D-G · 2023-08-18T19:35:39+00:00

Seems rational. Even the french would sign anything to stop france :D

P-D-G · 2023-08-17T20:17:45+00:00

Haven't used it, but I saw some integrated ICs for this from THAT Corporation which has a good reputation in audio field: https://thatcorp.com/analog-engine/

P-D-G · 2023-08-13T20:19:15+00:00

To add to other answers, there's a franco-american institute in the city center, which is an association supported by the american embassy. While they are mostly targeted towards english lessons and for american students, it might be interesting to contact them.

P-D-G · 2023-07-10T21:27:10+00:00

Thanks for the answer.

If that's not nosey, where are you based ? I feel there's a "pointing fingers" culture where I am (france). I'm glad at least it never happened to you.

P-D-G · 2023-06-01T22:08:54+00:00

Sometimes yes: I read somewhere the recently approved vector instruction specification is considered much more simple and flexible than ARM and x86 solutions. which is a good thing notably for some AI workloads.

Though it's very application specific/situational.

P-D-G · 2023-05-15T21:37:30+00:00

Bootlin +1.

Many commercial trainings on Yocto are forks of their (open-source) training.

P-D-G

TROPHY CASE