One issue that I have running the Raspberry Pi OS with the infamous systemd, is for some undefined weird reason, the detection of the IQaudIO DAC is not done making sure to mute the sound card. On every boot, I get a strange sound from the speakers, as if, it comes from some alien! Before, the detection and initiation of the card were done silently: What happened now?
Now, the Raspberry Pi developers insist on users to use their OS! Is this some kind of vendor lock-in? To me, it is a message not to buy more Raspberry Pi mini-computers.
Now, the Raspberry Pi developers insist on users to use their OS! Is this some kind of vendor lock-in? To me, it is a message not to buy more Raspberry Pi mini-computers.
Why do you say they insist in using "their" OS? That's not at all the case. You can use whatever you like.
mbrennwa said:
To get support for the IQaudIO DAC hat I had to install their OS as they complained they cannot cater for every other Linux distribution. Moreover, I read that the Raspberry Pi developers strongly recommend users to use the RASPBERRY PI OS, their OS.
I would have preferred an infinite number of times to install an OS which does not use systemd, and which, detects the IQaudIO DAC HAT, but NO, I am in a vendor lock-in.
Needless to state, it will not repeat.
You really don't. I have used IQAudio DACs and Amps on many varied RPi OS's: picoreplayer, Moode, Volumio, Rune, arch etc without issue. IQAudio products were developed and produced independently from from the RPi makers; the production of them by RPi has only happened in the last year or so.
Don’t most or all of the solutions you mentioned use the pi OS under the covers? While using alternative OS is functional with the pi using them for practical application is experimental/beta/humorous. Honestly in real terms the pi is only just stable and functional enough with its own OS. I love the pi running moode even if general maintenance requires frequent reloads (or card swaps).
Not sure about Moode & Volumio, but picoreplayer is built on TinyCore, with Rune and Archphile built on Arch linux, so are totally independent from RPi OS.
I do not want to use ready made configurations which make many assumptions about the way I play music. Furthermore, such ready made packages expect the network to be configured in a certain way, which in my case, conflicted to such an extent, that the network was not connected to. I only want, a Linux base system without the bloat of a desktop or window manager, which recognises the DAC hat. However, that appears to expect too much!Yatsushiro said:
And, at least until I used the Raspberry Pi OS, these IQaudIO developers did not produce enough information to manually install a driver for their DAC hats.
The configuration should be as simple as:
a) install firmware
b) install the appropriate kernel modules/drivers
c) configure some text files if not automatically done
This seems asking too much.
Nevermind, I will NOT purchase such TRASH again!
Last edited:
Many users are posting in this thread what they prefer, much unlike me, having found nothing suitable for my use case. The Raspberry Pi developers, in their wisdom, chose bleeding edge software, instead of well proven "older" software. This introduces software misbehaviour (bugs). I am experiencing precisely this. This misbehaviour could have been avoided.
So many pontificating about what they use and how successful they are in their Linux choices! However, and this however is very important for my use case, does anyone know how to install drivers and firmware for the, ridiculously called, IQaudIO DAC PRO? Does anyone know how to configure it afterwards if it requires configuration?
The next time, I WILL NOT BUY another TRASH IQaudIO DAC FLOP (err PRO)! It is not supported, and in my case, resulted in a much despised VENDOR LOCK-IN!
So many pontificating about what they use and how successful they are in their Linux choices! However, and this however is very important for my use case, does anyone know how to install drivers and firmware for the, ridiculously called, IQaudIO DAC PRO? Does anyone know how to configure it afterwards if it requires configuration?
The next time, I WILL NOT BUY another TRASH IQaudIO DAC FLOP (err PRO)! It is not supported, and in my case, resulted in a much despised VENDOR LOCK-IN!
It is useless starting a new thread, as the DAC HAT developers did not publish how to install and configure their device. They want users to "use what they support". It seems, giving information as to how to install a driver and configure a piece of hardware, is the same as supporting it on other platforms!drkmatr said:
Maybe, I am an idiot, and cannot distinguish the difference!
Now, let us be serious. Which other DAC hats can be used instead which have full open source support instead of a much much despised VENDOR LOCK-IN? In other words, a user should be able to manually install a driver and configure it on whichever distribution one chooses.
What I am finding for the HiFiBerry DAC follows the same tragic path! HowTos pontificate about how easy it is to setup a DAC, and yet, when it is followed, after a boot one finds complete failure! Where is the DAC HAT listed? Sure, it works and it is easy, but where is the DAC? I have wasted several months searching a way to enable a silly DAC HAT, and, IT SHOULD NOT BE LIKE THAT!
The developers of whatever open source hardware should know hiding the way a driver is configured and installed is similar to what closed source software developers do. This is not open source, but a savage vendor lock-in.
Last edited:
@edbarx: When talking about vendor lock-in - did you obtain a binary-only kernel module from your DAC vendor, or do you complain because your DAC works only in the official RPi kernel?
The RPi people maintain sources for the various Rpi DAC hats in their repo, and accept new additions by the hat vendors.
https://github.com/raspberrypi/linux/tree/rpi-6.1.y/sound/soc/bcm
https://github.com/raspberrypi/linux/tree/rpi-6.1.y/arch/arm/boot/dts/overlays
The sources are publicly available, and any other distribution can include them into their kernel tree. Most of them are not part of the vanilla kernel as the hats are specific only for RPi in most cases.
Also you can extract the sources and compile your own modules on your linux of choice.
The RPi people maintain sources for the various Rpi DAC hats in their repo, and accept new additions by the hat vendors.
https://github.com/raspberrypi/linux/tree/rpi-6.1.y/sound/soc/bcm
https://github.com/raspberrypi/linux/tree/rpi-6.1.y/arch/arm/boot/dts/overlays
The sources are publicly available, and any other distribution can include them into their kernel tree. Most of them are not part of the vanilla kernel as the hats are specific only for RPi in most cases.
Also you can extract the sources and compile your own modules on your linux of choice.
Package maintainers are an essential group of distribution volunteers whose work is to port sources to their distribution. Their work can be difficult to achieve, sometimes even leading to package abandonment. I can speak about medit a text editor which I used a lot until it could NOT be ported to more recent distributions. Like medit, there are others, as older libraries are dropped or stopped being maintained.phofman said:
Vendor Lock-In and restrictive use of source can achieved in subtle ways, and this, is one of them. Make the use and installation of software unduly difficult and time consuming to dissuade any users using software in ways its authors do not like.
There are many, so called, howtos, which claim it is easy to use a DAC hat, and yet, it is instead, a terrible nightmare. For instance, if a user installs a DAC hat, why should it NOT be listed as "card 0"? A user is left in the dark to discover that other devices might exist on the Raspberry Pi which are taking precedence. This is one thing which happened to me, other devices were listed as card 0 and card 1, and my DAC hat given "card 2". Software like mpg123 and mplayer failed to use card 2, the DAC hat, whatever I did until I discovered I had to disable some devices using config.txt. However, NO ONE mentioned these devices in their howtos and that they can ruin an installation by making it impossible to access an installed hat. The only program which recognised "card 2" and used it was VLC, but it is now, extremely buggy, and I dare write, useless.
Last edited:
Several issues mixed here.
The I2S hats have no plug&play. There is no standardized device identification like in PCI or USB. RPi is not a consumer PC, it's an embedded ARM computer. Typically all SW incl. kernel and user-space would be provided by the device vendor, with firmware upgrades at best. RPi decided to create a learning tool, and made an ARM computer available for everyone. But that does not make it a consumer PC with plug&play and autodetection.
That's how linux alsa has been working since its beginning in 2002 (isch). The audio device order is not guaranteed and there is no way audio device vendor could ensure device index. You as a user can change the order, but the audio device vendor cannot hard-code the index 0 (and rightly so, every vendor would try to do that but only one device can be zero 🙂 ). The system does not know you want that particular audio device to have index 0. It's up to you to choose which device to use. Also devices can be identified by their names, not just indices.
Or use pulseaudio or pipewire and forget about alsa indices.
I am afraid you need to learn a bit more about linux audio. All the softwares you mention can be configured to use any of the alsa devices you have in your system, you just did not tell them to do so, and used the default device which on non-pulseaudio/pipewire systems uses device with index 0 (quite logically).
phofman said:
I solved the issue using brute force, that is, by disabling all other audio devices I do not use on the Raspberry Pi. ALSA, whether it likes it or not, had to assign "card 0" to the DAC HAT, as it is expected by anyone spending more money to get a separate better performing sound card, instead of the default devices which come with the Raspberry Pi.
This solved the issue of getting the right name for the card to allow mpg123 and mplayer to use the hat. However, as if the previous headaches were not enough, the developers of the Raspberry Pi OS, decided to use bleeding edge software which is full of outstanding bugs. To add insult to injury, as if this is not enough, they also use the infamous systemd. I tried to replace it, but the result was a breakage which could have resulted in an inability to boot. I wish I could use an alternative init to avoid boot hiccups and other issues.
There is never any need for a particular card to be card 0. You should just set the default device to the one you want, and refer to it by name instead of index.
It's really not that bleeding edge, compared to arch for example it's quite conservative. What bugs? And what is the problem with systemd? I mean what problems you have with it. Pretty much all the major distributions have adopted systemd. IMO it's a massive improvement over the old sysvinit with the awful init scripts.
Fair - still not sure how it's relevant to this generic Linux distro thread, but I hope you manage to find a solution 🙂
HOW? What magic wand should I use for it to work?HenrikEnquist said:
Bugs?! Sure! Trash behaviour like stopping and skipping parts of tracks, and during boot strange alien-like sounds emitted from speakers. A few months ago, this did not happen.
Ask the same question on the Devuan, dng@lists.dyne.org. They know far better than me. When the fork happened, I was one of the pioneers who pushed forward for the fork. However, notwithstanding my enthusiasm, I could not contribute much due to not having professional training in programming (ie a university course).
Oh, come on! Scripts could have been removed using other less invasive means.
Last edited:
@edbarx
Congratulations on getting it going !
I would suggest your demeaner is not assisting with you getting assistance.
Getting DAC HATs working has been the same process since the HAT were invented, maybe 8 years ago. Lots of people know the answers.
Congratulations on getting it going !
I would suggest your demeaner is not assisting with you getting assistance.
Getting DAC HATs working has been the same process since the HAT were invented, maybe 8 years ago. Lots of people know the answers.
Read the Alsa documentation, specifically the section "The default plugin":
https://www.alsa-project.org/main/index.php/Asoundrc
That's not what I asked. I asked what problems YOU have with it.
Lots of people know using a ready made image often works for them. In my case, it did not work as it expected my home network to be configured in some other way. I can only write, other devices like say, an android smart phone connects without issues.
I could not break my home network for the sake of a Pi image which refused to connect to it. I have been using that configuration for many many months without issues.