> As we know, it's always been somehow difficult or tricky to add sound for RaspberryPi. Some use gpio to generate pwm to make sound for speakers, some use I2S audio module to generate sound for speakers. But they all have some shortcomings. PWM generated from gpios on raspberryPi have much noise that make the speakers nealy usable, and I2S audio module will occupy the very precious gpio resoureces(usually take 3 gpio pins). And in some operating system there is no driver for these pwm or I2S audio module. Due to the reasons above this is how I solve the sound problem. [1]
Ok, digging into the schematic, I think I see the problem.
Almost all of the normally free GPIO is eaten up by a DPI (Display Parallel Interface) connection to the screen.
The screen should instead use the currently unused MIPI pins if you're already at the level of sophistication of laying out PCIe and USB3 traces.
That gives you back nearly all of your GPIO to use for stuff like I2S, and you can then even expose more non USB externally than just that one stemma port.
On top of that, for a project like this, I would disagree with the quality you get out of the pwm as audio thing. It's not audiophile by any means, but neither is some cheap Bluetooth receiver chip, and it's certainly good enough for the speakers that weren't designed for this case.
Far more complex because then you'd have to have a USB 3.X hub/switch IC on board unless you want to consume a USB interface. And USB hub/switches are notoriously not the greatest.
I'm not saying I like Bluetooth, but the justification isn't that bad.
The design artifacts are released with a liberal license, it shouldn't be TOO hard to fix that. Though I've never worked with SPI or I2S sound chips before.
When I've used i2s it has required setting spi clocks that made my spi devices not function. While it does have all of these IO buses, using more than one at a time is a bit of tetris. I wouldn't be surprised if there is some hardware constraint making i2s impossible.
I'd say the opposite. There's one interface, BT; pair your headphones, pair the internal speakers, there can't be a conflict, nor two places to look at.
It's a wireless device that is burning battery making negotiations with itself and wasting precious bt bandwidth in the process, and since most of Linux Bluetooth stack is user space stuff provided by the wm/de managers it guarantees no console sound compatibility without another layer of work. I think I could live without a pre console system beep but the other issues are pretty major oversights.
For real. For the kind of sound I'd expect out of this, the pwm channels on the rpi work just fine. If you want better sound, the rpi supports i2s.
> As we know, it's always been somehow difficult or tricky to add sound for RaspberryPi. Some use gpio to generate pwm to make sound for speakers, some use I2S audio module to generate sound for speakers. But they all have some shortcomings. PWM generated from gpios on raspberryPi have much noise that make the speakers nealy usable, and I2S audio module will occupy the very precious gpio resoureces(usually take 3 gpio pins). And in some operating system there is no driver for these pwm or I2S audio module. Due to the reasons above this is how I solve the sound problem. [1]
[1] https://github.com/ZitaoTech/HackberryPiCM5/tree/main/Speake...
Ok, digging into the schematic, I think I see the problem.
Almost all of the normally free GPIO is eaten up by a DPI (Display Parallel Interface) connection to the screen.
The screen should instead use the currently unused MIPI pins if you're already at the level of sophistication of laying out PCIe and USB3 traces.
That gives you back nearly all of your GPIO to use for stuff like I2S, and you can then even expose more non USB externally than just that one stemma port.
On top of that, for a project like this, I would disagree with the quality you get out of the pwm as audio thing. It's not audiophile by any means, but neither is some cheap Bluetooth receiver chip, and it's certainly good enough for the speakers that weren't designed for this case.
still just use a inexpensive usb to 3.5?
Far more complex because then you'd have to have a USB 3.X hub/switch IC on board unless you want to consume a USB interface. And USB hub/switches are notoriously not the greatest.
I'm not saying I like Bluetooth, but the justification isn't that bad.
The design artifacts are released with a liberal license, it shouldn't be TOO hard to fix that. Though I've never worked with SPI or I2S sound chips before.
When I've used i2s it has required setting spi clocks that made my spi devices not function. While it does have all of these IO buses, using more than one at a time is a bit of tetris. I wouldn't be surprised if there is some hardware constraint making i2s impossible.
Be grateful the keyboard doesn’t require pairing hahaha
I'd say the opposite. There's one interface, BT; pair your headphones, pair the internal speakers, there can't be a conflict, nor two places to look at.
It's a wireless device that is burning battery making negotiations with itself and wasting precious bt bandwidth in the process, and since most of Linux Bluetooth stack is user space stuff provided by the wm/de managers it guarantees no console sound compatibility without another layer of work. I think I could live without a pre console system beep but the other issues are pretty major oversights.