I'm putting together a Raspberry PI to play my FLAC music files. This will output SPDIF to a miniSharc using Volumio.
I can run this through my old Sony TV via HDMI. I am wondering if the TV is just a pass through or is liable to be doing something not bit perfect to the data.
The miniSharc resamples the data with sample rate conversion so I don't think jitter is an issue.
I can run this through my old Sony TV via HDMI. I am wondering if the TV is just a pass through or is liable to be doing something not bit perfect to the data.
The miniSharc resamples the data with sample rate conversion so I don't think jitter is an issue.
Your Sony TV is telling the Pi it has audio capabilities. HDMI relies on handshaking the capabilities. That's why it produces sound. Usually they downsample to 2.0 only.
Can the Minishark do the same thing or can You force HDMI audio on the PI ?
Does the Minishark work with a Blue ray player in 5.1. for example ?
Can the Minishark do the same thing or can You force HDMI audio on the PI ?
Does the Minishark work with a Blue ray player in 5.1. for example ?
Raspberry PI
The miniSharc is 2.0 so that is no problem. I listen to stereo from ripped CDs.
I think the situation may be more complicated, as I look into it the Raspberry PI does not do 44.1KHz in an accurate way. It requires some digital Hat to output at the correct sampling rate. So I think the HDMI in this case may be limited.
I could be wrong, there is a lot of older possibly out of date info on the web
The miniSharc is 2.0 so that is no problem. I listen to stereo from ripped CDs.
I think the situation may be more complicated, as I look into it the Raspberry PI does not do 44.1KHz in an accurate way. It requires some digital Hat to output at the correct sampling rate. So I think the HDMI in this case may be limited.
I could be wrong, there is a lot of older possibly out of date info on the web
HDMI audio output of RPi accepts any frequency between 8kHz and 192kHz linux/bcm2835-pcm.c at rpi-5.12.y * raspberrypi/linux * GitHub . The stock driver accepts only 16bits, for 24 bits the driver must be recompiled, unfortunately https://www.diyaudio.com/forums/pc-...rossovers-correction-etc-185.html#post6616884
The "less accurate" output for 44.1kHz is via I2S when generating clock directly by RPi (I2S master mode) - RPi (at least RPi4) does not have a free PLL clock available which could be configured to output integer multiple of 44,100Hz. Hence the jittery fractional MASH divider must be used for generating the bit & frame clocks. But that is not related to HDMI in any way.
Just a note - the HDMI stream does not carry any audio clock and the resultant clock must be PLL-recovered from the video-timed stream. I think less work is for 48kHz streams which allow fixed number of audio frames per each HDMI frame, theoretically making less work for the PLL recovering the audio clock. But I have not seen any real-world measurements, maybe jitter of the recovered clock for 48kHz and 44.1kHz streams is comparable, I do not know.
The "less accurate" output for 44.1kHz is via I2S when generating clock directly by RPi (I2S master mode) - RPi (at least RPi4) does not have a free PLL clock available which could be configured to output integer multiple of 44,100Hz. Hence the jittery fractional MASH divider must be used for generating the bit & frame clocks. But that is not related to HDMI in any way.
Just a note - the HDMI stream does not carry any audio clock and the resultant clock must be PLL-recovered from the video-timed stream. I think less work is for 48kHz streams which allow fixed number of audio frames per each HDMI frame, theoretically making less work for the PLL recovering the audio clock. But I have not seen any real-world measurements, maybe jitter of the recovered clock for 48kHz and 44.1kHz streams is comparable, I do not know.
Maybe another SBC would be a better choice to playback audio. Even my antique Cubox-i perform better than RPI 3 (was the last one I tried). On can (and must) build almost perfect electronics around the RPI for good audio results but it seems the RPI itself is still the weakest link. With best support, that must be said.
Last edited:
Any specific measurements? HDMI is pretty much digital. Maybe a different SBC would output a less jittery HDMI signal but I doubt this is an issue.
I2S quality depends on the bit clock. Generating the bitclock on RPi from a non-integer-multiple PLL clock is always a compromise. But the hardware allows simple switching to slave clocking.
On the other hand some other SBCs offer an external master-clock input and configurable internal dividers for the bit clock. That's quite convenient when providing external clock because the add-on hardware does not have to include the configurable dividers for each samplerate, the dividers can be adjusted by the ASoC driver directly.
I2S quality depends on the bit clock. Generating the bitclock on RPi from a non-integer-multiple PLL clock is always a compromise. But the hardware allows simple switching to slave clocking.
On the other hand some other SBCs offer an external master-clock input and configurable internal dividers for the bit clock. That's quite convenient when providing external clock because the add-on hardware does not have to include the configurable dividers for each samplerate, the dividers can be adjusted by the ASoC driver directly.